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.
*** Bug 365801 has been marked as a duplicate of this bug. ***
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.
Created attachment 248311 [details] xorg.conf
Created attachment 248321 [details] xorg.0.log
Created attachment 248331 [details] special bonus- lshal!
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
Still a problem in F10.
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?
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. :/
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.
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
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
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.
(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?
http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/keymap/README.keymap.txt
== 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.