Regression in thinkpad-acpi events

Regression in thinkpad-acpi events

[Natanji]

Hello everyone,
first time posting on this last, and I'm not subscribed, so please CC
any replies to me. ;)

I'm running Kernel version 3.1-4 using Arch Linux (32 Bit) on a Thinkpad
X60 Tablet. Since upgrading from a pre-3.1 kernel to a post-3.1 kernel,
the Thinkpad-specific ACPI events (from thinkpad-acpi) are completely gone.

This can be observed by using the acpi_listen command. For instance, no
ACPI events happen when swiveling the display, and the sleep button returns
	button/sleep SBTN 00000080 00000000
instead of the previous
	ibm/hotkey HKEY 00000080 00001004

The bug was reported in the Arch Linux bugtracker [1] and it was
suggested to report this upstream, so this is what I did now. Sadly I
have no idea how I could find out if this is indeed a kernel bug or not;
I have never compiled my own kernel so what I can give you is probably
limited. But I suppose quite a few members of this list use a Thinkpad.
If there is anything else I can help out with, just tell me.

[1] https://bugs.archlinux.org/index.php?do=details&task_id=26658

Re: Regression in thinkpad-acpi events

[Maciej Rutecki]

On środa, 9 listopada 2011 o 19:17:25 Natanji wrote:
> Hello everyone,
> first time posting on this last, and I'm not subscribed, so please CC
> any replies to me. ;)
> 
> I'm running Kernel version 3.1-4 using Arch Linux (32 Bit) on a Thinkpad
> X60 Tablet. Since upgrading from a pre-3.1 kernel to a post-3.1 kernel,
> the Thinkpad-specific ACPI events (from thinkpad-acpi) are completely gone.
> 
> This can be observed by using the acpi_listen command. For instance, no
> ACPI events happen when swiveling the display, and the sleep button returns
> 	button/sleep SBTN 00000080 00000000
> instead of the previous
> 	ibm/hotkey HKEY 00000080 00001004
> 
> The bug was reported in the Arch Linux bugtracker [1] and it was
> suggested to report this upstream, so this is what I did now. Sadly I
> have no idea how I could find out if this is indeed a kernel bug or not;
> I have never compiled my own kernel so what I can give you is probably
> limited. But I suppose quite a few members of this list use a Thinkpad.
> If there is anything else I can help out with, just tell me.
> 
> [1] https://bugs.archlinux.org/index.php?do=details&task_id=26658

Can you check that 3.1 works or not? Or try bisection that it is regression 
after 3.0 or 3.1 kernel.

Regards
-- 
Maciej Rutecki
http://www.mrutecki.pl

Re: Regression in thinkpad-acpi events

[Natanji]

With 3.0 it was still fine, that much is for sure. The problem came 
with the upgrade to 3.1. I've never even compiled my own kernel so I 
cannot bisect. Sorry...

Regards,
Natanji

On Mon 14 Nov 2011 08:31:06 PM CET, Maciej Rutecki wrote:
> On środa, 9 listopada 2011 o 19:17:25 Natanji wrote:
>> Hello everyone,
>> first time posting on this last, and I'm not subscribed, so please CC
>> any replies to me. ;)
>>
>> I'm running Kernel version 3.1-4 using Arch Linux (32 Bit) on a Thinkpad
>> X60 Tablet. Since upgrading from a pre-3.1 kernel to a post-3.1 kernel,
>> the Thinkpad-specific ACPI events (from thinkpad-acpi) are completely gone.
>>
>> This can be observed by using the acpi_listen command. For instance, no
>> ACPI events happen when swiveling the display, and the sleep button returns
>> 	button/sleep SBTN 00000080 00000000
>> instead of the previous
>> 	ibm/hotkey HKEY 00000080 00001004
>>
>> The bug was reported in the Arch Linux bugtracker [1] and it was
>> suggested to report this upstream, so this is what I did now. Sadly I
>> have no idea how I could find out if this is indeed a kernel bug or not;
>> I have never compiled my own kernel so what I can give you is probably
>> limited. But I suppose quite a few members of this list use a Thinkpad.
>> If there is anything else I can help out with, just tell me.
>>
>> [1] https://bugs.archlinux.org/index.php?do=details&task_id=26658
>
> Can you check that 3.1 works or not? Or try bisection that it is regression 
> after 3.0 or 3.1 kernel.
>
> Regards

