Re: [PATCH v5] platform/x86/lenovo: Add Yoga Book 9 keyboard dock detection driver

[johannes.goede@oss.qualcomm.com]

Hi Dave,

On 8-Jun-26 14:52, Dave Carey wrote:
> On 08-Jun-26 11:13, Hans de Goede wrote:
>> Dave, I see that your "[PATCH v5] platform/x86/lenovo: Add Yoga Book 9 keyboard
>> dock detection driver" patch also uses a DMI match, is that necessary ?
>>
>> If we need the DMI match because the GUID is not unique enough, then we might
>> just as well add this functionality here as this patch is doing ...
> 
> Yes, the DMI match is necessary, specifically for the block GUID
> (E7F300FA, LENOVO_FEATURE_STATUS_DATA). This is a generic Lenovo feature
> query interface that may appear on other Lenovo machines for unrelated
> purposes. Both GUIDs live under a PNP0C14 device with _UID "GMZN" on
> this machine, which is firmware-specific, but the WMI core matches by
> GUID alone — not by parent device UID. Without the DMI guard the block
> driver could bind on unrelated hardware and misinterpret WQAF's return
> value as a BKBD field.
> 
> The event GUID (806BD2A2, LENOVO_BTKBD_EVENT) is named specifically for
> Bluetooth keyboard events in the BMOF and is likely unique to BT keyboard
> dock hardware, but keeping the DMI guard on both drivers is the safe choice
> given we can't easily verify all Lenovo platforms.
> 
>> I do wonder since this seems to emit TP_HKEY_EV_TABLET_CHANGED thinkpad_acpi
>> events if the existing thinkpad_acpi support does not already provide working
>> SW_TABLET_MODE input ?
>>
>> If it does then also having the WMI driver emit SW_TABLET_MODE events seems
>> to be undesirable duplicate functionality.
> 
> Tested: no overlap. On the YB9 the existing SW_TABLET_MODE source is
> lenovo-ymc (not thinkpad_acpi).

Hmm, interesting not having thinkpad_acpi on a (non ThinkPad) Yoga makes
sense. Let me double check if this driver really is duplicate with
the thinkpad_acpi patch from pit:

https://patchwork.kernel.org/project/platform-driver-x86/patch/20260419102724.91451-1-pithenrich2d@gmail.com/

Ok, I should have looked closer, that one if for a "ThinkPad X1 Fold 16 Gen 1"
and yours is for the "Yoga Book 9" so I was mistaken that these drivers are
duplicate, we will need both, my bad.

That does bring the question if we want to unify the userspace interface,
but the 2 setups seem to be different enough that having a single unified
userspace interface also seems unnecessary.

The yoga book 9 has a keyboard which as your driver reports can either
cover the bottom or top half of the bottom screen, where as the
"ThinkPad X1 Fold 16 Gen 1" has a keyboard trackpad combo which covers
the whole bottom screen (*) when attached to the screen.

*) bottom screen half as it is a single big screen

> The YMC driver tracks hinge/orientation
> modes (clamshell=0, tent/tablet/stand=1) — it does not track BT keyboard
> attachment state. I ran evtest on both the lenovo-ymc and yb9-kbdock input
> devices while detaching and reattaching the keyboard: lenovo-ymc did not
> fire at all; only yb9-kbdock emitted SW_TABLET_MODE events. There is no
> duplicate functionality.

Hmm, so lenovo-ymc does load and create a /dev/input/event# nodes with
a SW_TABLET_MODE switch reported as being present ?

That is a problem because for switches unlike keys the mere presence
of them has meaning. E.g GNOME will read the SW_TABLET_MODE switch
value at GNOME start and use that to decide if it should start in tablet
or regular=clamshell/desktop mode. So the mere presence of a SW_* style
evdev node can cause behavior changes.

And userspace really does not expect there to be 2 evdev nodes which
both report SW_TABLET_MODE. So I think we need a patch to the lenovo-ymc
driver to exit probe() early (with return 0) when loading on the
yoga book 9 to avoid there being 2 SW_TABLET_MODE reporting input devices.

Regards,

Hans