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?
[1] https://github.com/libratbag/libratbag/pull/1071
Cheers,
Filipe Laíns
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
On Wed, 2021-01-06 at 20:16 +0100, Hans de Goede wrote:
> Hi Filipe,
>
> 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
>
>
>
Great to know!
I have that device, I can try it out and send a patch if everything is working
correctly :)
The lightspeed receivers we support all have the DJ interface, these new ones do
not. But yeah, I think it should just work, or at least be simple to make it
work.
Cheers,
Filipe Laíns