Ikke's Blog

Post details: ASUS laptops, multimedia keys and INPUT

Aug 15
ASUS laptops, multimedia keys and INPUT

For quite a while on several systems where ACPI is used to deliver key press events to the operating system (mostly laptops, that's why we got the asus_acpi, thinkpad, toshiba, sony,... drivers in the kernel). In userspace acpid was used then to fetch these commands, a callout script was used which used some application to inject the corresponding keycode (based on the ACPI event ID, which is just "randomly chosen" by the hardware manufacturers) on some input device, so applications (eg your X server) were able to see the key press events. Especially the acpid -> callout -> map scancode to keycode -> inject in input device isn't such a "nice" solution, but it worked, most of the time.

Recently people (one of them Richard Hughes of GPM fame, you know, that power-eating applet ;-)) started to rework these in-kernel drivers to use the kernel input subsystem directly, so no more round-trip to userspace would be necessary.
There are 2 possibilities here: you can store a scancode to keycode mapping table in the driver itself, or you can remap scancodes to a keycode from userspace on some device using ioctl's.

This last method is made easy by HAL (0.5.10 or git), which includes a callout which allows you to store the mappings in an FDI file, and then performs the remapping when a matched device is found on the system. More information about this can be found here.

IMHO this method is the cleanest, as it doesn't force us to store big device-specific mapping tables in the kernel driver. It's userspace so much easier to make changes, add new device information,...

ASUS laptop owners couldn't make use of this yet as nor the in-kernel driver, asus_laptop, or it's -cvs version provide relaying to a kernel input device. Yesterday I decided to implement this, and today it got somewhat finished, after some minor issues. You can find the resulting patch here, it's against current acpi4asus CVS, but I think it should apply cleanly against a vanilla kernel too. I'll submit it to the acpi4asus list tomorrow. Git repository is here, you want the "acpi_keys_to_input_layer_no_internal_mapping" branch.

