* Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels
@ 2021-03-10 18:55 Mark Hounschell
2021-03-10 19:56 ` Filipe Laíns
0 siblings, 1 reply; 7+ messages in thread
From: Mark Hounschell @ 2021-03-10 18:55 UTC (permalink / raw)
To: lains, Jiri Kosina, sashal, Linux-kernel
I have been using a Logitech wireless G602 mouse since forever. As of
kernel 5.10.11 I get the following kernel messages;
$dmesg | grep -i logitech
[ 7.102140] usb 3-3.4: Manufacturer: Logitech
[ 10.036763] input: Logitech USB Receiver as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.0/0003:046D:C537.0001/input/input10
[ 10.037904] hid-generic 0003:046D:C537.0001: input,hidraw0: USB HID
v1.11 Mouse [Logitech USB Receiver] on usb-0000:16:00.3-3.4/input0
[ 10.039542] input: Logitech USB Receiver Keyboard as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/input/input11
[ 10.092374] input: Logitech USB Receiver Consumer Control as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/input/input12
[ 10.093726] input: Logitech USB Receiver System Control as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/input/input13
[ 10.094924] input: Logitech USB Receiver as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/input/input16
[ 10.096155] hid-generic 0003:046D:C537.0002: input,hiddev96,hidraw1:
USB HID v1.11 Keyboard [Logitech USB Receiver] on
usb-0000:16:00.3-3.4/input1
[ 10.121557] logitech-djreceiver 0003:046D:C537.0001: hidraw0: USB HID
v1.11 Mouse [Logitech USB Receiver] on usb-0000:16:00.3-3.4/input0
[ 10.264445] logitech-djreceiver 0003:046D:C537.0002:
hiddev96,hidraw1: USB HID v1.11 Keyboard [Logitech USB Receiver] on
usb-0000:16:00.3-3.4/input1
[ 10.320315] logitech-djreceiver 0003:046D:C537.0002: device of type
eQUAD step 4 Gaming (0x07) connected on slot 1
[ 10.321505] input: Logitech Wireless Mouse PID:402c Mouse as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/0003:046D:402C.0003/input/input17
[ 10.322637] hid-generic 0003:046D:402C.0003: input,hidraw2: USB HID
v1.11 Mouse [Logitech Wireless Mouse PID:402c] on
usb-0000:16:00.3-3.4/input1:1
[ 10.360344] input: Logitech G602 as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/0003:046D:402C.0003/input/input21
[ 10.361537] logitech-hidpp-device 0003:046D:402C.0003: input,hidraw2:
USB HID v1.11 Mouse [Logitech G602] on usb-0000:16:00.3-3.4/input1:1
[ 23.271323] logitech-hidpp-device 0003:046D:402C.0003: HID++ 2.0
device connected.
[ 36.471326] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 36.565317] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 42.390321] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 42.478325] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 42.771318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 42.859318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 42.955318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.049318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.105317] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.200317] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.280318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.375321] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.455318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.558317] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.638318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.741319] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.812319] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 43.916318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 44.003318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
[ 44.106318] logitech-djreceiver 0003:046D:C537.0002: Unexpected input
report number 128
.
.
.
Every mouse event seems to produce another "Unexpected input report
number 128" kernel message.
The commit that started this is:
commit 1e6fc9768ed2c3917e1fd7af26cb194dfe14f7da
Author: Filipe LaÃns <lains@archlinux.org>
Date: Mon Jan 4 20:47:17 2021 +0000
HID: logitech-dj: add the G602 receiver
[ Upstream commit e400071a805d6229223a98899e9da8c6233704a1 ]
Tested. The device gets correctly exported to userspace and I can see
mouse and keyboard events.
Signed-off-by: Filipe LaÃns <lains@archlinux.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
The actual patch:
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 1ffcfc9a1e033..45e7e0bdd382b 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -1869,6 +1869,10 @@ static const struct hid_device_id
logi_dj_receivers[] = {
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
0xc531),
.driver_data = recvr_type_gaming_hidpp},
+ { /* Logitech G602 receiver (0xc537) */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+ 0xc537),
+ .driver_data = recvr_type_gaming_hidpp},
{ /* Logitech lightspeed receiver (0xc539) */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1),
markh@harley:~> lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 046d:c537 Logitech, Inc.
Bus 003 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
With the patch reverted:
$dmesg | grep -i logitech
[ 6.748821] usb 3-3.4: Manufacturer: Logitech
[ 9.738428] input: Logitech USB Receiver as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.0/0003:046D:C537.0001/input/input10
[ 9.738605] hid-generic 0003:046D:C537.0001: input,hidraw0: USB HID
v1.11 Mouse [Logitech USB Receiver] on usb-0000:16:00.3-3.4/input0
[ 9.740277] input: Logitech USB Receiver Keyboard as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/input/input11
[ 9.794321] input: Logitech USB Receiver Consumer Control as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/input/input12
[ 9.795535] input: Logitech USB Receiver System Control as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/input/input13
[ 9.795565] input: Logitech USB Receiver as
/devices/pci0000:00/0000:00:08.1/0000:16:00.3/usb3/3-3/3-3.4/3-3.4:1.1/0003:046D:C537.0002/input/input16
[ 9.795624] hid-generic 0003:046D:C537.0002: input,hiddev96,hidraw1:
USB HID v1.11 Keyboard [Logitech USB Receiver] on
usb-0000:16:00.3-3.4/input1
$lsusb
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 046d:c537 Logitech, Inc.
Bus 003 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
With or without the patch and error messages the mouse has always worked.
Regards
Mark
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels
2021-03-10 18:55 Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels Mark Hounschell
@ 2021-03-10 19:56 ` Filipe Laíns
2021-03-10 20:24 ` Mark Hounschell
0 siblings, 1 reply; 7+ messages in thread
From: Filipe Laíns @ 2021-03-10 19:56 UTC (permalink / raw)
To: markh, Jiri Kosina, sashal, Linux-kernel
[-- Attachment #1: Type: text/plain, Size: 4767 bytes --]
On Wed, 2021-03-10 at 13:55 -0500, Mark Hounschell wrote:
> I have been using a Logitech wireless G602 mouse since forever. As of
> kernel 5.10.11 I get the following kernel messages;
>
>
> $dmesg | grep -i logitech
(snip)
> .
> .
> .
> Every mouse event seems to produce another "Unexpected input report
> number 128" kernel message.
>
> The commit that started this is:
>
> commit 1e6fc9768ed2c3917e1fd7af26cb194dfe14f7da
> Author: Filipe LaÃns <lains@archlinux.org>
> Date: Mon Jan 4 20:47:17 2021 +0000
>
> HID: logitech-dj: add the G602 receiver
>
> [ Upstream commit e400071a805d6229223a98899e9da8c6233704a1 ]
>
> Tested. The device gets correctly exported to userspace and I can see
> mouse and keyboard events.
>
> Signed-off-by: Filipe LaÃns <lains@archlinux.org>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
>
> The actual patch:
>
> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> index 1ffcfc9a1e033..45e7e0bdd382b 100644
> --- a/drivers/hid/hid-logitech-dj.c
> +++ b/drivers/hid/hid-logitech-dj.c
> @@ -1869,6 +1869,10 @@ static const struct hid_device_id
> logi_dj_receivers[] = {
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> 0xc531),
> .driver_data = recvr_type_gaming_hidpp},
> + { /* Logitech G602 receiver (0xc537) */
> + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> + 0xc537),
> + .driver_data = recvr_type_gaming_hidpp},
> { /* Logitech lightspeed receiver (0xc539) */
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1),
>
>
>
> markh@harley:~> lsusb
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 003: ID 046d:c537 Logitech, Inc.
> Bus 003 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
>
>
> With the patch reverted:
>
> $dmesg | grep -i logitech
(snip)
>
> $lsusb
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 003: ID 046d:c537 Logitech, Inc.
> Bus 003 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
> With or without the patch and error messages the mouse has always worked.
>
> Regards
> Mark
Yes, sorry about that. The following patch should fix it, can you confirm?
You probably didn't notice any breakage because you do not have any of your
buttons bound to keyboard events.
commit ef07c116d98772952807492bd32a61f5af172a94 (hid/for-5.11/upstream-fixes)
Author: Filipe Laíns <lains@riseup.net>
Date: Fri Feb 5 14:34:44 2021 +0000
HID: logitech-dj: add support for keyboard events in eQUAD step 4 Gaming
In e400071a805d6229223a98899e9da8c6233704a1 I added support for the
receiver that comes with the G602 device, but unfortunately I screwed up
during testing and it seems the keyboard events were actually not being
sent to userspace.
This resulted in keyboard events being broken in userspace, please
backport the fix.
The receiver uses the normal 0x01 Logitech keyboard report descriptor,
as expected, so it is just a matter of flagging it as supported.
Reported in
https://github.com/libratbag/libratbag/issues/1124
Fixes: e400071a805d6 ("HID: logitech-dj: add the G602 receiver")
Cc: <stable@vger.kernel.org>
Signed-off-by: Filipe Laíns <lains@riseup.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 45e7e0bdd382..fcdc922bc973 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -980,6 +980,7 @@ static void logi_hidpp_recv_queue_notif(struct hid_device
*hdev,
case 0x07:
device_type = "eQUAD step 4 Gaming";
logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
+ workitem.reports_supported |= STD_KEYBOARD;
break;
case 0x08:
device_type = "eQUAD step 4 for gamepads";
Cheers,
Filipe Laíns
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels
2021-03-10 19:56 ` Filipe Laíns
@ 2021-03-10 20:24 ` Mark Hounschell
2021-03-10 20:49 ` Mark Hounschell
2021-03-10 20:55 ` Filipe Laíns
0 siblings, 2 replies; 7+ messages in thread
From: Mark Hounschell @ 2021-03-10 20:24 UTC (permalink / raw)
To: Filipe Laíns, Jiri Kosina, sashal, Linux-kernel
On 3/10/21 2:56 PM, Filipe Laíns wrote:
> On Wed, 2021-03-10 at 13:55 -0500, Mark Hounschell wrote:
>> I have been using a Logitech wireless G602 mouse since forever. As of
>> kernel 5.10.11 I get the following kernel messages;
>>
>>
>> $dmesg | grep -i logitech
> (snip)
>> .
>> .
>> .
>> Every mouse event seems to produce another "Unexpected input report
>> number 128" kernel message.
>>
>> The commit that started this is:
>>
>> commit 1e6fc9768ed2c3917e1fd7af26cb194dfe14f7da
>> Author: Filipe LaÃns <lains@archlinux.org>
>> Date: Mon Jan 4 20:47:17 2021 +0000
>>
>> HID: logitech-dj: add the G602 receiver
>>
>> [ Upstream commit e400071a805d6229223a98899e9da8c6233704a1 ]
>>
>> Tested. The device gets correctly exported to userspace and I can see
>> mouse and keyboard events.
>>
>> Signed-off-by: Filipe LaÃns <lains@archlinux.org>
>> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>
>> The actual patch:
>>
>> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
>> index 1ffcfc9a1e033..45e7e0bdd382b 100644
>> --- a/drivers/hid/hid-logitech-dj.c
>> +++ b/drivers/hid/hid-logitech-dj.c
>> @@ -1869,6 +1869,10 @@ static const struct hid_device_id
>> logi_dj_receivers[] = {
>> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
>> 0xc531),
>> .driver_data = recvr_type_gaming_hidpp},
>> + { /* Logitech G602 receiver (0xc537) */
>> + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
>> + 0xc537),
>> + .driver_data = recvr_type_gaming_hidpp},
>> { /* Logitech lightspeed receiver (0xc539) */
>> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
>> USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1),
>>
>>
>>
>> markh@harley:~> lsusb
>> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>> Bus 003 Device 003: ID 046d:c537 Logitech, Inc.
>> Bus 003 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
>> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>
>>
>>
>> With the patch reverted:
>>
>> $dmesg | grep -i logitech
> (snip)
>>
>> $lsusb
>> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>> Bus 003 Device 003: ID 046d:c537 Logitech, Inc.
>> Bus 003 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
>> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>
>> With or without the patch and error messages the mouse has always worked.
>>
>> Regards
>> Mark
>
> Yes, sorry about that. The following patch should fix it, can you confirm?
> You probably didn't notice any breakage because you do not have any of your
> buttons bound to keyboard events.
>
>
> commit ef07c116d98772952807492bd32a61f5af172a94 (hid/for-5.11/upstream-fixes)
> Author: Filipe Laíns <lains@riseup.net>
> Date: Fri Feb 5 14:34:44 2021 +0000
>
> HID: logitech-dj: add support for keyboard events in eQUAD step 4 Gaming
>
> In e400071a805d6229223a98899e9da8c6233704a1 I added support for the
> receiver that comes with the G602 device, but unfortunately I screwed up
> during testing and it seems the keyboard events were actually not being
> sent to userspace.
> This resulted in keyboard events being broken in userspace, please
> backport the fix.
>
> The receiver uses the normal 0x01 Logitech keyboard report descriptor,
> as expected, so it is just a matter of flagging it as supported.
>
> Reported in
> https://github.com/libratbag/libratbag/issues/1124
>
> Fixes: e400071a805d6 ("HID: logitech-dj: add the G602 receiver")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Filipe Laíns <lains@riseup.net>
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>
> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> index 45e7e0bdd382..fcdc922bc973 100644
> --- a/drivers/hid/hid-logitech-dj.c
> +++ b/drivers/hid/hid-logitech-dj.c
> @@ -980,6 +980,7 @@ static void logi_hidpp_recv_queue_notif(struct hid_device
> *hdev,
> case 0x07:
> device_type = "eQUAD step 4 Gaming";
> logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);
> + workitem.reports_supported |= STD_KEYBOARD;
> break;
> case 0x08:
> device_type = "eQUAD step 4 for gamepads";
>
>
That is correct, I don't have any buttons bound to keyboard events. With
the original patch the G4(forward) and G5(Backward) buttons work in a
browser. I guess G7, G8, and G9 buttons are programmable to keyboard events?
However this patch does not seem to fix the messages I get.
Regards
Mark
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels
2021-03-10 20:24 ` Mark Hounschell
@ 2021-03-10 20:49 ` Mark Hounschell
2021-03-10 20:55 ` Filipe Laíns
1 sibling, 0 replies; 7+ messages in thread
From: Mark Hounschell @ 2021-03-10 20:49 UTC (permalink / raw)
To: Filipe Laíns, Jiri Kosina, sashal, Linux-kernel
On 3/10/21 3:24 PM, Mark Hounschell wrote:
> On 3/10/21 2:56 PM, Filipe Laíns wrote:
>> On Wed, 2021-03-10 at 13:55 -0500, Mark Hounschell wrote:
>>> I have been using a Logitech wireless G602 mouse since forever. As of
>>> kernel 5.10.11 I get the following kernel messages;
>>>
>>>
>>> $dmesg | grep -i logitech
>> (snip)
>>> .
>>> .
>>> .
>>> Every mouse event seems to produce another "Unexpected input report
>>> number 128" kernel message.
>>>
>>> The commit that started this is:
>>>
>>> commit 1e6fc9768ed2c3917e1fd7af26cb194dfe14f7da
>>> Author: Filipe LaÃns <lains@archlinux.org>
>>> Date: Mon Jan 4 20:47:17 2021 +0000
>>>
>>> HID: logitech-dj: add the G602 receiver
>>>
>>> [ Upstream commit e400071a805d6229223a98899e9da8c6233704a1 ]
>>>
>>> Tested. The device gets correctly exported to userspace and I
>>> can see
>>> mouse and keyboard events.
>>>
>>> Signed-off-by: Filipe LaÃns <lains@archlinux.org>
>>> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>>
>>> The actual patch:
>>>
>>> diff --git a/drivers/hid/hid-logitech-dj.c
>>> b/drivers/hid/hid-logitech-dj.c
>>> index 1ffcfc9a1e033..45e7e0bdd382b 100644
>>> --- a/drivers/hid/hid-logitech-dj.c
>>> +++ b/drivers/hid/hid-logitech-dj.c
>>> @@ -1869,6 +1869,10 @@ static const struct hid_device_id
>>> logi_dj_receivers[] = {
>>> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
>>> 0xc531),
>>> .driver_data = recvr_type_gaming_hidpp},
>>> + { /* Logitech G602 receiver (0xc537) */
>>> + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
>>> + 0xc537),
>>> + .driver_data = recvr_type_gaming_hidpp},
>>> { /* Logitech lightspeed receiver (0xc539) */
>>> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
>>> USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1),
>>>
>>>
>>>
>>> markh@harley:~> lsusb
>>> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>>> Bus 003 Device 003: ID 046d:c537 Logitech, Inc.
>>> Bus 003 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
>>> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>
>>>
>>>
>>> With the patch reverted:
>>>
>>> $dmesg | grep -i logitech
>> (snip)
>>>
>>> $lsusb
>>> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>>> Bus 003 Device 003: ID 046d:c537 Logitech, Inc.
>>> Bus 003 Device 002: ID 0424:2504 Standard Microsystems Corp. USB 2.0 Hub
>>> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>>>
>>> With or without the patch and error messages the mouse has always
>>> worked.
>>>
>>> Regards
>>> Mark
>>
>> Yes, sorry about that. The following patch should fix it, can you
>> confirm?
>> You probably didn't notice any breakage because you do not have any of
>> your
>> buttons bound to keyboard events.
>>
>>
>> commit ef07c116d98772952807492bd32a61f5af172a94
>> (hid/for-5.11/upstream-fixes)
>> Author: Filipe Laíns <lains@riseup.net>
>> Date: Fri Feb 5 14:34:44 2021 +0000
>>
>> HID: logitech-dj: add support for keyboard events in eQUAD step 4
>> Gaming
>>
>> In e400071a805d6229223a98899e9da8c6233704a1 I added support for the
>> receiver that comes with the G602 device, but unfortunately I
>> screwed up
>> during testing and it seems the keyboard events were actually not
>> being
>> sent to userspace.
>> This resulted in keyboard events being broken in userspace, please
>> backport the fix.
>>
>> The receiver uses the normal 0x01 Logitech keyboard report
>> descriptor,
>> as expected, so it is just a matter of flagging it as supported.
>>
>> Reported in
>> https://github.com/libratbag/libratbag/issues/1124
>>
>> Fixes: e400071a805d6 ("HID: logitech-dj: add the G602 receiver")
>> Cc: <stable@vger.kernel.org>
>> Signed-off-by: Filipe Laíns <lains@riseup.net>
>> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
>>
>> diff --git a/drivers/hid/hid-logitech-dj.c
>> b/drivers/hid/hid-logitech-dj.c
>> index 45e7e0bdd382..fcdc922bc973 100644
>> --- a/drivers/hid/hid-logitech-dj.c
>> +++ b/drivers/hid/hid-logitech-dj.c
>> @@ -980,6 +980,7 @@ static void logi_hidpp_recv_queue_notif(struct
>> hid_device
>> *hdev,
>> case 0x07:
>> device_type = "eQUAD step 4 Gaming";
>> logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report,
>> &workitem);
>> + workitem.reports_supported |= STD_KEYBOARD;
>> break;
>> case 0x08:
>> device_type = "eQUAD step 4 for gamepads";
>>
>>
>
> That is correct, I don't have any buttons bound to keyboard events. With
> the original patch the G4(forward) and G5(Backward) buttons work in a
> browser. I guess G7, G8, and G9 buttons are programmable to keyboard
> events?
>
> However this patch does not seem to fix the messages I get.
>
Actually is not this patch already in a 5.10.21 kernel?
Mark
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels
2021-03-10 20:24 ` Mark Hounschell
2021-03-10 20:49 ` Mark Hounschell
@ 2021-03-10 20:55 ` Filipe Laíns
2021-03-10 21:48 ` Hans de Goede
1 sibling, 1 reply; 7+ messages in thread
From: Filipe Laíns @ 2021-03-10 20:55 UTC (permalink / raw)
To: markh, Jiri Kosina, sashal, Linux-kernel, Hans de Goede
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
On Wed, 2021-03-10 at 15:24 -0500, Mark Hounschell wrote:
>
> That is correct, I don't have any buttons bound to keyboard events. With
> the original patch the G4(forward) and G5(Backward) buttons work in a
> browser. I guess G7, G8, and G9 buttons are programmable to keyboard events?
>
> However this patch does not seem to fix the messages I get.
>
> Regards
> Mark
Those events belong to the USB HID button usage page and are sent by the
receiver in the HID device with the unnumbered report descriptor, so they are
not affected.
Looking at the report descriptor for the other HID device, I see a report ID of
128 (0x80) used for a vendor application, I am not really sure what it is used
for and can't seem to trigger my device to send it.
I am gonna guess this is the device reporting the pressed buttons via vendor
reports or something like that. Speaking as the person who added support for
this device in libratbag, this report is very likely not something that we don't
need in our custom drivers and just likely something extra that Logitech built
to achieve something custom in the Windows driver. FWIW, this device is a very
weird one, it does not even follow Logitech's own spec :P
Seeing this report the driver chugs.
if (report > REPORT_TYPE_RFREPORT_LAST) {
hid_err(hdev, "Unexpected input report number %d\n", report);
return;
}
Causing your
[ 36.471326] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
[ 36.565317] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
[ 42.390321] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
I feel like the correct fix for these cases is not to consume the report and not
forward it to device node, but rather to forward it to the receiver node.
(looping in Hans)
Hans, you introduced this code, do you remember why? Where did
REPORT_TYPE_RFREPORT_LAST get its value from and what is the purpose of this
check?
Shouldn't we just keep forwarding unknown reports to the receiver node? Is there
any technical limitation to do that? I am not too familiar with this part of the
code.
Cheers,
Filipe Laíns
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels
2021-03-10 20:55 ` Filipe Laíns
@ 2021-03-10 21:48 ` Hans de Goede
2021-03-11 17:39 ` Mark Hounschell
0 siblings, 1 reply; 7+ messages in thread
From: Hans de Goede @ 2021-03-10 21:48 UTC (permalink / raw)
To: Filipe Laíns, markh, Jiri Kosina, sashal, Linux-kernel
Hi,
On 3/10/21 9:55 PM, Filipe Laíns wrote:
> On Wed, 2021-03-10 at 15:24 -0500, Mark Hounschell wrote:
>>
>> That is correct, I don't have any buttons bound to keyboard events. With
>> the original patch the G4(forward) and G5(Backward) buttons work in a
>> browser. I guess G7, G8, and G9 buttons are programmable to keyboard events?
>>
>> However this patch does not seem to fix the messages I get.
>>
>> Regards
>> Mark
>
> Those events belong to the USB HID button usage page and are sent by the
> receiver in the HID device with the unnumbered report descriptor, so they are
> not affected.
>
> Looking at the report descriptor for the other HID device, I see a report ID of
> 128 (0x80) used for a vendor application, I am not really sure what it is used
> for and can't seem to trigger my device to send it.
>
> I am gonna guess this is the device reporting the pressed buttons via vendor
> reports or something like that. Speaking as the person who added support for
> this device in libratbag, this report is very likely not something that we don't
> need in our custom drivers and just likely something extra that Logitech built
> to achieve something custom in the Windows driver. FWIW, this device is a very
> weird one, it does not even follow Logitech's own spec :P
>
> Seeing this report the driver chugs.
>
> if (report > REPORT_TYPE_RFREPORT_LAST) {
> hid_err(hdev, "Unexpected input report number %d\n", report);
> return;
> }
>
> Causing your
>
> [ 36.471326] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
> [ 36.565317] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
> [ 42.390321] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
>
> I feel like the correct fix for these cases is not to consume the report and not
> forward it to device node, but rather to forward it to the receiver node.
>
> (looping in Hans)
> Hans, you introduced this code, do you remember why? Where did
> REPORT_TYPE_RFREPORT_LAST get its value from and what is the purpose of this
> check?
> Shouldn't we just keep forwarding unknown reports to the receiver node? Is there
> any technical limitation to do that? I am not too familiar with this part of the
> code.
The code used by the recvr_type_gaming_hidpp receivers is shared with all the
other non-unifying receivers. Even though these receivers are not unifying the
non gaming versions may still have multiple devices (typically a keyboard + a mouse)
paired with them.
The standard HID interfaces which these devices emulate are usually split in
at least 2 HID interfaces:
1. A keyboard following the requirements of the "boot keyboard" subclass of the
USB HID class, so that the keyboard works inside say the BIOS setup screen.
This uses a single unnumbered HID report
2. A mouse + media-keys interface, which delivers numbered reports, including the
special Logitech HID++ reports for things like battery monitoring, but also some
special keys, which have their own sub-addressing embedded inside the reports.
The driver asks the receiver for a list of paired devices and then builts a list
of devices, which are then instantiated as child-HID devices which are
handled by the drivers/hid/hid-logitech-hidpp.c driver.
Any input reports received by drivers/hid/hid-logitech-dj.c are then forwarded
to the instantiated child devices, where they are actually processed.
The problem is that there is not a 1:1 relation between the interfaces and
the instantiated child-devices, so the driver aggregates all input-reports
from both interfaces together and then dispatches / forwards them to the
child-devices using its own internal addressing.
This forwarding uses 2 different addressing schemes:
1. If the report received is a special HID++ report, then it is forwarded to
paired-dev child-dev matching the HID++ device-index which is embedded
inside these special reports.
2. If a normal (unnumbered or numbered) report is received then that report is
forwarded based on the report-number. What happens here is that each paired-dev
which the hid-logitech-dj.c code instantiates has a bitmask associated with it
which indicates which kind of reports it consumes. So e.g. a normal mouse will
only consume mouse input-reports (STD_MOUSE, report-id 2) and a keyboard
will consume all of:
#define STD_KEYBOARD BIT(1)
#define MULTIMEDIA BIT(3)
#define POWER_KEYS BIT(4)
#define MEDIA_CENTER BIT(8)
#define KBD_LEDS BIT(14)
When forwarding these normal (unnumbered or numbered) reports, the list of
paired devices is searched and the report is forwarded to the first paired-dev
which reports_supported bitmask includes the report-nr:
spin_lock_irqsave(&djrcv_dev->lock, flags);
for (i = 0; i < (DJ_MAX_PAIRED_DEVICES + DJ_DEVICE_INDEX_MIN); i++) {
dj_dev = djrcv_dev->paired_dj_devices[i];
if (dj_dev && (dj_dev->reports_supported & BIT(report))) {
logi_dj_recv_forward_report(dj_dev, data, size);
spin_unlock_irqrestore(&djrcv_dev->lock, flags);
return;
}
}
The:
if (report > REPORT_TYPE_RFREPORT_LAST) {
hid_err(hdev, "Unexpected input report number %d\n", report);
return;
}
check happens before this to ensure that report can be represented
as a bitmask, IOW to ensure that BIT(report) does what we expect it to do,
without any wrapping BIT(128) cannot be represented in a 64 bit integer,
so then we end up with undefined behavior. The result will likely be either
0x00 or 0x01, but it certainly will not do what we want.
I hope that helps explain why the check is there.
As for what to do about the errors, I agree with you that the code which is
logging these errors should check for this new special input-reports with
a report-number of 128 and just silently discard these.
Regards,
Hans
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels
2021-03-10 21:48 ` Hans de Goede
@ 2021-03-11 17:39 ` Mark Hounschell
0 siblings, 0 replies; 7+ messages in thread
From: Mark Hounschell @ 2021-03-11 17:39 UTC (permalink / raw)
To: Hans de Goede, Filipe Laíns, Jiri Kosina, sashal, Linux-kernel
On 3/10/21 4:48 PM, Hans de Goede wrote:
> Hi,
>
> On 3/10/21 9:55 PM, Filipe Laíns wrote:
>> On Wed, 2021-03-10 at 15:24 -0500, Mark Hounschell wrote:
>>>
>>> That is correct, I don't have any buttons bound to keyboard events. With
>>> the original patch the G4(forward) and G5(Backward) buttons work in a
>>> browser. I guess G7, G8, and G9 buttons are programmable to keyboard events?
>>>
>>> However this patch does not seem to fix the messages I get.
>>>
>>> Regards
>>> Mark
>>
>> Those events belong to the USB HID button usage page and are sent by the
>> receiver in the HID device with the unnumbered report descriptor, so they are
>> not affected.
>>
>> Looking at the report descriptor for the other HID device, I see a report ID of
>> 128 (0x80) used for a vendor application, I am not really sure what it is used
>> for and can't seem to trigger my device to send it.
>>
>> I am gonna guess this is the device reporting the pressed buttons via vendor
>> reports or something like that. Speaking as the person who added support for
>> this device in libratbag, this report is very likely not something that we don't
>> need in our custom drivers and just likely something extra that Logitech built
>> to achieve something custom in the Windows driver. FWIW, this device is a very
>> weird one, it does not even follow Logitech's own spec :P
>>
>> Seeing this report the driver chugs.
>>
>> if (report > REPORT_TYPE_RFREPORT_LAST) {
>> hid_err(hdev, "Unexpected input report number %d\n", report);
>> return;
>> }
>>
>> Causing your
>>
>> [ 36.471326] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
>> [ 36.565317] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
>> [ 42.390321] logitech-djreceiver 0003:046D:C537.0002: Unexpected input report number 128
>>
>> I feel like the correct fix for these cases is not to consume the report and not
>> forward it to device node, but rather to forward it to the receiver node.
>>
>> (looping in Hans)
>> Hans, you introduced this code, do you remember why? Where did
>> REPORT_TYPE_RFREPORT_LAST get its value from and what is the purpose of this
>> check?
>> Shouldn't we just keep forwarding unknown reports to the receiver node? Is there
>> any technical limitation to do that? I am not too familiar with this part of the
>> code.
>
> The code used by the recvr_type_gaming_hidpp receivers is shared with all the
> other non-unifying receivers. Even though these receivers are not unifying the
> non gaming versions may still have multiple devices (typically a keyboard + a mouse)
> paired with them.
>
> The standard HID interfaces which these devices emulate are usually split in
> at least 2 HID interfaces:
>
> 1. A keyboard following the requirements of the "boot keyboard" subclass of the
> USB HID class, so that the keyboard works inside say the BIOS setup screen.
> This uses a single unnumbered HID report
>
> 2. A mouse + media-keys interface, which delivers numbered reports, including the
> special Logitech HID++ reports for things like battery monitoring, but also some
> special keys, which have their own sub-addressing embedded inside the reports.
>
> The driver asks the receiver for a list of paired devices and then builts a list
> of devices, which are then instantiated as child-HID devices which are
> handled by the drivers/hid/hid-logitech-hidpp.c driver.
>
> Any input reports received by drivers/hid/hid-logitech-dj.c are then forwarded
> to the instantiated child devices, where they are actually processed.
>
> The problem is that there is not a 1:1 relation between the interfaces and
> the instantiated child-devices, so the driver aggregates all input-reports
> from both interfaces together and then dispatches / forwards them to the
> child-devices using its own internal addressing.
>
> This forwarding uses 2 different addressing schemes:
>
> 1. If the report received is a special HID++ report, then it is forwarded to
> paired-dev child-dev matching the HID++ device-index which is embedded
> inside these special reports.
>
> 2. If a normal (unnumbered or numbered) report is received then that report is
> forwarded based on the report-number. What happens here is that each paired-dev
> which the hid-logitech-dj.c code instantiates has a bitmask associated with it
> which indicates which kind of reports it consumes. So e.g. a normal mouse will
> only consume mouse input-reports (STD_MOUSE, report-id 2) and a keyboard
> will consume all of:
>
> #define STD_KEYBOARD BIT(1)
> #define MULTIMEDIA BIT(3)
> #define POWER_KEYS BIT(4)
> #define MEDIA_CENTER BIT(8)
> #define KBD_LEDS BIT(14)
>
> When forwarding these normal (unnumbered or numbered) reports, the list of
> paired devices is searched and the report is forwarded to the first paired-dev
> which reports_supported bitmask includes the report-nr:
>
> spin_lock_irqsave(&djrcv_dev->lock, flags);
> for (i = 0; i < (DJ_MAX_PAIRED_DEVICES + DJ_DEVICE_INDEX_MIN); i++) {
> dj_dev = djrcv_dev->paired_dj_devices[i];
> if (dj_dev && (dj_dev->reports_supported & BIT(report))) {
> logi_dj_recv_forward_report(dj_dev, data, size);
> spin_unlock_irqrestore(&djrcv_dev->lock, flags);
> return;
> }
> }
>
> The:
>
> if (report > REPORT_TYPE_RFREPORT_LAST) {
> hid_err(hdev, "Unexpected input report number %d\n", report);
> return;
> }
>
> check happens before this to ensure that report can be represented
> as a bitmask, IOW to ensure that BIT(report) does what we expect it to do,
> without any wrapping BIT(128) cannot be represented in a 64 bit integer,
> so then we end up with undefined behavior. The result will likely be either
> 0x00 or 0x01, but it certainly will not do what we want.
>
> I hope that helps explain why the check is there.
>
> As for what to do about the errors, I agree with you that the code which is
> logging these errors should check for this new special input-reports with
> a report-number of 128 and just silently discard these.
>
> Regards,
>
> Hans
>
I am unsubscribing from kernel.org mailing list. I only subscribed to
report this issue. Please keep me CC'd to this thread.
Thanks
Mark
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-03-11 17:39 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-10 18:55 Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels Mark Hounschell
2021-03-10 19:56 ` Filipe Laíns
2021-03-10 20:24 ` Mark Hounschell
2021-03-10 20:49 ` Mark Hounschell
2021-03-10 20:55 ` Filipe Laíns
2021-03-10 21:48 ` Hans de Goede
2021-03-11 17:39 ` Mark Hounschell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).