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

[Ben Armstrong]

On 04/22/11 12:59, Ben Armstrong wrote:
> Yes, I don't think we have a good solution yet for the backlight toggle.

I should elaborate ...

In prior versions of eeepc-acpi-scripts we used ACPI events to trigger
changes to Xorg. Backlight toggle is one such case. Unfortunately, we
had some horrible code to try to determine the DISPLAY and XAUTHORITY
and set them so that root could modify the user's display. This has been
rightly criticized as a bad idea and one that needs to die. In 1.1.11,
we began the work to fix this. Ideally, what happens is every key
generates a "button" even to the input subsystem instead. Then the
Window Manager can be used to bind that key to an appropriate action. In
this case, "xset dpms force off" to toggle off and "xset dpms force on"
to toggle on. (If you don't use X, you're on your own. I suppose in that
case, ACPI events might still be used to trigger some appropriate
action. I really haven't a clear idea of what the best way is.)

In git, we have some continuation of this work which needs to be
finished and finally uploaded. But of course, it's only going to be as
good as what the kernel modules (eeepc_wmi.ko for new models with WMI
BIOSes and eeepc_laptop.ko for older models without) translate to keys.
This varies per model, so any discrepancies between what different
models need and what the modules provide need to be filed as bugs
upstream (acpi4asus project) and find its way into new kernel releases
to help us.

We need any interested parties to chip in to continue this work, as it
has been stalled out for some time, ever since we decided the work in
progress wasn't going to make it into the Lenny release, in fact, work
has come to a standstill.

So here's where it starts:

1. check out the current version of eeepc-acpi-scripts from git
2. locally build the package & install it
3. use the latest 2.6.38 kernel from sid
4. by xev, etc.* determine which keys are generating "useful" keycodes
for your model
5. discuss here what to do with each issue found

For example, for the backlight toggle key Fn-F7, model 1001PX,
linux-image-2.6.38-2-amd64 version 2.6.38-3, xev indicates keycode 253
is sent:

KeyPress event, serial 37, synthetic NO, window 0x2c00001,
    root 0xab, subw 0x2c00002, time 214089027, (35,50), root:(327,351),
    state 0x0, keycode 253 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2c00001,
    root 0xab, subw 0x2c00002, time 214089027, (35,50), root:(327,351),
    state 0x0, keycode 253 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

In /usr/include/linux/input.h (linux-libc-dev 2.6.38-3) there is no
definition for keycode 253. However, there is:

#define KEY_DISPLAYTOGGLE	0x1af	/* Turn display (LCD) on and off */

Seems to be a different keycode. Furthermore, if there is supposed to be
a default Xorg mapping for this, I've been unable to find it.

Don't fixate on this particular example to the exclusion of all others.
It's just one of several we'll have to deal with. It may require bugs
filed against Xorg, the kernel, acpi4asus, eeepc-acpi-scripts,
individual window managers, or a combination of all. The main thing is
to not lose focus and stray from our goal to make Debian "just work" on
Eee PCs.

Ben
* I would say "input-events" as well, except for this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=609300
which seems to prevent it from working with 2.6.38.