lwn.git/drivers/platform/x86/intel-vbtn.c, branch docs-6.8-2

platform/x86: intel-vbtn: Move to intel sub-directory

2021-08-20T18:11:23+00:00

Move Intel vButton driver to intel sub-directory to improve readability. Signed-off-by: Kate Hsuan Reviewed-by: Hans de Goede Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210820110458.73018-19-andriy.shevchenko@linux.intel.com Signed-off-by: Hans de Goede

platform/x86: Add and use a dual_accel_detect() helper

2021-07-29T11:14:07+00:00

Various 360 degree hinges (yoga) style 2-in-1 devices use 2 accelerometers to allow the OS to determine the angle between the display and the base of the device. On Windows these are read by a special HingeAngleService process which calls undocumented ACPI methods, to let the firmware know if the 2-in-1 is in tablet- or laptop-mode. The firmware may use this to disable the kbd and touchpad to avoid spurious input in tablet-mode as well as to report SW_TABLET_MODE info to the OS. Since Linux does not call these undocumented methods, the SW_TABLET_MODE info reported by various pdx86 drivers is incorrect on these devices. Before this commit the intel-hid and thinkpad_acpi code already had 2 hardcoded checks for ACPI hardware-ids of dual-accel sensors to avoid reporting broken info. And now we also have a bug-report about the same problem in the intel-vbtn code. Since there are at least 3 different ACPI hardware-ids in play, add a new dual_accel_detect() helper which checks for all 3, rather then adding different hardware-ids to the drivers as bug-reports trickle in. Having shared code which checks all known hardware-ids is esp. important for the intel-hid and intel-vbtn drivers as these are generic drivers which are used on a lot of devices. The BOSC0200 hardware-id requires special handling, because often it is used for a single-accelerometer setup. Only in a few cases it refers to a dual-accel setup, in which case there will be 2 I2cSerialBus resources in the device's resource-list, so the helper checks for this. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=209011 Reported-and-tested-by: Julius Lehmann Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210729082134.6683-1-hdegoede@redhat.com

platform/x86: intel-vbtn: Remove unused KEYMAP_LEN define

2021-04-07T17:47:13+00:00

Now that we have 2 separate input_dev-s for the buttons and the switches, this is no longer used, remove it. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210325123255.73103-1-hdegoede@redhat.com

platform/x86: intel-vbtn: Stop reporting SW_DOCK events

2021-03-21T16:44:34+00:00

Stop reporting SW_DOCK events because this breaks suspend-on-lid-close. SW_DOCK should only be reported for docking stations, but all the DSDTs in my DSDT collection which use the intel-vbtn code, always seem to use this for 2-in-1s / convertibles and set SW_DOCK=1 when in laptop-mode (in tandem with setting SW_TABLET_MODE=0). This causes userspace to think the laptop is docked to a port-replicator and to disable suspend-on-lid-close, which is undesirable. Map the dock events to KEY_IGNORE to avoid this broken SW_DOCK reporting. Note this may theoretically cause us to stop reporting SW_DOCK on some device where the 0xCA and 0xCB intel-vbtn events are actually used for reporting docking to a classic docking-station / port-replicator but I'm not aware of any such devices. Also the most important thing is that we only report SW_DOCK when it reliably reports being docked to a classic docking-station without any false positives, which clearly is not the case here. If there is a chance of reporting false positives then it is better to not report SW_DOCK at all. Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210321163513.72328-1-hdegoede@redhat.com

platform/x86: intel-vbtn: Eval VBDL after registering our notifier

2021-01-25T20:34:36+00:00

The VBDL ACPI method enables button/switch reporting through the intel-vbtn device. In some cases the embedded-controller (EC) might call Notify() on the intel-vbtn device immediately after the the VBDL call to make sure that the OS is synced with the EC's button and switch state. If we register our notify_handler after evaluating VBDL this means that we might miss the Notify() calls made by the EC to sync the state. E.g. the HP Stream x360 Convertible PC 11 has a VGBS method which always returns 0, independent of the actual SW_TABLET_MODE state of the device; and immediately after the VBDL call it calls Notify(0xCD) or Notify(0xCC) to report the actual state. Move the evaluation of VBDL to after registering our notify_handler so that we don't miss any events. Cc: Elia Devito Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210115161850.117614-4-hdegoede@redhat.com

