[Debian-eeepc-devel] Help needed: eeepc kernel modules & eeepc-acpi-scripts for Wheezy

[Ben Armstrong]

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