Bug 366211 - thinkpad-acpi generates event for tablet PC rotation, but X(?) doesn't do anything with them
thinkpad-acpi generates event for tablet PC rotation, but X(?) doesn't do any...
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
12
All Linux
low Severity low
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
: Triaged
: 365801 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-04 17:57 EST by Luis Villa
Modified: 2010-04-13 12:13 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-13 12:13:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
xorg.conf (1.06 KB, text/plain)
2007-11-05 10:27 EST, Luis Villa
no flags Details
xorg.0.log (676.43 KB, text/plain)
2007-11-05 10:28 EST, Luis Villa
no flags Details
special bonus- lshal! (113.78 KB, text/plain)
2007-11-05 10:28 EST, Luis Villa
no flags Details

  None (edit)
Description Luis Villa 2007-11-04 17:57:07 EST
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.
Comment 1 Luis Villa 2007-11-04 17:58:50 EST
*** Bug 365801 has been marked as a duplicate of this bug. ***
Comment 2 Matěj Cepl 2007-11-05 04:25:21 EST
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.
Comment 3 Luis Villa 2007-11-05 10:27:42 EST
Created attachment 248311 [details]
xorg.conf
Comment 4 Luis Villa 2007-11-05 10:28:14 EST
Created attachment 248321 [details]
xorg.0.log
Comment 5 Luis Villa 2007-11-05 10:28:53 EST
Created attachment 248331 [details]
special bonus- lshal!
Comment 6 Bug Zapper 2008-11-26 03:12:14 EST
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
Comment 7 Luis Villa 2008-11-30 21:54:36 EST
Still a problem in F10.
Comment 8 Adam Jackson 2009-02-08 02:54:22 EST
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?
Comment 9 Luis Villa 2009-02-08 13:39:16 EST
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. :/
Comment 10 Richard Schwarting 2009-10-25 06:07:10 EDT
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.
Comment 11 Bug Zapper 2009-11-18 07:22:47 EST
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
Comment 12 Richard Schwarting 2009-11-18 15:56:32 EST
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
Comment 13 Peter Hutterer 2009-11-24 18:22:21 EST
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.
Comment 14 Harald Hoyer 2010-01-26 06:04:27 EST
(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?
Comment 16 Harald Hoyer 2010-03-17 08:39:25 EDT
== 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.

Note You need to log in before you can comment on or make changes to this bug.