Re: [gentoo-user] How are Fn-F# ACPI events mapped?

[Mark Knecht]

On Tue, Mar 13, 2012 at 5:27 AM, YoYo Siska <yoyo@××××××.sk> wrote:
> On Sun, Mar 11, 2012 at 03:23:28PM -0700, Mark Knecht wrote:
>> Hi,
>>    I'm trying to figure out how my Asus laptop maps function key
>> events. This is being driven by an emerge message telling me that the
>> acpi4asus package is being obsoleted and removed in 30 days and
>> replaced by an in-kernel driver. I've removed the package and rebuilt
>> my kernels to use this driver, and for vanilla-sources-3.2.7 the
>> results are similar as with the acpi4asus package.
>
> don't know anything about the assus packages/drivers, but the general
> direction in all such drivers is to move these things where they belong:
> to the input subsystem, so my guess is the new driver doesn't produce
> acpi events, but insted create a "input device" and produce key
> press/release events on that device...
>
> (note that sleep / hibernate actions are usually still reported also
> throgh acpi, because some programs expect them to come from there, that
> would explaing your Fn-F1/sleep working)
>
> to test this, just run as root on the linux console (not in a termnal in
> X):
>
> showkey -s
>
> and then pres the keys (ie Fn-F4,) to stop showkeys, just don't press
> anything for 10 seconds...
> if you see numbers appearing after each keypress / release, then the key
> directly generates keyboard ivents  and its possible you will see them
> directly in X, for that jus run (now under X)
>
> xev
>
> and (the window that appears must have focus / be active) press the keys
> again, xev will print the X keycodes/keysyms to its output...
> if you see reasonable names there, then you should be able to map those
> keys in the programs you are using (ie global hotkeys in kde, etc...)
> note however that qt/kde doesn't recognise some of the more exotic
> keysyms...  (in my case XF86TouchpadToggle produced by Fn-F8 on
> thinkpads ;)
>
> if you can see the key in showkey -s  but not in xev, the problem might
> be in kernel keyboard map (though i'm not sure if the x's evdev driver
> uses that) or in the evdev driver not mapping that key
>
> basically the kernel driver reports scan codes (what showkey -s shows),
> kernel translates that to keycodes (showkey -k to see them) and then X's
> input driver (ie evdev) translates those to the X keycodes X server
> again trasnlates them to keysym-s....
>
> yoyo
>

Hi,
   Sorry about the late reply. I messed with this a few days ago but
never wrote to say thanks. My bad.

   Basic outcome - there seemed to be three things I learned:

1) The basic message architecture, thanks to your post. Thanks for that.

2) There is some problem with vanilla-sources-3.2.9 which is
apparently fixed in 3.2.10. Thanks to kernel devs I suppose for that.
Almost all the function keys now produce some sort of message in
acpi_listen, showkey & xev.

3) The function I seem to be missing at this point is being able to
actually control the brightness of keyboard backlights. I can do this
in Windows but not in Linux. However I don't know yet if Linux even
has a driver with that capability so I'll have to spend some time
looking for that over the weekend.

   Again, thanks for the response. It was quite helpful.

Cheers,
Mark