Bug 204763 - Powerbutton press not recognized on Lenovo X1 Tablet 2nd gen
Summary: Powerbutton press not recognized on Lenovo X1 Tablet 2nd gen
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: ACPI
Classification: Unclassified
Component: EC (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: acpi_ec
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-03 18:58 UTC by Jannis Schmidt
Modified: 2021-02-23 07:47 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.2.11
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Original DSDT file (168.68 KB, application/octet-stream)
2019-09-03 18:58 UTC, Jannis Schmidt
Details

Description Jannis Schmidt 2019-09-03 18:58:08 UTC
Created attachment 284809 [details]
Original DSDT file

Pressing the powerbutton of the tablet device does not get registered or handled by the system. There is no event dispatched as confirmed via acpi_listen.

You can get it to work for sleep, but not wakeup when you set the kernel parameters "acpi_osi" and "acpi_os_name" to "Linux", but it breaks the digitizer (and possibly more) by doing so.

By extracting and disassembling the DSDT I was able to narrow it down to the variable "\_SB.PWRB.PBST" being set to 0x00 and all further checks for the powerbutton fall through.

Here is my rigged version of the code dsdt.dsl I am able to recompile and it does indeed provide the functionality: https://gist.github.com/jschmidt-1/43f39d680df00b92a0025568ac957d56

Additionally here is the dmesg output: http://ix.io/1Ubn

Since I do not know how to properly create a patch for the kernel and how to fix the underlying issue I am opening this ticket.
Comment 1 Zhang Rui 2019-09-09 03:38:42 UTC
please confirm
1. does your kernel have CONFIG_INTEL_VBTN set?
2. if no, does the original DSDT works well with CONFIG_INTEL_VBTN set?
Comment 2 Jannis Schmidt 2019-09-09 18:49:54 UTC
It is compiled as a module and the module intel_vbtn is loaded. Without the modified DSDT it does not work as described above.
Same result with the newer kernel 5.2.13 I tested just after.
Comment 3 Zhang Rui 2019-12-30 02:01:22 UTC
                Method (VBDL, 0, Serialized)
                {
                    ADBG ("VBDL")
                    PB1E |= 0x20
                    ADBG ("VBDL EN")
                    If (CondRefOf (\_SB.PWRB.PBST))
                    {
                        \_SB.PWRB.PBST = 0x00
                        Notify (\_SB.PWRB, 0x01) // Device Check
                    }

                    VBTN = 0x01
                    \_SB.PCI0.LPCB.EC.B10E = 0x01
                    RSDE = 0x01
                }

when PBST is set, we're using ACPI Power Button, PWRB._STA returns present, and notifications are sent to PWRB device.
when PBST is cleared, PWRB is gone and the power button events are sent to another device,
        Method (_Q75, 0, NotSerialized)  // _Qxx: EC Query, xx=0x00-0xFF
        {
            If (((OSYS >= 0x07DF) && \_SB.HIDD.BTLD))
            {
                ADBG ("Notify _HID 0xCE")
                Notify (\_SB.HIDD, 0xCE) // Hardware-Specific
            }
            ElseIf ((\_SB.PWRB.PBST == 0x01))
            {
                Notify (\_SB.PWRB, 0x80) // Status Change
                \_SB.PWRB.PBLV = 0x01
            }
        }
            Device (HIDD)
            {
                Name (_HID, "INT33D5")  // _HID: Hardware ID
                ...
            }
HIDD is the intel-hid device, so please make sure if you have intel-hid driver is built or not (CONFIG_INTEL_HID_EVENT).
Comment 4 Zhang Rui 2020-06-29 09:58:03 UTC
Bug closed as there is no response from the bug reporter.
Please feel free to reopen it if the problem still exists in latest upstream kernel.
Comment 5 Alexander Kobel 2021-02-22 11:55:50 UTC
Still relevant on 5.10.16.

intel-hid doesn't help, either: similar to intel-vbtn (which works nicely for the functions it supports), it's built as a module and loaded by default on my machine, but doesn't help.
Comment 6 Alexander Kobel 2021-02-23 07:47:25 UTC
Amazing community. Few minutes later, Alban Bedel produced this:
https://lore.kernel.org/platform-driver-x86/20210222141559.3775-1-albeu@free.fr/

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