You are not logged in.
The acpi hotkeys of my x201 tablet stopped working since upgrading to 3.1
thinkpad_acpi is correctly loaded during boot up and under
/sys/devices/platform/thinkpad_acpi
everything looks alright.
Normal events like brightness up and down keep on working because generic acpi signals get emitted:
[root@aotearoa ~]# acpi_listen
video/brightnessup BRTUP 00000086 00000000
video/brightnessup BRTUP 00000086 00000000
video/brightnessdown BRTDN 00000087 00000000
video/brightnessdown BRTDN 00000087 00000000
But I remember that they used to have the prefix: ibm/hoteky
This is no big issue, but the signals for swiveling the screen won't get emitted at all. So my acpid handler scripts for automatically switching to the tablet mode won't work anymore.
It seems that this is only an issue of the hotkeys, because the tablet mode is correctly recognized by thinkpad_acpi:
[root@aotearoa ~]# cat /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
0
and
[root@aotearoa ~]# cat /sys/devices/platform/thinkpad_acpi/hotkey_tablet_mode
1
when in tablet mode.
Any ideas?
Last edited by jaclar (2011-10-27 19:55:48)
Offline
The removal of deprecated acpi functionality from /proc may be related: https://mailman.archlinux.org/pipermail … 21829.html
Last edited by Stebalien (2011-10-26 03:37:26)
Offline
hm... i'll try later on today to compile myself a kernel with the deprecated /proc interfaces enabled. hope this helps...
Offline
indeed, compiling the kernel with the deprecated acpi proc interface, gave back the old functionality of acpid.
so what is the new way to get and react on this signals?
Update:
After some research I found out that the "state of the art" method to get the display state is to use the input layer. thinkpad_acpi generates a device node under /dev/input/event*.
I found a useful tool Magick Rotation and made a package for it in AUR. This solves the problem for now.
Last edited by jaclar (2011-10-27 19:54:53)
Offline