linux-kernel - Re: (hid-logitech) Support for non-DJ receivers

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <308ef1e5-16ae-899f-9d89-d63f854b12bc@redhat.com>
Date:   Wed, 6 Jan 2021 20:16:56 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Filipe Laíns <filipe.lains@...il.com>,
        Jiri Kosina <jikos@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: (hid-logitech) Support for non-DJ receivers

Hi Filipe,

On 1/6/21 8:07 PM, Filipe Laíns wrote:
> Hey,
> 
> Some of the new Logitech receivers do not have the DJ interface, this creates an
> issue userspace applications like libratbag, as seen in [1], because we can't
> identify the device based on the hidraw PID.
> 
> There are two solutions for this:
> 
> 1) Implement device discovery via the internal Logitech ID in libratbag and all
> other userspace apps.
> 
> 2) Make hid-logitech-dj export a duplicated hidraw node with internal Logitech
> ID as PID, just like it does for the DJ interface.
> 
> In case you aren't aware of what the DJ interface is, it is essentially a
> multiplexing protocol that receivers support. 6 devices could be connected to
> the same receiver, hid-logitech-dj enables the DJ mode and the receiver will
> essentially perpend the device ID to each HID report. hid-logitech-dj then
> creates a HID device for each connected device and routes the HID reports to the
> correspondent HID device.
> 
> Option 2) would be the easier on userspace, as it keeps the same interface we
> use for DJ receivers for other Logitech HID++ receivers and avoids all userspace
> apps to have to reimplement the same discovery logic.
> 
> Any thoughts?

hid-logitech-dj already supports exposing devices behind a non-DJ / non-unifying
receiver as separate HID child-devices of the receiver as we doe for DJ devices.

ATM hid-logitech-dj does not yet support the c541 PID receiver, but with some
luck that could be as simple as adding this patch to the kernel:

diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 1ffcfc9a1e03..ee7051f3c926 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1877,6 +1877,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
 	  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
 		USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1),
 	 .driver_data = recvr_type_gaming_hidpp},
+	{ /* Logitech lightspeed receiver (0xc541) */
+	  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+		0xc541),
+	 .driver_data = recvr_type_gaming_hidpp},
 	{ /* Logitech 27 MHz HID++ 1.0 receiver (0xc513) */
 	  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER),
 	 .driver_data = recvr_type_27mhz},

Where the second 0xc541 should really be a
USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_2 define in hid-ids.h, but we
can fix that when upstreaming this.

For now if you can get the reporter of the bug to build a kernel with the
above change and test that, then that would be great. If things do not work
OOTB with this change, then we may need to do some additional work on
the kernel side, but we do already support lightspeed receivers, so
we should be able to add support for this new model too.

Regards,

Hans

[1] https://github.com/libratbag/libratbag/pull/1071