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