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

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

[Mark Knecht]

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.

   However, for vanilla-sources-3.2.9 the only key that is doing
anything seems to be Fn-F1 which says 'button/sleep' (using
acpi_listen) but actually just turns on the screen saver as best I can
tell.

   Note that even with 3.2.7 most keys don't actually work, but at
least they all produce acpi_listen events. The only ones that do work
in 3.2.7 and earlier are:

Fn-F1 - screen saver
Fn-F5 - turns off screen but doesn't seem to generate an ACPI event in
acpi_listen (may be hardware mapped)
Fn-F11 - turn volume down
Fn-F12 - turn volume up

I haven't tested the external monitor one.

   The ones I really want to figure out are Fn-F3 & F4 as they turn
the keyboard lighting up and down. With 3.2.7 I had lighting, but with
3.2.9 I have no keyboard lighting at all so it will have hard to use
in the dark.

   Before I call this a 3.2.9 regression I figured I should determine
if I'm supposed to configure this stuff by hand, or maybe load some
new machine specific package that sets up the mappings.

Thanks in advance,
Mark


vanilla-sources-3.2.9

slinky events # acpi_listen
button/sleep SLPB 00000080 00000003
button/sleep SLPB 00000080 00000004



vanilla-sources-3.2.7

slinky ~ # acpi_listen
button/sleep SLPB 00000080 00000001
hotkey ATKD 0000005d 00000000
hotkey ATKD 0000007e 00000000
hotkey ATKD 000000c5 00000000
hotkey ATKD 000000c4 00000000
hotkey ATKD 0000002e 00000000
hotkey ATKD 0000001a 00000000
hotkey ATKD 00000034 00000000
hotkey ATKD 00000033 00000000
hotkey ATKD 00000034 00000001
hotkey ATKD 00000033 00000001
hotkey ATKD 00000061 00000000
hotkey ATKD 0000006b 00000000
hotkey ATKD 00000032 00000000
hotkey ATKD 00000032 00000001
hotkey ATKD 00000032 00000002
hotkey ATKD 00000031 00000000
hotkey ATKD 00000031 00000001
hotkey ATKD 00000031 00000002
hotkey ATKD 00000030 00000000
hotkey ATKD 00000030 00000001
hotkey ATKD 00000030 00000002
hotkey ATKD 00000030 00000003

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

[YoYo Siska]

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



> 
>    However, for vanilla-sources-3.2.9 the only key that is doing
> anything seems to be Fn-F1 which says 'button/sleep' (using
> acpi_listen) but actually just turns on the screen saver as best I can
> tell.
> 
>    Note that even with 3.2.7 most keys don't actually work, but at
> least they all produce acpi_listen events. The only ones that do work
> in 3.2.7 and earlier are:
> 
> Fn-F1 - screen saver
> Fn-F5 - turns off screen but doesn't seem to generate an ACPI event in
> acpi_listen (may be hardware mapped)
> Fn-F11 - turn volume down
> Fn-F12 - turn volume up
> 
> I haven't tested the external monitor one.
> 
>    The ones I really want to figure out are Fn-F3 & F4 as they turn
> the keyboard lighting up and down. With 3.2.7 I had lighting, but with
> 3.2.9 I have no keyboard lighting at all so it will have hard to use
> in the dark.
> 
>    Before I call this a 3.2.9 regression I figured I should determine
> if I'm supposed to configure this stuff by hand, or maybe load some
> new machine specific package that sets up the mappings.
> 
> Thanks in advance,
> Mark
> 
> 
> vanilla-sources-3.2.9
> 
> slinky events # acpi_listen
> button/sleep SLPB 00000080 00000003
> button/sleep SLPB 00000080 00000004
> 
> 
> 
> vanilla-sources-3.2.7
> 
> slinky ~ # acpi_listen
> button/sleep SLPB 00000080 00000001
> hotkey ATKD 0000005d 00000000
> hotkey ATKD 0000007e 00000000
> hotkey ATKD 000000c5 00000000
> hotkey ATKD 000000c4 00000000
> hotkey ATKD 0000002e 00000000
> hotkey ATKD 0000001a 00000000
> hotkey ATKD 00000034 00000000
> hotkey ATKD 00000033 00000000
> hotkey ATKD 00000034 00000001
> hotkey ATKD 00000033 00000001
> hotkey ATKD 00000061 00000000
> hotkey ATKD 0000006b 00000000
> hotkey ATKD 00000032 00000000
> hotkey ATKD 00000032 00000001
> hotkey ATKD 00000032 00000002
> hotkey ATKD 00000031 00000000
> hotkey ATKD 00000031 00000001
> hotkey ATKD 00000031 00000002
> hotkey ATKD 00000030 00000000
> hotkey ATKD 00000030 00000001
> hotkey ATKD 00000030 00000002
> hotkey ATKD 00000030 00000003
> 

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

[Mark Knecht]

On Tue, Mar 13, 2012 at 5:27 AM, YoYo Siska <yoyo@gl.ksp.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