Re: Regression in thinkpad-acpi events

[Maciej Rutecki]

(add more CCs)

On poniedziałek, 14 listopada 2011 o 20:44:14 Natanji wrote:
> With 3.0 it was still fine, that much is for sure. The problem came
> with the upgrade to 3.1. I've never even compiled my own kernel so I
> cannot bisect. Sorry...
> 
> Regards,
> Natanji
> 
> On Mon 14 Nov 2011 08:31:06 PM CET, Maciej Rutecki wrote:
> > On środa, 9 listopada 2011 o 19:17:25 Natanji wrote:
> >> Hello everyone,
> >> first time posting on this last, and I'm not subscribed, so please CC
> >> any replies to me. ;)
> >> 
> >> I'm running Kernel version 3.1-4 using Arch Linux (32 Bit) on a Thinkpad
> >> X60 Tablet. Since upgrading from a pre-3.1 kernel to a post-3.1 kernel,
> >> the Thinkpad-specific ACPI events (from thinkpad-acpi) are completely
> >> gone.
> >> 
> >> This can be observed by using the acpi_listen command. For instance, no
> >> ACPI events happen when swiveling the display, and the sleep button
> >> returns
> >> 
> >> 	button/sleep SBTN 00000080 00000000
> >> 
> >> instead of the previous
> >> 
> >> 	ibm/hotkey HKEY 00000080 00001004
> >> 
> >> The bug was reported in the Arch Linux bugtracker [1] and it was
> >> suggested to report this upstream, so this is what I did now. Sadly I
> >> have no idea how I could find out if this is indeed a kernel bug or not;
> >> I have never compiled my own kernel so what I can give you is probably
> >> limited. But I suppose quite a few members of this list use a Thinkpad.
> >> If there is anything else I can help out with, just tell me.
> >> 
> >> [1] https://bugs.archlinux.org/index.php?do=details&task_id=26658
> > 
> > Can you check that 3.1 works or not? Or try bisection that it is
> > regression after 3.0 or 3.1 kernel.
> > 
> > Regards

-- 
Maciej Rutecki
http://www.mrutecki.pl

Re: Regression in thinkpad-acpi events

[Henrique de Moraes Holschuh]

On Mon, 14 Nov 2011, Natanji wrote:
> With 3.0 it was still fine, that much is for sure. The problem came 
> with the upgrade to 3.1. I've never even compiled my own kernel so I 
> cannot bisect. Sorry...

Well, please keep me in the CC.  I'm the thinkpad-acpi maintainer.

> >> This can be observed by using the acpi_listen command. For instance, no
> >> ACPI events happen when swiveling the display, and the sleep button returns
> >> 	button/sleep SBTN 00000080 00000000
> >> instead of the previous
> >> 	ibm/hotkey HKEY 00000080 00001004

That usually happens when you don't have thinkpad-acpi loaded at all.

Does lsmod report that thinkpad-acpi is loaded?  Are there any messages from
thinkpad-acpi in the kernel log?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Regression in thinkpad-acpi events

[Natanji]

thinkpad-acpi is definitely loaded:
$ lsmod | grep think
thinkpad_acpi          54704  0
snd                    43817  11
snd_hda_codec_analog,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,thinkpad_acpi,snd_timer
rfkill                 12470  3 bluetooth,thinkpad_acpi,cfg80211
nvram                   4765  1 thinkpad_acpi

