Re: [PATCH] amd-sfh-hid: tablet mode switch and asus quirk

[Basavaraj Natikar <bnatikar@amd.com>]

On 5/14/2026 1:29 PM, Helge Bahmann wrote:

> [You don't often get email from hcb@chaoticmind.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On Tue, 12 May 2026, Jiri Kosina wrote:
>> On Mon, 27 Apr 2026, Helge Bahmann wrote:
>>
>>> Add an input driver that interprets the "operation mode" sensor offered
>>> by the amd sfh on some laptop models.
>>>
>>> Add a quirk to make the driver work again with the Asus VivoBook
>>> VivoBook (turn off the "disable interrupts" flag).
>>>
>>> Expose the intr_disable flag as a module parameter in case it turns out
>>> to be needed on further laptop models.
>>>
>>> Signed-off-by: Helge Bahmann <hcb@chaoticmind.net>
>> Basavaraj, can you please review this one?
> Some additional context, maybe helpful for review:
>
> 1. The numbers and behavior were extracted from the ACPI tables
> (WMI driver of sorts) of the notebook; I don't have access to any
> official AMD / ASUS docs or similar.
>
> 2. I have an alternate version of this change that is more indirect:
> - create a HID driver providing an "abstract table mode" message
> - have an input driver attaching to this newly defined HID driver
>
> While that is keeping "more in line" with the current driver
> architecture, I am not sure this indirection really helps. Particularly,
> there is no "canonical" HID tablet mode switch message defined,
> so it all remains completely bespoke. I am happy to change it if
> you prefer, but would need your input.
>
> 3. Since this is based on Asus VivoBook and its ACPI tables,
> there is a possibility that this "op sensor / tablet mode" behavior
> is not as universal as I surmise. A point could be made to make this
> entire behavior model-dependent (with a mod param to override
> / activate for other models). Happy to take input / advice.

Thanks Helge.

I'd like to go with the dedicated input-driver approach (your option with
a standalone input driver) rather than the HID-message indirection -- it
keeps clean subsystem boundaries.

For splitting the work, either of these works for me -- whichever you
prefer:
   Option 1: I create the new input driver
   drivers/input/misc/amd_sfh_tabletmode.c and once done we will review your ASUS VivoBook
   quirk + intr_disable module-param patches on top of it.
   
   Option 2: If you'd rather keep ownership of it, you write
   drivers/input/misc/amd_sfh_tabletmode.c consuming the mode exposed by
   amd-sfh, and I'll review and help.
   

Let me know which option you'd like and I'll proceed.

Thanks,
--
Basavaraj