Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#26658 - [linux] 3.1 - 3.12.x breaks some ACPI events on Lenovo ThinkPad tablets

Attached to Project: Arch Linux
Opened by Dan Fuhry (fuhry) - Friday, 28 October 2011, 07:07 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Tuesday, 11 February 2014, 04:29 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas B├Ąchler (brain0)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No


I'm currently running kernel version 3.1-2 from testing. I have noticed that certain ACPI events, most noticeably the one which fires when the tablet's lid is rotated down or up (hotkey 00005009 and 0000500a) are not showing up in acpi_listen. These events work properly when the kernel is downgraded to the latest 3.0.7 in core.

Running acpid -lfddd shows some log activity when the lid is rotated down or up but no event is fired.

The hardware in question is a Lenovo X220 Tablet running arch x86_64. If desired I will also test on my old tablet, an X41 running arch i686.

linux version (nonworking): 3.1-2
linux version (working): 3.0.7-1
acpid version: 2.0.12-1
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Tuesday, 11 February 2014, 04:29 GMT
Reason for closing:  Upstream
Additional comments about closing:  Nothing can be done here if not resolved since 2011 in upstream.
Comment by Jelle van der Waa (jelly) - Saturday, 29 October 2011, 09:23 GMT
IS it a bug in the linux package or in the kernel? If its in the kernel report it upstream
Comment by Natanji (Natanji) - Wednesday, 09 November 2011, 17:50 GMT
Just confirming this bug on 32-Bit, X60 Tablet.
Comment by Ethan Schoonover (altercation) - Sunday, 20 November 2011, 23:28 GMT
I believe this has also been noted in the mailing list but I'm seeing the same on the non-testing 3.1.1 kernel on an x220 tablet.
Comment by Ethan Schoonover (altercation) - Monday, 21 November 2011, 22:10 GMT
FWIW, the acpi events in 3.1.1 are a major improvement over 3.0 on my x220 in most of the cases and the stylus now generates an event on eject/stylus-dock, which is great. I'm hoping those stick around after this regression is addressed.
Comment by Peter (coolmast) - Wednesday, 23 November 2011, 12:21 GMT
Same problem on a x220 Tablet. Everything was working using kernel-3.0.7 on Arch Linux 64bit. Tried latest core and latest testing kernel (3.1.2), but both don't generate any acpi event for the thinkpad specific options. However the drivers are still working. Via polling it's still possible e.g. to determine the tablet mode but the corresponding acpi events are missing.
Comment by Natanji (Natanji) - Thursday, 24 November 2011, 21:43 GMT
I posted this to the kernel mailing list a while ago. The replies upstream suggest that this is an Arch-specific problem (as in: no other distribution has this problem!) This post here suggests that this is because of disabling PROCFS_ACPI in the Arch kernel as of 3.1.

What does PROCFS_ACPI do? Why was it disabled?