I also noticed that removing or replacing the tablet pen in its slot
still yields an ibm/hotkey acpi event. This is the output of $
acpi_listen when I do this:
ibm/hotkey IBM0068:00 00000080 0000500c
processor LNXCPU:00 00000081 00000000
processor LNXCPU:01 00000081 00000000
ibm/hotkey IBM0068:00 00000080 0000500b
processor LNXCPU:00 00000081 00000000
processor LNXCPU:01 00000081 00000000

thinkpad-acpi also shows up in kernel log:
# cat /var/log/kernel.log | grep thinkpad_acpi
Nov 14 10:00:13 localhost kernel: [   14.207399] thinkpad_acpi: ThinkPad
ACPI Extras v0.24
Nov 14 10:00:13 localhost kernel: [   14.207403] thinkpad_acpi:
http://ibm-acpi.sf.net/
Nov 14 10:00:13 localhost kernel: [   14.207406] thinkpad_acpi: ThinkPad
BIOS 7JET30WW (1.15 ), EC 7JHT13WW-1.04
Nov 14 10:00:13 localhost kernel: [   14.207409] thinkpad_acpi: Lenovo
ThinkPad X60 Tablet, model 6363WDK
Nov 14 10:00:13 localhost kernel: [   14.224471] thinkpad_acpi: detected
a 8-level brightness capable ThinkPad
Nov 14 10:00:13 localhost kernel: [   14.231577] thinkpad_acpi: ACPI
backlight control delay disabled
Nov 14 10:00:13 localhost kernel: [   14.232156] thinkpad_acpi: radio
switch found; radios are enabled
Nov 14 10:00:13 localhost kernel: [   14.232897] thinkpad_acpi: possible
tablet mode switch found; ThinkPad in laptop mode
Nov 14 10:00:13 localhost kernel: [   14.257007] thinkpad_acpi: rfkill
switch tpacpi_bluetooth_sw: radio is blocked
Nov 14 10:00:13 localhost kernel: [   14.263972] thinkpad_acpi: Standard
ACPI backlight interface available, not loading native one
Nov 14 10:00:13 localhost kernel: [   14.264099] thinkpad_acpi: Console
audio control enabled, mode: monitor (read only)
Nov 14 10:00:13 localhost kernel: [   14.265628] input: ThinkPad Extra
Buttons as /devices/platform/thinkpad_acpi/input/input5
Nov 14 10:00:16 localhost kernel: [   19.996929] thinkpad_acpi:
deprecated sysfs attribute: access by process with PID 1076
Nov 14 10:00:16 localhost kernel: [   19.996934] thinkpad_acpi: WARNING:
sysfs attribute bluetooth_enable is deprecated and will be removed.
Please switch to generic rfkill before year 2010
Nov 14 12:58:34 localhost kernel: [ 5453.928107] thinkpad_acpi: ACPI
backlight control delay disabled
Nov 14 19:30:16 localhost kernel: [23290.557775] Modules linked in: fuse
hidp hid cpufreq_ondemand ext3 jbd ecb btusb bluetooth pcmcia arc4
snd_hda_codec_analog iwlagn sdhci_pci firewire_ohci sdhci mmc_core
firewire_core yenta_socket pcmcia_rsrc pcmcia_core uhci_hcd mac80211
crc_itu_t snd_hda_intel ehci_hcd snd_hda_codec psmouse thinkpad_acpi
snd_hwdep cfg80211 e1000e serio_raw iTCO_wdt snd_pcm iTCO_vendor_support
snd_timer i2c_i801 snd usbcore snd_page_alloc soundcore rfkill ac nvram
battery evdev thermal ipv6 acpi_cpufreq freq_table processor mperf ext4
mbcache jbd2 crc16 cryptd aes_i586 aes_generic xts gf128mul dm_crypt
dm_mod ata_piix sd_mod ahci libahci libata scsi_mod i915 drm_kms_helper
drm i2c_algo_bit button i2c_core video intel_agp intel_gtt agpgart
Nov 14 19:30:16 localhost kernel: [23292.952019] thinkpad_acpi: ACPI
backlight control delay disabled

