linux-kernel - Re: [PATCH] HID: i2c-hid: patch Lenovo Yoga Slim 7x Keyboard rdesc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <56l5tnplzap4mcqcridsavbtvbevhqd235m4m3h4ititj3j5p2@z6oy6wimoodv>
Date: Thu, 9 Oct 2025 10:29:19 +0200
From: Benjamin Tissoires <bentiss@...nel.org>
To: Lauri Tirkkonen <lauri@...ktheplanet.fi>
Cc: Jiri Kosina <jikos@...nel.org>, linux-input@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] HID: i2c-hid: patch Lenovo Yoga Slim 7x Keyboard rdesc

On Oct 09 2025, Lauri Tirkkonen wrote:
> Hi Benjamin,
> 
> On Thu, Oct 09 2025 09:38:50 +0200, Benjamin Tissoires wrote:
> > > diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
> > > index 63f46a2e5788..d78bd97ec24e 100644
> > > --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> > > +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> > 
> > Why patching i2c-hid-core when this is clearly a logical bug, not a
> > transport (I2C) bug?
> > 
> > I would rather see this fixup in hid-lenovo.c along with the other
> > lenovo fixes.
> 
> I'm not exactly familiar with HID; please bear with me :) If
> i2c-hid-core is not the correct place for this kind of thing, I can move
> it, but I'm going to need some guidance on where the correct place is.
> 
> This device uses hid-over-i2c, not hid-lenovo; I've got
> CONFIG_HID_LENOVO=m but the module is not even loaded. I don't see how
> putting the fixup in a module that does not attach to the device could
> work. So where should it go?

Well, the transport layer is i2c-hid, but the logical implementation is
in hid-generic which leverages the hid core default implementation.

In your case, you need to tell hid-lenovo to handle the device so we
stick to nice and tidy approach with each HID driver handling it's own
business.

Adding a line like the following will bind the keyboard part of the
device to hid-lenovo in lenovo_devices[]:
	{ HID_DEVICE(BUS_I2C, HID_GROUP_GENERIC,
		     USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_YOGA_SLIM_7X) },

If you don't use hid-multitouch on the same device you need a
HID_I2C_DEVICE() macro instead.

Once this is in, hid-lenovo.ko will bind to the device, and then we can
start fixing the report descriptor.

> 
> 	[  796.926931] input: hid-over-i2c 048D:8987 Keyboard as /devices/platform/soc@...c0000.geniqup/b80000.i2c/i2c-1/1-003a/0018:048D:8987.000F/input/input36
> 
> As a side note: apparently there is at least one other device in
> existence with a similar error in the report descriptor, which works
> fine on Windows:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=652f3d00de523a17b0cebe7b90debccf13aa8c31

Well, Windows is known for horrible hacks in their own generic layer,
but trying to mimmic them is sometimes harder than it looks :(
Especially because we also handle non Windows devices, and we might
break them while mimmicing Windows while our HID implementation is
currently rather "clean".

Cheers,
Benjamin

> 
> -- 
> Lauri Tirkkonen | lotheac @ IRCnet