platform/x86: intel-vbtn: Add alternative method to enable switches

2021-01-25T20:34:32+00:00

Some 2-in-1s have a broken VGBS method, so we cannot get an initial state for the switches from them. Reporting the wrong initial state for SW_TABLET_MODE causes serious problems (touchpad and/or keyboard events being ignored by userspace when reporting SW_TABLET_MODE=1), so on these devices we cannot register an input-dev for the switches at probe time. We can however register an input-dev for the switches as soon as we receive the first switches event, because then we will know the state. Note this mirrors the behavior of recent changs to the intel-hid driver which also registers a separate switches input-dev on receiving the first event on machines with a broken VGBS method. Cc: Elia Devito Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210115161850.117614-3-hdegoede@redhat.com

platform/x86: intel-vbtn: Create 2 separate input-devs for buttons and switches

2021-01-25T20:34:28+00:00

Create 2 separate input-devs for buttons and switches, this is a preparation for dynamically registering the switches-input device for devices which are not on the switches allow-list, but do make Notify() calls with an event value from the switches sparse-keymap. This also brings the intel-vbtn driver inline with the intel-hid driver which is doing the same thing. Cc: Elia Devito Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210115161850.117614-2-hdegoede@redhat.com

platform/x86: intel-vbtn: Rework wakeup handling in notify_handler()

2021-01-25T20:34:18+00:00

Rework the wakeup path inside notify_handler() to special case the buttons (KE_KEY) case instead of the switches case. In case of a button wake event we want to skip reporting this, mirroring how the drivers/acpi/button.c code skips the reporting in the wakeup case (suspended flag set) too. The reason to skip reporting in this case is that some Linux desktop-environments will immediately resuspend if we report an evdev event for the power-button press on wakeup. Before this commit the skipping of the button-press was done in a round-about way: In case of a wakeup the regular sparse_keymap_report_event() would always be skipped by an early return, and then to avoid not reporting switch changes on wakeup there was a special KE_SW path with a duplicate sparse_keymap_report_event() call. This commit refactors the wakeup handling to explicitly skip the reporting for button wake events, while using the regular reporting path for non button (switches) wakeup events. No intentional functional impact. Cc: Elia Devito Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210115161850.117614-1-hdegoede@redhat.com

platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from allow-list

2021-01-18T18:26:44+00:00

THe HP Stream x360 Convertible PC 11 DSDT has the following VGBS function: Method (VGBS, 0, Serialized) { If ((^^PCI0.LPCB.EC0.ROLS == Zero)) { VBDS = Zero } Else { VBDS = Zero } Return (VBDS) /* \_SB_.VGBI.VBDS */ } Which is obviously wrong, because it always returns 0 independent of the 2-in-1 being in laptop or tablet mode. This causes the intel-vbtn driver to initially report SW_TABLET_MODE = 1 to userspace, which is known to cause problems when the 2-in-1 is actually in laptop mode. During earlier testing this turned out to not be a problem because the 2-in-1 would do a Notify(..., 0xCC) or Notify(..., 0xCD) soon after the intel-vbtn driver loaded, correcting the SW_TABLET_MODE state. Further testing however has shown that this Notify() soon after the intel-vbtn driver loads, does not always happen. When the Notify does not happen, then intel-vbtn reports SW_TABLET_MODE = 1 resulting in a non-working touchpad. IOW the tablet-mode reporting is not reliable on this device, so it should be dropped from the allow-list, fixing the touchpad sometimes not working. Fixes: 8169bd3e6e19 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting") Link: https://lore.kernel.org/r/20210114143432.31750-1-hdegoede@redhat.com Signed-off-by: Hans de Goede

platform/x86: intel-vbtn: Support for tablet mode on Dell Inspiron 7352

2021-01-04T14:54:45+00:00

The Dell Inspiron 7352 is a 2-in-1 model that has chassis-type "Notebook". Add this model to the dmi_switches_allow_list. Signed-off-by: Arnold Gozum Link: https://lore.kernel.org/r/20201226205307.249659-1-arngozum@gmail.com Signed-off-by: Hans de Goede