So I suppose it is loaded alright, but just some of the events don't
work anymore at all (like for my physical rfkill switch) and/or get
overridden by other "standard" events (like with the sleep button).

On 11/14/2011 09:30 PM, Henrique de Moraes Holschuh wrote:
> On Mon, 14 Nov 2011, Natanji wrote:
>> With 3.0 it was still fine, that much is for sure. The problem came 
>> with the upgrade to 3.1. I've never even compiled my own kernel so I 
>> cannot bisect. Sorry...
> 
> Well, please keep me in the CC.  I'm the thinkpad-acpi maintainer.
> 
>>>> This can be observed by using the acpi_listen command. For instance, no
>>>> ACPI events happen when swiveling the display, and the sleep button returns
>>>> 	button/sleep SBTN 00000080 00000000
>>>> instead of the previous
>>>> 	ibm/hotkey HKEY 00000080 00001004
> 
> That usually happens when you don't have thinkpad-acpi loaded at all.
> 
> Does lsmod report that thinkpad-acpi is loaded?  Are there any messages from
> thinkpad-acpi in the kernel log?
> 

Re: Regression in thinkpad-acpi events

[Henrique de Moraes Holschuh]

On Mon, 14 Nov 2011, Natanji wrote:
> I also noticed that removing or replacing the tablet pen in its slot
> still yields an ibm/hotkey acpi event. This is the output of $
> acpi_listen when I do this:
> ibm/hotkey IBM0068:00 00000080 0000500c
> processor LNXCPU:00 00000081 00000000
> processor LNXCPU:01 00000081 00000000
> ibm/hotkey IBM0068:00 00000080 0000500b
> processor LNXCPU:00 00000081 00000000
> processor LNXCPU:01 00000081 00000000

Are those events above *exactly* the same on the kernel that is not
causing problems?

> So I suppose it is loaded alright, but just some of the events don't
> work anymore at all (like for my physical rfkill switch) and/or get
> overridden by other "standard" events (like with the sleep button).

