 |
 |
 |
|
 |
You are not logged in.
My darling has arrived 
It`s sooo sweet... I played around a lil bit with XP but now I have installed Ubuntu successfully. Adam`s kernel works quite well. Now I'm trying to finish the acpi-script (not Will`s version), which will have some original OSD from Ubuntu.
What I have done so far:
* WiFi toggle (from Merkmal, still buggy)
* BT toggle (second hotkey)
* Brightness
* Volume
Next:
* VGA toggle
* Fn+F6 => Gnome taskmanager
* First hotkey disables/enables internal screen
* Third and Fourth hotkey user-defined
But at the moment I am busy, so it could take some time...
Last edited by elmurato (2008-08-18 9:08:41 pm)
Offline
For those of you who, like me, have installed Xubuntu, note that any script actions that use acpi_fakekey will not work. Acpi_fakekey generates events, but unless something is listening for these events, nothing will happen. I believe under Ubuntu and possibly Kubuntu, some element within the GUI is listening for these events and will take some appropriate actions if it receives them. Not so for Xubuntu. As a result, if you want to get your mute, volume up, volume down, and any other keys that currently rely on acpi_fakekey to work, you will need to change the action to run, for example, amixer with the appropriate options. Furthermore, there will be no on screen display of these events unless you program an action to display something.
I believe WillW's architecture runs a python script in response to each Fn+F? event. Although I really like the Python language, it is rather heavyweight and there is a hefty startup penalty while it loads a bunch of libraries, etc. Although I have not actually timed the startup, I would be surprised if a simple "hello world" python script did not require at least 10x the time to execute as an equivalent C/C++ program. If response time is an issue (which I gather it is from reading the comments here), a significant improvement could be had by rewriting the program in C/C++. Alternatively, Python could be used if the code were rewritten to run as a daemon and listen for ACPI events directly (from the acpi daemon itself) thus avoiding the high start-up cost of Python applications.
If I had more time, I'd step up to the plate and write the code myself. However, as things stand, it may be some time before I could get to this as I don't use the eeepc often enough for it to be a big nuisance.
Thomas
Offline
Thanks thomasb.
I was wondering what was up. Couldn't get much to work!
Guess I'll wait for some scripts to be attached to this post and hack at them personally for Xubuntu. Or go digging around for some others. It'd be nice to find something for the four buttons above the function keys. They do send acpi events. Right now I'm thinking the silk-screened images suggest Cheese, or video calls/chat and maybe suspend/hibernate.
As an aside -- someone above mentioned removing a couple of scripts when the install is done. Any reason to leave other scripts there at all? It's just confusing, and potentially conflicting. Really, why have IBM, Toshiba and Sony scripts? And the Asus scripts that are there are not for the eee. I say take 'em all out.
But what do I know? Just a talky chump on a message board. 
m a r
Offline
Whatever handles the screen brightness seems to work so I'd advise against deleting that. Basically I think it's a case of "if it ain't broke, don't fix it".
The script I posted (a modified version of WillW's) controls the volume in Xubuntu using amixer (installed by default), which is DE-independent. No OSD yet and it's a bit laggy (not sure why, Python is usually lightning-quick), but aside from that it works just fine.
Offline
What`s the command for volume control with amixer? Could you post it please?
Offline
Volume up 10%: amixer set Master 10%+
Volume down 10%: amixer set Master 10%-
Volume mute: amixer set Master mute
Volume unmute: amixer set Master unmute
For how to check whether the control is muted or unmuted, see my Python script.
Offline
Just wrote a few lines of code to verify my earlier hypothesis. I executed a "Hello, World" program in Python and in C on my Asus eeepc 901 under Xubuntu. The results are as follows:
Python: 26 milliseconds per execution
C: 2.6 milliseconds per execution
Thus, the overhead to start up a Python program is almost exactly 10x the overhead to start up a C program. Looks like my earlier guess was spot on (lucky, I admit).
I used the Unix system() call to execute both Python and C programs. This starts a shell which in turn execs the hello world program. This is exactly how acpid will run any acpi actions, such as shell scripts or WillW's python handler, so the overhead of startup up the shell is included in this comparison (otherwise the difference would be substantially greater than 10x).
This shows that replacing WillW's python code with C or C++ code will make a noticeable difference in terms of reducing the button lag (by a factor of 10 or so!).
I can throw together a simple C program to process events pretty quickly. It won't handle any on screen displays, but it should significantly reduce button lag. I could get fancy and have it parse a configuration file with mappings between key codes and actions, but in the interests of expediency, I'll keep it simple and hard code everything until there's a need for greater flexibility.
I'll post the code in the next 24 hours or so when I've had a chance to write and test it on my system.
Offline
I don't think that the Python script is inherently too slow. The C program will not be 10x faster than the equivalent Python program; the starting overhead comes from initialising the interpreter. There is something specific in there that slows it down, and I'd quite like to find out what - I think it has something to do with wxWindows. Maybe I'll use the Python profiler to check.
Offline
This is getting off topic, so I'll keep it short.
I love Python. However, the facts are that C is a _much_ faster language. Most of the time this doesn't matter much, but occasionally it does. Of the 17 different benchmarks you will find compared at http://shootout.alioth.debian.org/gp4/b … ng2=python you will see that C runs anywhere from 1 to 290 times faster than Python, with an average of 55 times faster!
If you don't believe the numbers at the above web site, they provide the source code for all of the tests so that you can download it and verify for yourself.
The main issue in this case, however, isn't runtime performance, but rather startup performance. I believe after I have posted the C program I allude to above, you will be able to see this for yourself. Any Python profiling you do will not show you the startup overhead. If you want to see this overhead, tell me where you'd like me to upload the benchmark programs I referenced earlier and you're welcome to run strace on both of them to see exactly what's going on for yourself.
Offline
I'd be very happy to be proved wrong, but a 26ms lag shouldn't be noticeable at all. Your C program will run faster than the Python script, but the Python script should not run as slowly as it does.
EDIT: As I suspected, the slowdown is caused by wxPython. Removing 'import wx' and everything that used wx reduced the execute time for a volume mute from 0.528s to 0.128s. Importing GTK brings that up to 290s, so it seems that GTK is a much better option for OSD.
Last edited by nickspoon (2008-08-19 5:01:43 pm)
Offline
So guys my script is ready. On my 901 everything is working If you want to test it:
* Fn+F1 Standby
* Fn+F2 WLAN-toggle
* Fn+F3/F4 Brightness
* Fn+F5 VGA-toggle
* Fn+F6 Taskmanager
* Fn+F7/F8/F9 Volume
* 1. new hotkey Display-toggle (internal)
* 2. new hotkey Bluetooth-toggle
* 3. new hotkey user-defined
* 4. new hotkey user-defined
wget http://www.informatik.uni-bremen.de/~elmurato/901/Ubuntu_ACPI_scripts-EeePC_901_1000.tar.gz tar -xfvz Ubuntu_ACPI_scripts-EeePC_901_1000.tar.gz cd Ubuntu_ACPI_scripts-EeePC_901_1000/ chmod +x install.sh sudo ./install.sh
After the installation you have to add your username to the file /etc/acpi/eeepc-actions.sh. There you can also edit the user-defined comands...
@Nick
Thanks. Maybe I will add it to the script as an alternative...
Last edited by elmurato (2008-08-20 8:30:55 pm)
Offline
Oh, elmurato, you are the man, everything works like a charm on my 1000H now! thank you for your great work!
Offline
I`m glad that I could help you. You`re the first tester 
Offline
OK, I threw together a quick C program to replace eeepc-hotkeys.sh as a proof of concept. It seems to work fine on my eeepc 901 running Xubuntu and I don't detect any keyboard lag with the volume controls, despite being quite enthusiastic while pressing them.
I took the liberty of grabbing the eeepc-vga-toggle.sh and eeepc901_1000-wifi-toggle.sh from Elmurato and plumbing them into the C code for added functionality. For changing the volume, I'm using amixer. For those of you using regular Ubuntu systems, you could easily modify the code to use acpi_hotkeys instead.
My goals in writing this code were two: First, to see if the keyboard lag can be reduced to acceptable values (seems fine to me), and two, to provide a C foundation to which additional OSD capability could be added if it proves to be viable. A simple graphics library like pngwriter could be used to add this functionality without too much effort.
I've uploaded the code to http://rapidshare.com/files/138657466/c … 1.zip.html
I don't recommend trying the code unless you're somewhat comfortable with the command line. You'll need to unzip the code into a directory on your system and follow the brief directions in the included README file.
Note that I have only tested this on my eeepc 901 running Xubuntu. It should work on the eeepc 1000 from what I understand, and if you're comfortable making some small modifications to the included C program, you can adjust it to provide OSD for the volume controls under Ubuntu.
Offline
elmurato, almost everything works great for me on a 901! Congratulations and thank you!
The only issue I see is with Fn+F2. If I press it while online, networkmanager doesn't give me any feedback and still shows I'm online, but if I try to surf the web I see that I'm disconnected, cause every website is unreachable. If I press Fn+F2 again to reconnect, the icon of the network manager applet goes to OFFLINE., and never comes back to online. So I have to press Fn+f2 again to disable wireless, and then again Fn+F2 to finally be able to go online.
So in brief to disable wireless and enable it again I have to use Fn+F2 4 times. This is always reproduceable in my system.
I hope it can helps.
Last edited by canesalato (2008-08-20 6:00:25 am)
Offline
@elmurato
Are you planning on doing an OSD version ?
Offline
On my 1000H, there are 10 function keys with silk-screened images, and the four new hotkeys.
F1: sleep
F2: wireless
F3: blank (and sends no acpi event)
F4: blank (and sends no acpi event)
F5: dim screen
F6: brighten screen
F7: backlight off
F8: toggle external monitor/LCD
F9: system monitor or task manager
F10: mute
F11: volume down
F12: volume up
Plus the four new hotkeys, of course.
So elmurato's script would probably work, but not really suit the keyboard quite right. Any possibility for a script that fits it better?
Also, does anyone else get a brightness OSD popup on Xubuntu when the AC is connected? (NOT when the brightness up F6 is pressed, though.) What is generating that OSD image? It would be nice to use whatever it is to make an OSD for Xubuntu, as I gather that the usual Ubuntu OSD is generated via Gnome. Or remove it if it cannot make the other keys' popups.
Thanks,
m a r
Offline
Oh I din`t know that :S
But here you can see, that the event-codes are the same: http://forum.eeeuser.com/viewtopic.php?id=39666 It doesn`t matter where the keys are. And on matri`s 1000h it is working...
Offline
@elmurato -- I've got it working with my 1000h for the keys that you had already in your script. I just changed the pointers so they go to what's silkscreened on the keyboard.
there is a very significant time lag/latency between my button presses and the actual behavior, but it seems to work reliably as long as I'm a little patient. I'll post my changes to the /etc/acpi/eeepc-actions.sh later tonight.
Offline
I see, you mean this, right?
Fn+F7 hotkey ATKD 00000016
But isn`t this the same as the first one of the new keys? I could add that event code to the script, but what should it do?
Offline
well, odd things happened for me, but good news! elmurato's script works with my 1000h out of the box (+username) with the corrrect (silkscreened) fn keys.
turns out, you definitely need to reboot for the scripts to take effect. when i rebooted, i found that my script changes actually broke the functionality and the original script works fine.
i am confused about what's going on though, the text of the script says
<code>
# Fn+F6
00000012)
su $username -c /usr/bin/gnome-system-monitor &
;;
</code>
yet system monitor starts only when i hit fn+f9
does this mean that asus changed the code mapping or is this coming from adamm's kernel?
I'm probably missing something very basic, but I'd like to learn
thanks!
Offline
The key-mappings on the 901 and on the 1000/1000h are different, but the event-codes are the same. I will release a new version soon with some more OSDs and with corrected comments in the script to avoid missunderstanding.
901: http://www.madboxpc.com/wp-content/gall … te_800.jpg
1000: http://www.einfach-eee.de/wp-content/my … te_800.jpg
I will add the event-code for Fn+F7 of the EeePC 1000, but with no action... Or have you an idea?
Last edited by elmurato (2008-08-20 8:39:37 pm)
Offline
@elmurato thanks for the explanation (and the work!)
welll, the graphic on fn+f7 is a monitor-like square with an "X" inside, so i'm guessing that means blank screen? or backlight off?
Offline
Great work, elmurato.
All works perfectly on my 901!
One thing I would say is that your install script irreversibly deletes some files that some might like to hold on to in case they wish to revert all the changes back to stock?
Just a thought - anyway, love the scripts - finally the blue LED is banished when the wifi/bluetooth are turned off
Another point - about the VGA toggle:
When connected to a screen with a higher vertical resolution than the EEE's 600px high screen (say a 1024x768 projector), the EEE will display 1024x600 of the 1024x768 resolution, meaning that the EEE retains its aspect ratio without stretching things, but the bottom 168px are missing. The external will display at full 1024x768 res. However, this means that the bottom of the screen is not viewable on the EEE's panel, and you have to look at the external monitor to see the lower 168px of information (bad if you're running a presentation or the like from your EEE, perhaps).
You can get around this by altering the script to force the external screen to display at 800x600 just by altering the xrandr command for the VGA output from "--auto" to "--mode 800x600".
This then keeps the EEE in 1024x600 resolution, but constrains the screen real-estate to 800x600 for the taskbars etc. and when maximising new windows - meaning that everything you see on the EEE will display at the correct resolution and aspect ratio on the external screen - the only problem is that the external screen is displaying a paltry 800x600 which is very low, admittedly.
Can anyone offer any way to improve this (or for that matter allow the EEE 901 with stock Ubuntu to display at a higher res. than 1024x768? The EEE only provides a virtual space of 1024x1024 which is the maximum allowed when querying xrandr at the moment with the stock xorg.conf file.)
Top job, nevertheless, elmurato!
Offline
Excellent work, elmurato! I'm amazed at how fantastically everything works, I really am.
Offline
