[Debian-eeepc-devel] Some function keys not working on asus eee 1215T

[Ben Armstrong]

On 09/20/2011 03:17 PM, Cristian Rigamonti wrote:
> On Tue, Sep 20, 2011 at 11:52:29AM -0300, Ben Armstrong wrote:
>>
>> Which version of eeepc-acpi-scripts are you using? 
> 
> The 1.1.11 package from Debian testing.
> 
>> Did you see my  earlier note in this thread, posted this morning?
> 
> Just seen it (sorry I wasn't yet subscribed to the list); of course I can use my
> window manager settings to overcome the keys, but I was looking for a more
> general solution (BTW the LCD backlight keys are currently working OK both in X
> and in the console).

The general solution *is* the window manager solution. Window managers
and desktop environments should have default mappings for standard keys.
Drivers should fire standard key events. ACPI scripts should not get in
the middle unless they absolutely have to (and I would say what they
should do in that case is map the ACPI event to fire a key with
acpi_fakekey and *then* let the WM/DE handle it).

If the driver doesn't fire a key at all, it's a bug on the driver. File
it on the kernel and we'll forward it upstream.

If the driver fires a key but the WM/DE doesn't provide a default
mapping for that key (and it's a standard, non-hardware-specific key)
arguably, that's a bug in the WM or DE.

If the WM or DE upstream doesn't agree it's a standard key, maybe you
should consider using one that does. If you find no WM or DE agrees it's
a standard key, well, we'll cross that bridge when we get to it. :)

Just about the only key I would agree is possibly non-standard and
Eee-specific is Fn-Spacebar, the "Super Hybrid Engine" key. Ideally, if
for no other reason, to be consistent, that should follow the same
model. That being said, even though the ASUS implementation is a bit
strange, I would say this key is a kind of "performance" hotkey that
surely exists in other hardware, so eventually some standard keysym that
X understands should be decided upon for it.

As for what agent on the desktop would respond to and act on the
(privileged) action that the S.H.E. key should trigger, that's perhaps a
separate issue that should be tackled in the same manner as however you
make an applet that modifies cpufreq settings on the fly, rather than
some hardcoded acpi script behaviour.

And finally, for those using neither a WM nor DE, yes, I do see the
appeal of acpi scripts, but I still think it is cleaner to generalize
the keyboard as "just a bunch of keys" that generate input events that
are then handled by your front end rather than hardwiring some of them
to do jobs "behind the scenes" without the front end even knowing it. I
don't know how console-only users plan to handle multimedia keys in
general, or if there are already agents available to take care of these
matters, but since I am not one of those, it is not high up on my list
of priorities to solve.

> Anyway, I dug a bit into the scripts and maybe they need to be fixed to work
> with newer eee models using the eeepc_wmi module; for example:
> 
> - /etc/default/eeepc-acpi-scripts contains:
> 
>     FnF_VGATOGGLE='handle_vga_toggle'

As I've stated, we want to get away from this model.

> - /usr/share/acpi-support/eeepc-acpi-scripts/vga-toggle.sh contains:
> 
>     test -d /sys/bus/platform/devices/eeepc || exit 0
>     # do nothing if package is removed
> 
>   But this directory doesn't exist on my system, though the package is
>   installed. /sys/bus/platform/devices/eeepc-wmi exists instead.

Right. You'll find in git this reads:

[ -d /sys/devices/platform/eeepc ] || [ -d
/sys/devices/platform/eeepc-wmi ] || exit 0

i.e. it continue on so long as either eeepc-laptop or eeepc-wmi is
loaded. we haven't fully finished support for eeepc-wmi.

>   Tests for the existence of this directory are found in other scripts of the
>   package (including the /etc/init.d script).
> 
>   I fixed all occurrences that I could find (replacing with:
>   test -d /sys/bus/platform/devices/eeepc* || exit 0 ), restarted the service
>   but I still can't get any results.

you should have checked our code in git before starting down this road.

>   (I now get a warning about pciehp on service startup:
>   
>     Loading EeePC support modules...pciehp...FATAL: 
>     Error inserting pciehp (/lib/modules/3.0.0-1-686-pae/kernel/drivers/pci/hotplug/pciehp.ko):
>     Unknown symbol in module, or unknown parameter (see dmesg) ... (warning).

that's a known bug, fixed in git.

>     
>     dmesg says:  pciehp: Unknown parameter `pciehp_slot_with_bus'
> 
>   but maybe this is not relevant; I guess because I'm running linux 3.0 and the
>   init script doesn't support it yet).
> 
> This makes me wonder that maybe there are other parts of the package to be
> updated in order to work with newer eee models using the eeepc_wmi module.
> 
> Another example: some scripts try to use /sys/class/backlight/eeepc/brightness but
> that doesn't exist either on my system.
> 
> Yet another one: /etc/acpi/if-asus-not-eee.sh from the "acpi-support" package
> contains the same test (I also fixed this, but no results).

Please check out the git code and dpkg-buildpackage -us -uc, then try
the resulting package.

Ben