Please give me the output of:
grep . /sys/bus/platform/devices/thinkpad*/*

(adjust that path if required, it may be slightly incorrect).  I really
want to know the contents of the hotkey_* sysfs nodes.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Regression in thinkpad-acpi events

[Tom Gundersen]

On Tue, Nov 15, 2011 at 7:18 AM, Maciej Rutecki
<maciej.rutecki@gmail.com> wrote:
> (add more CCs)
>
> On poniedziałek, 14 listopada 2011 o 20:44:14 Natanji wrote:
>> With 3.0 it was still fine, that much is for sure. The problem came
>> with the upgrade to 3.1. I've never even compiled my own kernel so I
>> cannot bisect. Sorry...
>>
>> Regards,
>> Natanji
>>
>> On Mon 14 Nov 2011 08:31:06 PM CET, Maciej Rutecki wrote:
>> > On środa, 9 listopada 2011 o 19:17:25 Natanji wrote:
>> >> Hello everyone,
>> >> first time posting on this last, and I'm not subscribed, so please CC
>> >> any replies to me. ;)
>> >>
>> >> I'm running Kernel version 3.1-4 using Arch Linux (32 Bit) on a Thinkpad
>> >> X60 Tablet. Since upgrading from a pre-3.1 kernel to a post-3.1 kernel,
>> >> the Thinkpad-specific ACPI events (from thinkpad-acpi) are completely
>> >> gone.
>> >>
>> >> This can be observed by using the acpi_listen command. For instance, no
>> >> ACPI events happen when swiveling the display, and the sleep button
>> >> returns
>> >>
>> >>    button/sleep SBTN 00000080 00000000
>> >>
>> >> instead of the previous
>> >>
>> >>    ibm/hotkey HKEY 00000080 00001004
>> >>
>> >> The bug was reported in the Arch Linux bugtracker [1] and it was
>> >> suggested to report this upstream, so this is what I did now. Sadly I
>> >> have no idea how I could find out if this is indeed a kernel bug or not;
>> >> I have never compiled my own kernel so what I can give you is probably
>> >> limited. But I suppose quite a few members of this list use a Thinkpad.
>> >> If there is anything else I can help out with, just tell me.
>> >>
>> >> [1] https://bugs.archlinux.org/index.php?do=details&task_id=26658
>> >
>> > Can you check that 3.1 works or not? Or try bisection that it is
>> > regression after 3.0 or 3.1 kernel.

I'm observing the same, also with Arch Linux, and a ThinkPad x60:
# uname -a
Linux x60 3.1.1-1-ARCH #1 SMP PREEMPT Fri Nov 11 22:28:29 CET 2011
x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux

The kernel config can be found here:
<http://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux>.

As requested:
# grep . /sys/bus/platform/devices/thinkpad*/*
/sys/bus/platform/devices/thinkpad_acpi/bluetooth_enable:1
grep: /sys/bus/platform/devices/thinkpad_acpi/cmos_command: Permission denied
/sys/bus/platform/devices/thinkpad_acpi/hotkey_all_mask:0x00ffffff
/sys/bus/platform/devices/thinkpad_acpi/hotkey_bios_enabled:0
/sys/bus/platform/devices/thinkpad_acpi/hotkey_bios_mask:0x0000080c
/sys/bus/platform/devices/thinkpad_acpi/hotkey_enable:1
/sys/bus/platform/devices/thinkpad_acpi/hotkey_mask:0x008dffff
/sys/bus/platform/devices/thinkpad_acpi/hotkey_poll_freq:10
/sys/bus/platform/devices/thinkpad_acpi/hotkey_radio_sw:1
/sys/bus/platform/devices/thinkpad_acpi/hotkey_recommended_mask:0x008dffff
/sys/bus/platform/devices/thinkpad_acpi/hotkey_report_mode:1
/sys/bus/platform/devices/thinkpad_acpi/hotkey_source_mask:0x00000000
/sys/bus/platform/devices/thinkpad_acpi/modalias:platform:thinkpad_acpi
/sys/bus/platform/devices/thinkpad_acpi/uevent:DRIVER=thinkpad_acpi
/sys/bus/platform/devices/thinkpad_acpi/uevent:MODALIAS=platform:thinkpad_acpi
/sys/bus/platform/devices/thinkpad_acpi/wakeup_hotunplug_complete:0
/sys/bus/platform/devices/thinkpad_acpi/wakeup_reason:0
/sys/bus/platform/devices/thinkpad_hwmon/fan1_input:2780
/sys/bus/platform/devices/thinkpad_hwmon/modalias:platform:thinkpad_hwmon
/sys/bus/platform/devices/thinkpad_hwmon/name:thinkpad
/sys/bus/platform/devices/thinkpad_hwmon/pwm1:255
/sys/bus/platform/devices/thinkpad_hwmon/pwm1_enable:2
/sys/bus/platform/devices/thinkpad_hwmon/temp10_input:49000
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp11_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp12_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp13_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp14_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp15_input: No such
device or address
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp16_input: No such
device or address
/sys/bus/platform/devices/thinkpad_hwmon/temp1_input:62000
/sys/bus/platform/devices/thinkpad_hwmon/temp2_input:56000
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp3_input: No such
device or address
/sys/bus/platform/devices/thinkpad_hwmon/temp4_input:58000
/sys/bus/platform/devices/thinkpad_hwmon/temp5_input:37000
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp6_input: No such
device or address
/sys/bus/platform/devices/thinkpad_hwmon/temp7_input:37000
grep: /sys/bus/platform/devices/thinkpad_hwmon/temp8_input: No such
device or address
/sys/bus/platform/devices/thinkpad_hwmon/temp9_input:46000
/sys/bus/platform/devices/thinkpad_hwmon/uevent:DRIVER=thinkpad_hwmon
/sys/bus/platform/devices/thinkpad_hwmon/uevent:MODALIAS=platform:thinkpad_hwmon