After compiling the driver and insmoding it (or modprobe if you install it too, make sure you don't load the old version by accident) you should see some information in dmesg: a message the driver is loaded, the name of your laptop model, and the fact a new input device called "Asus Extra Buttons" was created. Now when you press some multimedia buttons and check dmesg again, it should tell you some keys were pressed it can't map to a known keycode, also providing the scancode. You can use this information to generate an FDI file as described in the pages I linked to before.

If you're using an "old" HAL version, you can download a small utility here to emulate HAL's behaviour using hard-coded information. You need to make a list of scancodes and their meaning using KEY_* values. You can find these constants in /usr/include/linux/input.h, or in include/linux/input.h of your local kernel source tree.
Once you know which scancodes map to which KEY_* value, you can add them to the "mappings" variable defined at the top of the C file. The format is simple: scancode1, keycode1, scancode2, keycode2,...,-1. Make sure you always add pairs of scancode/keycode values, and end the array with a -1.

Once you entered the values, compile the program (gcc -o set-asus-keymap set-asus-keymap.c), figure out the event device node for the Asus Extra Buttons device (check /proc/bus/input/devices, where Name is Asus Extra Buttons, see which eventX is after Handlers), and run the program (as root) using ./set-asus-keymap /dev/event/eventX (now I don't want *any* comments on this entry regarding "I have no eventX node").

When you're done with this, create a nice FDI file too, and send it to the HAL mailing list so others can enjoy your research too :-)

That's about it, your special keys should "just work" and acpid is no longer necessary to handle them.


Comment from: Jack Malmostoso [Visitor] Email
Thank you so much!
I just bought an Asus laptop and I couldn't find a way to make the "turn off Wifi" button work.

Do you have any advice on how to do that? I was thinking about linking it to a shell script that would rmmod the iwl4965 module and the bluetooth modules. If there is a cleaner way, I'm here to listen :)

Thanks again!
PermalinkPermalink 08/15/07 @ 10:35
Comment from: Ikke [Member] · http://www.eikke.com
I guess as these buttons are mapped to "real" keycodes now, it should be possible to add this functionality to some "hardware manager" daemon. Maybe gnome-volume-manager is a good place for this, maybe some other application (maybe even superseeding gvm) should be used, not completely sure...
HAL got support for the ipw killswitch, so that shouldn't be an issue. There are several ways to "power off" a bluetooth or wlan device, next to rmmod'ing the module, think of hcitool hci0 down, or iwconfig wlan0 down.

The "performance buttons" could eg also change GPU speed settings, set your wlan chipset to a lower power mode, etc. Would be an interesting project.
PermalinkPermalink 08/15/07 @ 11:54
Comment from: Jack Malmostoso [Visitor] Email
The patch applied cleanly to Debian's 2.6.22 sources. Now I get the keycodes when I press the buttons :D

I'll look into compiling properly hal 0.5.10 (not even Gutsy has packages, meh) and try to prepare .fdi files.

Thanks again for your help!
PermalinkPermalink 08/15/07 @ 15:59
Comment from: Patrys [Visitor] Email
Hughsie already did a patch against asus-laptop and last time I checked with him, was in the middle of getting it submitted upstream. You might want to contact him not to do duplicate work.
PermalinkPermalink 08/15/07 @ 20:09
Comment from: SzymonO [Visitor] Email
I used your patch and there was no problem. I wanted to do fdi file but now I have a problem. Every time I press special key i receive something like this:

keyboard.c: can't emulate rawmode for keycode 240
keyboard.c: can't emulate rawmode for keycode 240
asus-laptop: scancode 0x51 is unknown

Last line is your log. I think that previous two means that event was not generated because of a bug. Can you help me with that?

My model is:
system.hardware.product = 'V1J' (string)
system.hardware.serial = 'SSN12345678901234567' (string)
system.hardware.uuid = '533381DB-584F-4B81-7E80-0018F33C278E' (string)
system.hardware.vendor = 'ASUSTeK Computer Inc.' (string)
system.hardware.version = '1.0' (string)

I used asus-laptop -0.42-cvs

Keymap is also registered
info.capabilities = {'input', 'button', 'input.keymap'} (string list)
input.keymap.data = {'0x50:email', '0x51:www'} (string list)

Szymon O

PermalinkPermalink 08/19/07 @ 18:07
Comment from: Ikke [Member] · http://www.eikke.com
the keyboard.c warnings are normal. You should add a mapping for 0x51 too.
PermalinkPermalink 08/23/07 @ 16:44
Comment from: SzymonO [Visitor] Email
I think i registered it already. Doesn't this says that key 0x51 is registered?

info.capabilities = {'input', 'button', 'input.keymap'} (string list)
input.keymap.data = {'0x50:email', '0x51:www'} (string list)

Maybe I registered it wrong. I did new file like that:

<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->

<deviceinfo version="0.2">

<!-- These are raw scancodes produced by the asus-latop driver with patch form http://blog.eikke.com/index.php/ikke/2007/08/15/asus_laptops_multimedia_keys_and_input -->
<match key="input.product" string="Asus Extra Buttons">

<match key="/org/freedesktop/Hal/devices/computer:system.hardware.vendor" prefix="ASUSTeK">
<match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" contains="V1J">
<append key="input.keymap.data" type="strlist">0x50:email</append> <!-- Email -->
<append key="input.keymap.data" type="strlist">0x51:www</append> <!-- I key -->
<append key="info.capabilities" type="strlist">input.keymap</append>



I bind keys to "Asus Extra Buttons" input.product is that ok?
PermalinkPermalink 08/29/07 @ 11:59

This post has 7 feedbacks awaiting moderation...

Leave a comment:

Your email address will not be displayed on this site.
Your URL will be displayed.

Allowed XHTML tags: <p, ul, ol, li, dl, dt, dd, address, blockquote, ins, del, span, bdo, br, em, strong, dfn, code, samp, kdb, var, cite, abbr, acronym, q, sub, sup, tt, i, b, big, small>
(Line breaks become <br />)
(Set cookies for name, email and url)
(Allow users to contact you through a message form (your email will NOT be displayed.))


Who's Online?

  • Guest Users: 117


XML Feeds

What is RSS?