Lenovo Thinkpad x41 Tablet, X60 Tablet and X200 Tablet rotate events

[Christian Kellner]

Binary package hint: acpi-support

tablet mode close (when switching from laptop mode to tablet mode):
ibm/hotkey HKEY 00000080 00005009

tablet mode open (when switching from tablet mode to laptop mode):
ibm/hotkey HKEY 00000080 0000500a

The two lid events are (only occur in laptop mode):
button/lid LID 00000080 00000003
button/lid LID 00000080 00000004

It also has an rotate button which is not yet mapped to anything:
16:15:59.754: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = direction

This should rotate the screen as well as the wacom tablet.

It also has up and down buttons which are designed to go up and down in portrait mode and to left and right in landscape mode.
Keycodes:

left/down: keycode 105 from xev
right/up: keycode 99 from xev

[Christian Kellner (gicmo)]

cat /var/lib/acpi-support/*-*
75ET56WW (2.02 )
IBM
1869CNG
ThinkPad X41 Tablet

[Luis (luis-redhat-bugs-1)]

When I rotate my tablet, I see this in dmesg:
thinkpad_acpi: unknown LID-related hotkey event: 0x5009
thinkpad_acpi: unknown LID-related hotkey event: 0x500a

The first is 'down', the second 'up. They are unknown, so nothing happens :)

I'm not sure, frankly, exactly what should happen in F8- I have a script that
calls the following on 'down'

    /usr/bin/xrandr --output LVDS --rotate right
    /usr/bin/xsetwacom set stylus rotate 1

and the following on 'up':

    /usr/bin/xrandr --output LVDS --rotate normal
    /usr/bin/xsetwacom set stylus rotate 0

Those work OK. Not sure how to configure that, though. But it should happen by
default.

[Luis (luis-redhat-bugs-1)]

*** Bug 365801 has been marked as a duplicate of this bug. ***

[Matěj (matj-redhat-bugs)]

Luis, could we get our usual combo -- /etc/X11/xorg.conf and
/var/log/Xorg.0.log, please? This probably *is* hardware independent, but still
I would prefer to see what Xorg thinks about your hardware and whether there are
any error messages or warnings available.

[Luis (luis-redhat-bugs-1)]

Created attachment 248311
xorg.conf

[Luis (luis-redhat-bugs-1)]

Created attachment 248321
xorg.0.log

[Luis (luis-redhat-bugs-1)]

Created attachment 248331
special bonus- lshal!

[Christian Kellner (gicmo)]

This also applies to the X60 Tablet. I therefore changed the Subject to better describe the situation.

The HKEY events for "tablet mode close"/"tablet mode open" or identical. So is the not yet mapped rotate button.

But instead of the up and down buttons it has a wheel, i.e. a up, down, right and left key and one in the center to the wheel which already maps the ENTER. The up (portrait)/ and down (portrait) are xev keycodes are the same as for the X41 Tablet but I dont get any events in xev, or acpi_listen when I press them.

cat /var/lib/acpi-support/*-*
7JET22WW (1.07 )
LENOVO
6363A7G
Thinkpad X60 Tablet

[Florian Hackenberger (f-hackenberger)]

I'd like to propose the following additions in order to support panel rotation:

/etc/acpi/events/thinkpad-swivel-panel-down
--------------------------------------------------------
# called when tablet head swivels down
event=ibm/hotkey HKEY 00000080 00005009
action=/etc/acpi/swivel-panel-down.sh
EOF
--------------------------------------------------------

/etc/acpi/events/thinkpad-swivel-panel-up
--------------------------------------------------------
# called when tablet head swivels up
event=ibm/hotkey HKEY 00000080 0000500a
action=/etc/acpi/swivel-panel-up.sh
EOF
--------------------------------------------------------

/etc/acpi/swivel-panel-down.sh
--------------------------------------------------------
#!/bin/sh
#/etc/acpi/swivel-panel-down.sh

. /etc/default/acpi-support
. /usr/share/acpi-support/power-funcs

for x in /tmp/.X11-unix/*; do
    displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
    getXuser;
    if [ x"$XAUTHORITY" != x"" ]; then
        export DISPLAY=":$displaynum"
        /usr/bin/xrandr --output LVDS --rotate inverted
        /usr/bin/xsetwacom set stylus rotate 3
    fi
done
--------------------------------------------------------

/etc/acpi/swivel-panel-up.sh
--------------------------------------------------------
#!/bin/sh
#/etc/acpi/swivel-panel-down.sh

. /etc/default/acpi-support
. /usr/share/acpi-support/power-funcs

for x in /tmp/.X11-unix/*; do
    displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
    getXuser;
    if [ x"$XAUTHORITY" != x"" ]; then
        export DISPLAY=":$displaynum"
        /usr/bin/xrandr --output LVDS --rotate normal
        /usr/bin/xsetwacom set stylus rotate 0
        killall cellwriter
    fi
done
--------------------------------------------------------

Works fine on a T61t here.

[Florian Hackenberger (f-hackenberger)]

Ops, forget the
killall cellwriter
line in the /etc/acpi/swivel-panel-up.sh script. That's a leftover from my personal script.

[Daniel Hahler (blueyed)]

To get your fix included in Ubuntu, it would help if you tried transforming it into a debdiff (http://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff) and submit it for review (http://wiki.ubuntu.com/SponsorshipProcess). If you prefer somebody else to do that, that's fine - please just indicate if you're available to do that.

[Tom Verdaat (tom-verdaat)]

I support this request.

Florian, there is also a sensor on my X60 that senses which side of the screen is down when holding it vertically (in stead of laying it down on a table). Windows uses it to rotate the screen accordingly automatically. Is that included in your scripts? If not, could you look in to this?

[Florian Hackenberger (f-hackenberger)]

Hi Tom!

I quicked implemented a daemon which reads sensors values from the accelerometer using the hdaps_ec kernel driver and rotates the screen and the wacom stylus accordingly. The code is not mature yet, but it works quite nicely on my machine. Please download the code from http://code.google.com/p/rotate-daemon/ and test it. The installation is as easy as:

cd /tmp
svn checkout http://rotate-daemon.googlecode.com/svn/trunk/ rotate-daemon-read-only
cd rotate-daemon-read-only/
make
sudo make install

Now flip your display and execute:
sudo rotate_daemon

As soon as you tilt your screen in one direction over a certain threshold, the display should rotate accordingly.

I'm currently quite busy with work. Would someone volunteer to package it for Debian/Ubuntu and go through the upload sponsoring process?

[Florian Hackenberger (f-hackenberger)]

Sorry, I forgot to mention that you need to execute
sudo modprobe hdaps_ec before running rotate_daemon. After loading the module a 'dmesg' should give a line like:
input: ThinkPad HDAPS accelerometer data as /devices/platform/hdaps/input/input37
which confirms that the accelerometer values are accessible using the kernel input driver framework.

[Craig Magina (craig.magina)]

This is what I get when I rotate my X61 tablet running Kubuntu 8.04. This started with Hardy as it used to work with the 7.10.

[ 7744.482309] thinkpad_acpi: unknown LID-related HKEY event: 0x500c
[ 7748.771977] thinkpad_acpi: unknown LID-related HKEY event: 0x500b
[10932.697538] thinkpad_acpi: unknown LID-related HKEY event: 0x500c
[10949.251946] thinkpad_acpi: unknown LID-related HKEY event: 0x500b
[10995.392731] thinkpad_acpi: unknown LID-related HKEY event: 0x5009
[10999.820134] thinkpad_acpi: unknown LID-related HKEY event: 0x500c
[11010.466366] thinkpad_acpi: unknown LID-related HKEY event: 0x500a
[11017.964196] thinkpad_acpi: unknown LID-related HKEY event: 0x500b
[11710.325098] thinkpad_acpi: unknown LID-related HKEY event: 0x5009
[11716.484596] thinkpad_acpi: unknown LID-related HKEY event: 0x500a
[11818.422491] thinkpad_acpi: unknown LID-related HKEY event: 0x5009
[11819.443854] thinkpad_acpi: unknown LID-related HKEY event: 0x500a

I have all of your scripts loaded and the permissions set to what the other files in the directory have. Any help would be greatly appreciated.

[Craig Magina (craig.magina)]

OK, I got the rotation to work and the auto rotation as well. It took a reboot. I can't find a way to autostart the daemon though. I've tried an event.d file, rc.local, and an init.d script. The init.d script itself works but even though it is linked in rc5.d, it doesn't start. I will attach the init.d script, which I am sure could use a lot of work. It currently is able to start and stop the daemon.

[Florian Hackenberger (f-hackenberger)]

The scripts as well as the rotate daemon work fine on Ubuntu Hardy on an X61t here. I modified the scripts as follows to start/stop the rotate daemon as needed. The daemon is only useful when in tablet mode, therefore starting it using an init script is not ideal IMO. Adding / removing the kernel module within the swivel scripts might not be what you want though.

----------------------------------------------------------------------------------------
#!/bin/sh
#/etc/acpi/swivel-panel-down.sh

. /etc/default/acpi-support
. /usr/share/acpi-support/power-funcs

for x in /tmp/.X11-unix/*; do
    displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
    getXuser;
    if [ x"$XAUTHORITY" != x"" ]; then
        export DISPLAY=":$displaynum"
        if /usr/bin/xrandr --output LVDS --rotate inverted; then
                /usr/bin/xsetwacom set stylus rotate 3
        fi
        modprobe hdaps_ec
        killall rotate_daemon
        /usr/bin/rotate_daemon &
    fi
done
----------------------------------------------------------------------------------------
#!/bin/sh
#/etc/acpi/swivel-panel-down.sh

. /etc/default/acpi-support
. /usr/share/acpi-support/power-funcs

for x in /tmp/.X11-unix/*; do
    displaynum=`echo $x | sed s#/tmp/.X11-unix/X##`
    getXuser;
    if [ x"$XAUTHORITY" != x"" ]; then
        export DISPLAY=":$displaynum"
        if /usr/bin/xrandr --output LVDS --rotate normal; then
                /usr/bin/xsetwacom set stylus rotate 0
        fi
        killall rotate_daemon
        sleep 0.5;
        modprobe -r hdaps_ec
    fi
done
----------------------------------------------------------------------------------------

[Craig Magina (craig.magina)]

Removing the hdaps_ec kernel module isn't needed and having it is probably beneficial as that module is the "IBM Hard Drive Active Protection System (HDAPS) driver." Granted I have not looked at the code to see if it really does park the hard drive if it detects the laptop is in a free fall. A better way to start and stop the rotate daemon would be to use the "start-stop-daemon" tool, instead of doing the random kill to ensure it is dead before starting a new one. The start-stop-daemon will actually check for such things for you. The lines I added are as follows:

/etc/acpi/swivel-panel-up.sh
start-stop-daemon --stop --quiet --signal TERM --name rotate_daemon --exec /usr/bin/rotate_daemon

/etc/acpi/swivel-panel-down.sh
start-stop-daemon --start --quiet --background --name rotate_daemon --exec /usr/bin/rotate_daemon

Thanks for the advice on where to put these lines as this configuration is working very well.

Anyone interested in packaging all of these configurations for the thinkpad tablets?

[Tom Verdaat (tom-verdaat)]

I'm not a programmer so excuse me if this remark is completely illogical. I was reading this and wondering why we need a rotate_daemon?

There seem to be a number of actions related to screen rotation:
* rotating the screen to and from tablet mode
* vertically rotating the laptop itself
* pushing the rotate display button on the screen edge
If all these actions trigger ACPI events, couldn't they just be handled by an ACPI action script that executes xrandr and xsetwacom rotate commands?

If we do need a rotate daemon, can't it then handle all these actions so it can just be started at boot? If not, I guess it will be responsible for handling the accelerometer-driven events. It should be able to detect whether the laptop is in tablet mode or not, right? This way it could be enabled at all times (e.g. loaded at boot).

p.s. other distributions either support it already or are not paying much attention to it:
* https://bugzilla.redhat.com/show_bug.cgi?id=366211
* http://en.opensuse.org/TabletPCs

[Florian Hackenberger (f-hackenberger)]

Everything but the
* vertically rotating the laptop itself
action trigger ACPI events / xserver key events.

The laptop contains an accelerometer sensor which can be read by user space software (the rotate_daemon). The daemon has to read the sensors continously to detect a physical rotation over a certain treshold. As soon as the 'action' is detected, it rotates the screen.

All the other actions generate ACPI events or xserver key events. While ACPI event could in theory be read by the daemon, the acpid is usually responsible for doing that. But the acpid cannot read from the accelerometer sensors, therefore something else needs to do that. Furthermore, reading from the sensors can be computationally expensive if the update interval is high (this value is set in the kernel module), therefore it is a good idea to disable the daemon while being in laptop mode. While killing the daemon is one option, it could simply be 'suspended' with a USR1 signal for example.

Also note that the implementation I proposed was written in about two hours and is certainly far from ideal. Borrowing code / ideas from other distributions is probably a good idea.

Cheers,
          Florian

[Craig Magina (craig.magina)]

I have plans to work on improving my tablets configuration and creating/modifying packages to automatically configuring my tablet for me. Is there a project page where we can create a tablet support project, if one does not already exist, and add in all of these instructions there and also have a place share ideas/code we've done to get these things working to their fullest extent?

Due to the way the start-stop-daemon works, it does not allow for the passing of a signal on the start line. That could be modified though, or a wrapper script could be written to interact with the rotate_daemon to start/stop it using signals. The question I have is, what is the cost of terminating it and restarting it versus putting it to sleep? Is it even an issue? What I mean by that is when someone puts their laptop into tablet mode, they will probably leave it there for a long period of time until they are done with the laptop, and the same would go for using it in laptop mode. I know my common usage is laptop mode due to the lack of tablet usability under Linux. I only go into tablet mode when I am reading something. I'm looking forward to KDE4 as they are taking into consideration touchscreen interfaces with their design of the desktop, which as a side will improve tablet usage as well, at least in the tablet screen configurations. I use Linux 100% of the time on my X61t, so I would love to get everything working and have it easy to set up. I'm very willing to invest time into improving this stuff. The problem I know right now is that until the X input device support improves, which it is at a fast rate, some of the configuration might remain difficult for a few more releases.

One thing that should be added to these swivel scripts, is the keypad rotation. I know the python script out there handles that, but there is no reason this swivel script can't be extended to do it as well. Another thing with the swivel scripts, is a more descriptive name for them, like thinkpad-swivel-*.sh might be more appropriate as these are pretty specific to the thinkpad once the rotation daemon gets added to them.

[Florian Hackenberger (f-hackenberger)]

Since all that is quite distribution specific (each distribution has their own acpi scripts), I would recommend creating a project on launchpad and creating a wiki page on http://help.ubuntu.com/community for communication with users. https://help.ubuntu.com/community/TabletPC could need some more content anyways. If you want to get all this work into Intrepid, creating a blueprint would probably be a good idea.

Regarding the start/stop daemon question, the overhead is neglectible, the code of the daemon is about 200 lines of c code.

[Craig Magina (craig.magina)]

That sounds like a good idea. The problem I can foresee is there are a lot of different things that need to be configured/installed on a default Ubuntu system to get it configured for a tablet. I don't know much about the Ubuntu/Debian build system, so help there would be greatly appreciated. One aspect of the whole thing is the delivery mechanism. We could use a series of packages and a meta package that could pull the whole group in that could handle all of the setup and extra applications. Another issue I can see is with the difference between tablets. Thanks for the help, I'll see what I can get started based on what others have already done and see if it can be centralized for at least the Ubuntu community, although I'd prefer to see it all get back to Debian, at least what can be pushed back to them.

[Tom Verdaat (tom-verdaat)]

These pages contain some nice insights and scripts as well:
* http://www.thinkwiki.org/wiki/Installing_Ubuntu_6.10_on_a_ThinkPad_X41_Tablet
* http://www.krizka.net/2008/02/13/thinkpad-x61-tablet-automatic-screen-rotation-under-linux/
* http://www.krizka.net/2008/01/23/thinkpad-x61-tablet-tilt-detection-and-ubuntu-hardy-heron/
* http://luke.no-ip.org/x60tablet/

[Tom Verdaat (tom-verdaat)]

forgot one: http://ostebaronen.dk/?p=32

[yositune (webpagemail)]

I'm not sure what the status is but rotation has never worked for me from 7.10. acpi_listen receives the
ibm/hotkey HKEY 00000080 00005009
ibm/hotkey HKEY 00000080 0000500a

and /etc/acpi/events and scripts should be executing but they simply.. don't. I did notice that acpi also did not process the "access ibm" button events and execute scripts properly either and I ended up using metacity keyboard events to handle the button.

Also the rotation scripts that are floating around need to be consolidated (many of them will hang now at least on intrepid and 8.04) and I would support focus on Florian's sensors approach in the future.

8.10 upgrade has been very bad with brightness dimming and PAM problems and I'm almost tempted to just reinstall from a clean 8.10 to see if that fixes things... but makes my unix admin roots cringe.. ah but for time to fiddle with computers again..

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Luis (luis-redhat-bugs-1)]

Still a problem in F10.

[Adam (adam-redhat-bugs)]

Fixing component, XFree86 isn't really a thing anymore.

Do you still get the same messages in dmesg? Do you see an event for this in xev?

[Luis (luis-redhat-bugs-1)]

thinkpad_acpi no longer seems to emit those messages, and nothing in xev. This is even more irritating than it used to be, since I can't even jury-rig a fix myself for the problem. :/

[Roger E Critchlow Jr (rec)]

I'm going to confirm this and add the Lenovo X200 Tablet to the machines referenced by this bug. These hotkey events have been available for incorporation into acpi-support for years now, yet they still have to be researched by users and added manually to make them work.

There are also two additional hotkey events emitted by the x200 tablet which are mentioned above as unknown LID events. These are:

/etc/acpi/events/thinkpad-remove-stylus:
------------------------------------------------------
# Stylus removed from holder
event=ibm/hotkey HKEY 00000080 0000500c
action=/etc/acpi/thinkpad-remove-stylus.sh
------------------------------------------------------
/etc/acpi/events/thinkpad-replace-stylus
------------------------------------------------------
# Stylus replaced into holder
event=ibm/hotkey HKEY 00000080 0000500b
action=/etc/acpi/thinkpad-replace-stylus.sh
------------------------------------------------------

Could we perhaps get some centralized location for dealing with these tablet problems in ubuntu? There are a lot of them, and the response when filing bugs against the many different packages involved is uninspiring. This bug has been active since October 2007, a debdiff was requested and provided over a year ago, but nothing has happened, the problem remains unaddressed, generations of Thinkpad tablets have come and gone and Ubuntu remains a do-it-yourself project for owners of these laptops.

The screen rotation daemon issue discussed above is a bug that has no package to be filed against. To implement screen rotation you need to catch the xrandr rotations, and the accelerometer clues, no matter what source they originate from and generate tablet orientation and configuration changes which effect the stylus/touch coordinate systems, the pixel rendering, and the accelerometer orientation. This needs to be solved for all tablet and convertible computers. I suspect that we need a new /dev/input channel that collects and merges tablet orientation/configuration information.

So, this is a bug in acpi-support, but also in hal-info, and also in a non-existent package that takes care of making acpi-support and hal-info do the right thing.

[Karl Hegbloom (karl.hegbloom)]

I've started a package that addresses this. Please see:

https://code.launchpad.net/~karl.hegbloom/tabuntu/tablet-screen-rotation-support

[Karl Hegbloom (karl.hegbloom)]

Just want to remind everyone about the 'tablet-screen-rotation-support' package I've created. It's up in Launchpad, as part of the Tabuntu metapackage.

   https://code.launchpad.net/~karl.hegbloom/tabuntu/tablet-screen-rotation-support

I would love to spend more time developing this, but have limits on my available time. I put it up for everyone so that if anybody wants to work on it, they can. I think it has some features that the official tablet rotation support should have:

 * It is event driven, so any means of rotating the screen triggers it.
 * It is modular, so other packages can drop hook scripts into place, and so it can easily support other models of tablet computer or even monitors that rotate for landscape / portrait views.

[Richard (richard-redhat-bugs)]

When I press the button on F12 Beta Live CD (on USB), this appears in my message log:
atkbd.c: Unknown key pressed (translated set 2, code 0x6c on isa0060/serio0).
atkbd.c: Use 'setkeycodes 6c <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0x6c on isa0060/serio0).
atkbd.c: Use 'setkeycodes 6c <keycode>' to make it known.

And it does not rotate.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Richard (richard-redhat-bugs)]

Could an interested party bump this to 12?

Just upgraded to Fedora 12 and the issue remains:

atkbd.c: Unknown key pressed (translated set 2, code 0x6d on isa0060/serio0).
atkbd.c: Use 'setkeycodes 6d <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0x6d on isa0060/serio0).
atkbd.c: Use 'setkeycodes 6d <keycode>' to make it known.
atkbd.c: Unknown key pressed (translated set 2, code 0x6e on isa0060/serio0).
atkbd.c: Use 'setkeycodes 6e <keycode>' to make it known.
atkbd.c: Unknown key released (translated set 2, code 0x6e on isa0060/serio0).
atkbd.c: Use 'setkeycodes 6e <keycode>' to make it known.

Cheers

[Peter (peter-redhat-bugs)]

http://hal.freedesktop.org/quirk/quirk-keymap-intro.html
this article is now outdated with the deprecation of HAL but still provides some useful information.

reassigning to udev.

[tilo (thetilo)]

is there an ETA when this will be fixed in Fedora 12?

[Harald (harald-redhat-bugs)]

(In reply to comment #13)
> http://hal.freedesktop.org/quirk/quirk-keymap-intro.html
> this article is now outdated with the deprecation of HAL but still provides
> some useful information.
>
> reassigning to udev.

why udev?

[Harald (harald-redhat-bugs)]

http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/keymap/README.keymap.txt

[Harald (harald-redhat-bugs)]

== Fixing broken keys ==

In order to make a broken key work on your system and send it back to upstream
for inclusion you need to do the following steps:

 1. Find the keyboard device.

 Run /lib/udev/findkeyboards. This should always give you an "AT
 keyboard" and possibly a "module". Some laptops (notably Thinkpads, Sonys, and
 Acers) have multimedia/function keys on a separate input device instead of the
 primary keyboard. The keyboard device should have a name like "input/event3".
 In the following commands, the name will be written as "input/eventX" (replace
 X with the appropriate number).

 2. Dump current mapping:

 sudo /lib/udev/keymap input/eventX > /tmp/orig-map.txt

 3. Find broken scan codes:

 sudo /lib/udev/keymap -i input/eventX

 Press all multimedia/function keys and check if the key name that gets printed
 out is plausible. If it is unknown or wrong, write down the scan code (looks
 like "0x1E") and the intended functionality of this key. Look in
 /usr/include/linux/input.h for an available KEY_XXXXX constant which most
 closely approximates this functionality and write it down as the new key code.

 For example, you might press a key labeled "web browser" which currently
 produces "unknown". Note down this:

   0x1E www # Fn+F2 web browser

 Repeat that for all other keys. Write the resulting list into a file. Look at
 /lib/udev/keymaps/ for existing key map files and make sure that you use the
 same structure.

 If the key only ever works once and then your keyboard (or the entire desktop)
 gets stuck for a long time, then it is likely that the BIOS fails to send a
 corresponding "key release" event after the key press event. Please note down
 this case as well, as it can be worked around in
 /lib/udev/keymaps/95-keyboard-force-release.rules .

 4. Find out your system vendor and product:

 cat /sys/class/dmi/id/sys_vendor
 cat /sys/class/dmi/id/product_name

 5. Generate a device dump with "udevadm info --export-db > /tmp/udev-db.txt".

 6. Send the system vendor/product names, the key mapping from step 3,
 /tmp/orig-map.txt from step 2, and /tmp/udev-db.txt from step 5
 to the bug tracker, so that they can be included in the next release:

   https://bugs.launchpad.net/udev/+bugs

For local testing, copy your map file to /lib/udev/keymaps/ with an appropriate
name, and add an appropriate udev rule to /lib/udev/rules.d/95-keymap.rules:

  * If you selected an "AT keyboard", add the rule to the section after
  'LABEL="keyboard_vendorcheck"'.

  * If you selected a "module", add the rule to the top section where the
  "ThinkPad Extra Buttons" are.