Re: Regression in thinkpad-acpi events

[Henrique de Moraes Holschuh]

> >> >> This can be observed by using the acpi_listen command. For instance, no
> >> >> ACPI events happen when swiveling the display, and the sleep button
> >> >> returns
> >> >>
> >> >>    button/sleep SBTN 00000080 00000000
> >> >>
> >> >> instead of the previous
> >> >>
> >> >>    ibm/hotkey HKEY 00000080 00001004
> >> >>
> 
> I'm observing the same, also with Arch Linux, and a ThinkPad x60:
> # uname -a
> Linux x60 3.1.1-1-ARCH #1 SMP PREEMPT Fri Nov 11 22:28:29 CET 2011
> x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux
> 
> The kernel config can be found here:
> <http://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux>.
> 
> As requested:
> # grep . /sys/bus/platform/devices/thinkpad*/*
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_enable:1
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_mask:0x008dffff
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_poll_freq:10
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_radio_sw:1
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_recommended_mask:0x008dffff
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_report_mode:1
> /sys/bus/platform/devices/thinkpad_acpi/hotkey_source_mask:0x00000000

Well, the driver has connected to the firmware, and should be working.  And
there were no changes to the code from v3.0 to v3.1.1.  So, it is either a
bug in something else, a problematic interaction of the driver with
something else, or a latent thinkpad-acpi bug that some change elsewhere has
exposed.

Are the events reported by acpi_listen from arch-linux exactly the same in
v3.0.9 and v3.1.1 ?  I know some events are missing in your v3.1.1, but I am
interested in the ones that do get reported.

Although you really should be using the input device for the hotkeys, and
not any of the 0x10xx events.  Those are driver-specific and deprecated, it
is all explained in Documentation/laptops/thinkpad-acpi.txt.  So, it really
might mean that you have something in userspace reading that input device
and synthesizing the ACPI HKEY events thinkpad-acpi deprecated for a long
time now.  I know some distros did that instead of switching to an
input-device-based hotkey daemon.  Please check for that possibility,
that daemon could be the one having problems with 3.1.1...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Regression in thinkpad-acpi events

[Tom Gundersen]

Hi Henrique,

On Wed, Nov 16, 2011 at 12:03 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
>> As requested:
>> # grep . /sys/bus/platform/devices/thinkpad*/*
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_enable:1
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_mask:0x008dffff
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_poll_freq:10
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_radio_sw:1
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_recommended_mask:0x008dffff
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_report_mode:1
>> /sys/bus/platform/devices/thinkpad_acpi/hotkey_source_mask:0x00000000
>
> Well, the driver has connected to the firmware, and should be working.  And
> there were no changes to the code from v3.0 to v3.1.1.  So, it is either a
> bug in something else, a problematic interaction of the driver with
> something else, or a latent thinkpad-acpi bug that some change elsewhere has
> exposed.
>
> Are the events reported by acpi_listen from arch-linux exactly the same in
> v3.0.9 and v3.1.1 ?  I know some events are missing in your v3.1.1, but I am
> interested in the ones that do get reported.
>
> Although you really should be using the input device for the hotkeys, and
> not any of the 0x10xx events.  Those are driver-specific and deprecated, it
> is all explained in Documentation/laptops/thinkpad-acpi.txt.  So, it really
> might mean that you have something in userspace reading that input device
> and synthesizing the ACPI HKEY events thinkpad-acpi deprecated for a long
> time now.  I know some distros did that instead of switching to an
> input-device-based hotkey daemon.  Please check for that possibility,
> that daemon could be the one having problems with 3.1.1...

It looks like my problem was something else. We don't do anything to
synthesize the ACPI HKEY events (AFAIK), so I believe that KDE (which
I am using) should be using the input events and that the HKEY stuff
does not matter.

I am still trying to figure out why my laptop does not always go to
sleep when I close my lid, but it turns out that I cannot reproduce it
reliably so it is taking me some time.