Also, could someone please increase the severity of this problem as this makes some ACPI events unusable, and maybe assign it to the kernel instead of ACPI since it seems to be the KERNEL that causes this problem (not some extra package)?
Comment by Ethan Schoonover (altercation) - Thursday, 24 November 2011, 22:57 GMT
I'm ready to do any testing required to help this along. I also haven't been able to generate a low battery ACPI ALARM event, though I've only tested this once.
Comment by Juri (lynucs) - Thursday, 24 November 2011, 23:13 GMT
confirming that since kernel 3.1.1 (and also in 3.1.2) no acpi event for lid close/open is reported on my x41t.
Comment by Peter (coolmast) - Friday, 25 November 2011, 08:36 GMT
I just rechecked it, recompiled my custom kernel and rechecked it again. I assume by PROCFS_ACPI you meant CONFIG_ACPI_PROCFS. At least this is the only corresponding config entry I could find. In my custom config it's enabled but the acpi events are still missing. To be more detailed. In sysfs there are all required information and by them I can verify that the drivers are loaded and working e.g. the tablet mode is displayed correctly. But the acpi events are still missing. So for me it doesn't seem to be a problem with CONFIG_ACPI_PROCFS. Must be something else. (For better understanding I attached my current .config
   note (82 KiB)
Comment by Thomas Krug (phragment) - Tuesday, 14 February 2012, 19:57 GMT
I can confirm that this bug is still around.
I'm missing my swivel up/down events.
running: 3.2.5-1-ARCH
Comment by Tobias Powalowski (tpowa) - Saturday, 28 April 2012, 08:10 GMT
Status on 3.3 series?
Comment by Natanji (Natanji) - Saturday, 28 April 2012, 15:01 GMT
Still broken. Additionally, the Lid-Close event is no longer the IBM-specific one, but the normal button/lid close event (no problem with that I guess).
Comment by Ignas Anikevicius (Liuuutas) - Sunday, 29 July 2012, 16:39 GMT
Unknowingly I have created a Forum Thread[1] and I am wondering could anybody confirm if my problem is related?

[1] -
Comment by Natanji (Natanji) - Monday, 30 July 2012, 12:10 GMT
I think your problem is very related, yes. It's the exact problem all others here have. ;)
Comment by Greg (dolby) - Monday, 15 October 2012, 02:57 GMT
Still a problem in 3.6?
Comment by Dan Fuhry (fuhry) - Monday, 15 October 2012, 03:04 GMT
I personally have moved on to other mechanisms (uinput).

If you take a look at pull requests under <>, I've submitted code for a daemon that polls the platform-thinkpad_acpi-event uinput device for rotation events and executes a rotation script. The code is horrible in a few places (I wrote it for my own use with no regard for portability or terrible hacks) but it shouldn't be too hard to port into a reasonable system level daemon.

Also, acpid 2.0.17 adds support for these rotation events. Too bad the emission of those events in acpid's socket crashes Xorg <>.
Comment by Ethan Schoonover (altercation) - Monday, 15 October 2012, 03:07 GMT
I'm on 3.5.6-1-ARCH and both lid rotation to tablet mode and pen dock/undock are now firing acpi events successfully. The lid rotation events show as TBLT (on|off), while the pen docking show up as generic LEN0068:00 events, but that's usable. I haven't tested low battery events yet, but at least regarding lid/tablet rotation and tablet pen state, this is a real improvement. Platform: Lenovo ThinkPad x220 tablet version
Comment by Natanji (Natanji) - Thursday, 18 October 2012, 13:05 GMT
  • Field changed: Percent Complete (100% → 0%)
The problem was not "fixed", it got worse:

I have the problem described there, and it is hell annoying really...
Comment by Natanji (Natanji) - Tuesday, 23 October 2012, 06:45 GMT
Okay, so we have the problem that X cannot handle the new Tablet-Event correctly. That sucks but is possibly not an ACPI bug.

There is something else though. My wifi radio switch *still* does not emit any kind of ACPI event. Is this different for anyone else with a Thinkpad?
Comment by Ethan Schoonover (altercation) - Tuesday, 23 October 2012, 17:38 GMT
@Natanji - I hadn't tested the radio hard kill switch but can confirm that it fails to trigger any acpi events (whereas it used to, long ago). This has been mitigated by recent improvements in iwlwifi/systemd, etc. and my wifi reconnection is pretty solid now. The only solution might be to use inotify and monitor your rfkill hard block values in /sys, though this is klugey and I only mention it as a stop gap that I am also considering.

@et al - Regarding tablet events, I'm running xorg-server 1.13.0-3, xf86-video-intel and xmonad, and can handle tablet events with no crashing, fwiw. I've seen a lot of strange xorg crashes based on my scripts that triggered on tablet events (scripts that used to prove rock solid). I've solved that through refactoring the scripts to be more robust in handling errors and trapping, and that's no suggestion that this is what other people are seeing at all, just a note.
Comment by Natanji (Natanji) - Wednesday, 19 December 2012, 13:17 GMT
I can confirm that X no longer crashes when the TBLT-event is emitted by ACPI, so that part is fixed.

rfkill remains a problem though. Polling for rfkill values sucks; I mean heck, the idea of ACPI is to be signal based so that you don't have to poll anything, right?
Comment by Tobias Powalowski (tpowa) - Wednesday, 23 January 2013, 14:54 GMT
Status on 3.7.x?
Comment by Natanji (Natanji) - Wednesday, 23 January 2013, 15:53 GMT
Same as ever.
Comment by Ethan Schoonover (altercation) - Wednesday, 23 January 2013, 18:13 GMT
3.7 - radio hard switch ACPI event still missing in action on x220 thinkpad.
Comment by Tobias Powalowski (tpowa) - Wednesday, 27 February 2013, 11:09 GMT
Status on 3.8?
Comment by Vladimir (vldmr) - Friday, 22 March 2013, 18:13 GMT
Issue still exists.
Kernel 3.8.4. Arch x86_64. ThinkPad X220i.
Comment by Tobias Powalowski (tpowa) - Thursday, 23 May 2013, 19:40 GMT
Status on 3.9?
Comment by Natanji (Natanji) - Friday, 02 August 2013, 09:03 GMT
  • Field changed: Percent Complete (100% → 0%)
Still exists on 3.9.9 - sorry for not replying before.
Comment by Tobias Powalowski (tpowa) - Friday, 02 August 2013, 09:03 GMT
Status on 3.10.x?
Comment by Natanji (Natanji) - Friday, 02 August 2013, 22:43 GMT
Same problem as always.
Comment by Jelle van der Waa (jelly) - Friday, 15 November 2013, 13:43 GMT
And status on 3.12?
Comment by Natanji (Natanji) - Friday, 15 November 2013, 16:09 GMT
Comment by Jelle van der Waa (jelly) - Friday, 15 November 2013, 16:41 GMT
did you fill a bug upstrem? I can't find one in this thread.
Comment by Natanji (Natanji) - Friday, 15 November 2013, 17:12 GMT
Yea, I reported it to the kernel mailing list in Nov. 2011.