On 04/23/11 06:11, Andre Majorel wrote: > Mmm... Sounds like it'll "just work" for the Gnome/KDE crowd and > the rest of us will have to make it work ourselves.
No. There's no reason if the keys all emit standard keycodes that all WMs should not provide reasonable default key bindings for all of them. If your favourite WM doesn't, file a bug. > I suppose we can live without hot keys in the console but it > would kind of suck if closing the lid had a different effect > depending on whether X is running. This is already the case, but don't worry about it. In the acpi-support package, if a power manager is detected, the action is delegated to the power manager. Otherwise yes, we do need to ensure some action (should also be handled by acpi-support ... I forget if this is the case right now or not, i.e. eeepc-acpi-scripts should not implement eee-specific behaviour here) should be triggered. > Without going through steps 1-3, here are the keycodes and > keysyms on a 1001HA running eeepc-acpi-scripts 1.1.10 and kernel > 2.6.38-2-686 : > > Fn-F1 150 XF86Sleep Suspends > Fn-F2 - - No effect > Fn-F3 199 - No effect > Fn-F4 192 - No effect > Fn-F5 232 XF86MonBrightnessDown Dims the backlight > Fn-F6 233 XF86MonBrightnessUp Brightens the backlight > Fn-F7 253 - No effect > Fn-F8 235 XF86Display No effect (then again, no monitor plugged) > Fn-F9 156 XF86Launch1 No effect > Fn-F10 121 XF86AudioMute Toggle audio > Fn-F11 122 XF86AudioLowerVolume Volume-- > Fn-F12 123 XF86AudioRaiseVolume Volume++ > Fn-spc 193 - No apparent effect > > Does that help at all ? Yes, it does. It's particularly interesting that Fn-F2 apparently has no keycode. For model 1001PX it is 246 and the Xorg keysym is XF86WLAN. So that is a case where acpi4asus needs to know about your model. They will need the results above and also the output of 'acpidump' for your model. I think for bugs like this we should both file a bug upstream and then again on the debian kernel (usertagging it with your model#, as per http://wiki.debian.org/DebianEeePC/Bugs/About), cross-referencing the upstream bug#. You can find the acpi4asus project here and use their bug tracker: http://acpi4asus.sourceforge.net/ As for Fn-F3, Fn-F4 and Fn-spc, in the current version of xorg (1:7.6+6) in sid, those are mapped to XF86TouchpadToggle, XF86Launch5 and XF86Launch6 respectively. Fn-F7, as I already noted, has no keysym in the latest xorg. So, at least for the first three keys, things should be fine in Wheezy. But I'm not sure about Fn-F7, whether acpi4asus is providing the right key here, or whether a different, more standard keycode should be emitted (something that Xorg maps to some standard keysym by default). Ben _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