As to the original report about the change in HKEY events, this is
(probably) due to PROCFS_ACPI being disabled in the Arch kernel as of
3.1.

Cheers,

Tom

Re: Regression in thinkpad-acpi events

[Henrique de Moraes Holschuh]

On Thu, 24 Nov 2011, Tom Gundersen wrote:
> It looks like my problem was something else. We don't do anything to
> synthesize the ACPI HKEY events (AFAIK), so I believe that KDE (which
> I am using) should be using the input events and that the HKEY stuff
> does not matter.

I have no idea if KDE can do it or not.

> As to the original report about the change in HKEY events, this is
> (probably) due to PROCFS_ACPI being disabled in the Arch kernel as of
> 3.1.

Well, maybe Arch needs to update its userspace to cope with its kernel...
but still, we will only really know whether this is the problem or not if
someone checks the input devices and the acpi events over netlink in that
Arch kernel.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] Regression in thinkpad-acpi events

[Henning Schild]

I came across this problem after updating the kernel on my laptop. The
hotkeys actually work until after the first wakeup from hibernation. I
tried 3.0.9 3.1.1 3.1.2 and for hibernation i used tuxonice. It is not
only the acpi events that stop working, also the events that should be
delivered as input events. Reloading the module does not help. Having
the module not loaded for the hibernation also does not help. After
waking up the events will be gone.

Do the Arch kernels use tuxonice? Do you receive events before the
first hibernation?

Henning

Re: [ibm-acpi-devel] Regression in thinkpad-acpi events

[Natanji]

The standard Arch kernel does not use tuxonice, you need to build your
kernel manually if you want it. I also don't receive these events before
the first hibernation, so you might be having a different problem.

Concerning PROCFS_ACPI, a user posted over at the bug report in the Arch
bugtracker [1] that re-enabling this did not solve this problem. So the
problem probably lies somewhere else still...

[1] https://bugs.archlinux.org/task/26658#comment85971

On Sun 27 Nov 2011 02:23:46 AM CET, Henning Schild wrote:
> I came across this problem after updating the kernel on my laptop. The
> hotkeys actually work until after the first wakeup from hibernation. I
> tried 3.0.9 3.1.1 3.1.2 and for hibernation i used tuxonice. It is not
> only the acpi events that stop working, also the events that should be
> delivered as input events. Reloading the module does not help. Having
> the module not loaded for the hibernation also does not help. After
> waking up the events will be gone.
>
> Do the Arch kernels use tuxonice? Do you receive events before the
> first hibernation?
>
> Henning

Re: [ibm-acpi-devel] Regression in thinkpad-acpi events

[Henrique de Moraes Holschuh]

On Wed, 30 Nov 2011, Natanji wrote:
> The standard Arch kernel does not use tuxonice, you need to build your
> kernel manually if you want it. I also don't receive these events before
> the first hibernation, so you might be having a different problem.

Just a hunch: check /proc/interrupts.  One of them must be assigned to acpi,
and it *must* increase when you press hotkeys, etc.

Does it?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: [ibm-acpi-devel] Regression in thinkpad-acpi events

[Natanji]

Yes, there are dozens of acpi interrupts every second.

$ cat /proc/interrupts | grep acpi ; sleep 1; cat /proc/interrupts | 
grep acpi
  9:    1776309          0   IO-APIC-fasteoi   acpi
  9:    1776332          0   IO-APIC-fasteoi   acpi

On Wed 30 Nov 2011 12:15:07 PM CET, Henrique de Moraes Holschuh wrote:
> On Wed, 30 Nov 2011, Natanji wrote:
>> The standard Arch kernel does not use tuxonice, you need to build your
>> kernel manually if you want it. I also don't receive these events before
>> the first hibernation, so you might be having a different problem.
>
> Just a hunch: check /proc/interrupts.  One of them must be assigned to acpi,
> and it *must* increase when you press hotkeys, etc.
>
> Does it?
>