hid-logitech-dj support for Anywhere 3SB

PATCH Allan Sandfeld Jensen 2 participants 6 messages Apr 12, 2024 – Apr 13, 2024

Subsystems (5)

x86 Kbuild HID HID logitech drivers +1 more subsystems

lore

Share & tools

lore

Allan Sandfeld Jensen

author

2024-04-12 09:11 UTC #0 lore raw

Hello,

I am writing because you are listed as author of the hid-logitech-dj driver. I recently bought a Logitech Anywhere 3SB mouse, and found Linux didn't recognize it. Thinking it was a simple case of new IDs not recognized, I quickly added them to the logitch HID++ drivers (patch attached), both for USB with the new receiver and for the Bluetooth direct connection.

I have noticed however that the patch while causing them to be recognized and interacted with as HID++ devices, it has a flaw. The scroll wheel events are reported by the linux kernel as being in hires mode, while haven't actually enabled it on the mouse. You can fix that using Solaar, but some piece is missing to enable it correctly in the driver. Since this is no longer a trivial fix. I wanted to reach out. Do you have any suggestions?

Best regards
Allan

From 7bbe473e227ae1a16e604a3b94fa168db27fed1a Mon Sep 17 00:00:00 2001
From: Allan Sandfeld Jensen <[email protected]>
Date: Wed, 10 Apr 2024 15:23:40 +0200
Subject: [PATCH] Logitech Anywhere 3SB support

---
 Makefile                         |  2 +-
 arch/x86/boot/Makefile           |  2 +-
 drivers/hid/hid-ids.h            |  1 +
 drivers/hid/hid-logitech-dj.c    | 10 +++++++++-
 drivers/hid/hid-logitech-hidpp.c |  2 ++
 5 files changed, 14 insertions(+), 3 deletions(-)

Makefile +1 -1

index e00c12240191..ae2e6b53ebdf 100644
@@ -2131,7 +2131,7 @@ kernelversion:
 	@echo $(KERNELVERSION)
 
 image_name:
-	@echo $(KBUILD_IMAGE)
+	@$(PERL) -e 'print "$(KBUILD_IMAGE)"'
 
 quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN   $(wildcard $(rm-files)))
       cmd_rmfiles = rm -rf $(rm-files)

arch/x86/boot/Makefile +1 -1

index 9e38ffaadb5d..d1043cd635dd 100644
@@ -83,7 +83,7 @@ cmd_image = $(obj)/tools/build $(obj)/setup.bin $(obj)/vmlinux.bin \
 
 $(obj)/bzImage: $(obj)/setup.bin $(obj)/vmlinux.bin $(obj)/tools/build FORCE
 	$(call if_changed,image)
-	@$(kecho) 'Kernel: $@ is ready' ' (#'$(or $(KBUILD_BUILD_VERSION),`cat .version`)')'
+	$(PERL) -e 'print "Kernel: $@ is ready"'
 
 OBJCOPYFLAGS_vmlinux.bin := -O binary -R .note -R .comment -S
 $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE

drivers/hid/hid-ids.h +1 -0

index 2235d78784b1..4b79c4578d32 100644
@@ -849,6 +849,7 @@
 #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1	0xc539
 #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1	0xc53f
 #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY	0xc53a
+#define USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER		0xc548
 #define USB_DEVICE_ID_SPACETRAVELLER	0xc623
 #define USB_DEVICE_ID_SPACENAVIGATOR	0xc626
 #define USB_DEVICE_ID_DINOVO_DESKTOP	0xc704

drivers/hid/hid-logitech-dj.c +9 -1

index c358778e070b..92b41ae5a47c 100644
@@ -120,6 +120,7 @@ enum recvr_type {
 	recvr_type_27mhz,
 	recvr_type_bluetooth,
 	recvr_type_dinovo,
+	recvr_type_bolt,
 };
 
 struct dj_report {

@@ -1068,6 +1069,7 @@ static void logi_hidpp_recv_queue_notif(struct hid_device *hdev,
 		workitem.reports_supported |= STD_KEYBOARD;
 		break;
 	case 0x0f:
+	case 0x10:
 	case 0x11:
 		device_type = "eQUAD Lightspeed 1.2";
 		logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);

@@ -1430,7 +1432,8 @@ static int logi_dj_ll_parse(struct hid_device *hid)
 		dbg_hid("%s: sending a mouse descriptor, reports_supported: %llx\n",
 			__func__, djdev->reports_supported);
 		if (djdev->dj_receiver_dev->type == recvr_type_gaming_hidpp ||
-		    djdev->dj_receiver_dev->type == recvr_type_mouse_only)
+		    djdev->dj_receiver_dev->type == recvr_type_mouse_only ||
+		    djdev->dj_receiver_dev->type == recvr_type_bolt)
 			rdcat(rdesc, &rsize, mse_high_res_descriptor,
 			      sizeof(mse_high_res_descriptor));
 		else if (djdev->dj_receiver_dev->type == recvr_type_27mhz)

@@ -1773,6 +1776,7 @@ static int logi_dj_probe(struct hid_device *hdev,
 	case recvr_type_dj:		no_dj_interfaces = 3; break;
 	case recvr_type_hidpp:		no_dj_interfaces = 2; break;
 	case recvr_type_gaming_hidpp:	no_dj_interfaces = 3; break;
+	case recvr_type_bolt:		no_dj_interfaces = 4; break;
 	case recvr_type_mouse_only:	no_dj_interfaces = 2; break;
 	case recvr_type_27mhz:		no_dj_interfaces = 2; break;
 	case recvr_type_bluetooth:	no_dj_interfaces = 2; break;

@@ -1950,6 +1954,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
 	  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
 		USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2),
 	 .driver_data = recvr_type_dj},
+	{ /* Logitech bolt receiver (0xc548) */
+	  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+		USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER),
+	 .driver_data = recvr_type_bolt},
 
 	{ /* Logitech Nano mouse only receiver (0xc52f) */
 	  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,

drivers/hid/hid-logitech-hidpp.c +2 -0

index 3c00e6ac8e76..509142982daa 100644
@@ -4380,6 +4380,8 @@ static const struct hid_device_id hidpp_devices[] = {
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb023) },
 	{ /* MX Master 3S mouse over Bluetooth */
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
+	{ /* MX Anywhere 3SB mouse over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
 	{}
 };

Signature · 1 line

2.39.2

Filipe Laíns

reviewer

2024-04-12 19:53 UTC #1 lore raw

Quoted 15 lines · Allan Sandfeld Jensen

Hello,
I am writing because you are listed as author of the hid-logitech-dj driver. I recently bought a Logitech Anywhere 3SB mouse, and found Linux didn't recognize it. Thinking it was a simple case of new IDs not recognized, I quickly added them to the logitch HID++ drivers (patch attached), both for USB with the new receiver and for the Bluetooth direct connection.
I have noticed however that the patch while causing them to be recognized and interacted with as HID++ devices, it has a flaw. The scroll wheel events are reported by the linux kernel as being in hires mode, while haven't actually enabled it on the mouse. You can fix that using Solaar, but some piece is missing to enable it correctly in the driver. Since this is no longer a trivial fix. I wanted to reach out. Do you have any suggestions?

Quoted 2 lines

Best regards
Allan

Hi Allan,

Thank you for reaching out.

What likely is happening here is Solaar overwriting the configuration that the kernel driver sets, as that would happen after the driver talks to the device.

The settings in question need support in both the kernel and the userspace input stack (libinput) for them to work appropriately, it's not like configuring RGB or other sort setting on the device that works standalone.
I have, multiple times now, asked for Solaar to not expose these low level settings that need support from other parts of the input stack, leaving them to the kernel to configure.

I have been inactive in the Solaar project for quite some time now, so I don't feel like yet again make a big deal out of this there, so that this decision is reconsidered. I have already spent a significant amount of effort there, and nowadays I barely have energy to go through my day and deal with my all my responsibilities and other OSS project involvements, so I sadly have no more energy to spare there.

My recommendation is: disable Solaar from running at startup, restart the system, and see if that solves your problem. If it does, report this issue again to the Solaar upstream, then depending on that outcome, make a decision on how to proceed. It may be that setting the high-resolution settings in Solaar, which are expected by the driver, works, but it might not be super reliable, because since Solaar is overwriting the settings configured by the kernel driver, if anything in the kernel driver changes, then the setting you have configured in Solaar might no longer be correct.
There are alternatives to Solaar that do not have this issue, like libratbag, but these generally are feature lacking on the productivity line of Logitech projects.

Sorry I wasn't able to help much, but I hope that this clarifies things a bit, and helps you solve your problem.

Cheers,
Filipe Laíns

Allan Sandfeld Jensen

author

2024-04-13 08:20 UTC #2 lore raw

Quoted 25 lines · On Friday 12 April 2024 21:53:31 CEST Filipe Laíns wrote:

Quoted 17 lines · Allan Sandfeld Jensen
Hello,
I am writing because you are listed as author of the hid-logitech-dj driver. I recently bought a Logitech Anywhere 3SB mouse, and found Linux didn't recognize it. Thinking it was a simple case of new IDs not recognized, I quickly added them to the logitch HID++ drivers (patch attached), both for USB with the new receiver and for the Bluetooth direct connection.
I have noticed however that the patch while causing them to be recognized and interacted with as HID++ devices, it has a flaw. The scroll wheel events are reported by the linux kernel as being in hires mode, while haven't actually enabled it on the mouse. You can fix that using Solaar, but some piece is missing to enable it correctly in the driver. Since this is no longer a trivial fix. I wanted to reach out. Do you have any suggestions?
Quoted 2 lines
Best regards
Allan
Hi Allan,
Thank you for reaching out.

Quoted 7 lines

What likely is happening here is Solaar overwriting the configuration that the kernel driver sets, as that would happen after the driver talks to the device.
The settings in question need support in both the kernel and the userspace input stack (libinput) for them to work appropriately, it's not like configuring RGB or other sort setting on the device that works standalone.

We already have the support in the kernel and libinput. That is why I am expanding it to recognize this new device id.(?)

Quoted 22 lines

I have, multiple times now, asked for Solaar to not expose these low level settings that need support from other parts of the input stack, leaving them to the kernel to configure.
I have been inactive in the Solaar project for quite some time now, so I don't feel like yet again make a big deal out of this there, so that this decision is reconsidered. I have already spent a significant amount of effort there, and nowadays I barely have energy to go through my day and deal with my all my responsibilities and other OSS project involvements, so I sadly have no more energy to spare there.
My recommendation is: disable Solaar from running at startup, restart the system, and see if that solves your problem. If it does, report this issue again to the Solaar upstream, then depending on that outcome, make a decision on how to proceed. It may be that setting the high-resolution settings in Solaar, which are expected by the driver, works, but it might not be super reliable, because since Solaar is overwriting the settings configured by the kernel driver, if anything in the kernel driver changes, then the setting you have configured in Solaar might no longer be correct. There are alternatives to Solaar that do not have this issue, like libratbag, but these generally are feature lacking on the productivity line of Logitech projects.

Quoted 3 lines

Sorry I wasn't able to help much, but I hope that this clarifies things a bit, and helps you solve your problem.

Thanks. You are right, it works with solaar uninstalled, I only installed it to check the details of a device not recognized by the kernel.

So the patch as send to you before is then upstreamable. Is there anything more I need to do, to facilitate the upstreaming?

Best regards
Allan

Filipe Laíns

reviewer

2024-04-13 08:33 UTC #3 lore raw

Quoted 30 lines · Allan Sandfeld Jensen

Quoted 29 lines · On Friday 12 April 2024 21:53:31 CEST Filipe Laíns wrote:
Quoted 17 lines · Allan Sandfeld Jensen
Hello,
I am writing because you are listed as author of the hid-logitech-dj driver. I recently bought a Logitech Anywhere 3SB mouse, and found Linux didn't recognize it. Thinking it was a simple case of new IDs not recognized, I quickly added them to the logitch HID++ drivers (patch attached), both for USB with the new receiver and for the Bluetooth direct connection.
I have noticed however that the patch while causing them to be recognized and interacted with as HID++ devices, it has a flaw. The scroll wheel events are reported by the linux kernel as being in hires mode, while haven't actually enabled it on the mouse. You can fix that using Solaar, but some piece is missing to enable it correctly in the driver. Since this is no longer a trivial fix. I wanted to reach out. Do you have any suggestions?
Quoted 2 lines
Best regards
Allan
Hi Allan,
Thank you for reaching out.
What likely is happening here is Solaar overwriting the configuration that the kernel driver sets, as that would happen after the driver talks to the device.

Quoted 5 lines

Quoted 3 lines
The settings in question need support in both the kernel and the userspace input stack (libinput) for them to work appropriately, it's not like configuring RGB or other sort setting on the device that works standalone.
We already have the support in the kernel and libinput. That is why I am expanding it to recognize this new device id.(?)

Yes, that sounds right.

Quoted 25 lines

Quoted 22 lines
I have, multiple times now, asked for Solaar to not expose these low level settings that need support from other parts of the input stack, leaving them to the kernel to configure.
I have been inactive in the Solaar project for quite some time now, so I don't feel like yet again make a big deal out of this there, so that this decision is reconsidered. I have already spent a significant amount of effort there, and nowadays I barely have energy to go through my day and deal with my all my responsibilities and other OSS project involvements, so I sadly have no more energy to spare there.
My recommendation is: disable Solaar from running at startup, restart the system, and see if that solves your problem. If it does, report this issue again to the Solaar upstream, then depending on that outcome, make a decision on how to proceed. It may be that setting the high-resolution settings in Solaar, which are expected by the driver, works, but it might not be super reliable, because since Solaar is overwriting the settings configured by the kernel driver, if anything in the kernel driver changes, then the setting you have configured in Solaar might no longer be correct. There are alternatives to Solaar that do not have this issue, like libratbag, but these generally are feature lacking on the productivity line of Logitech projects.
Quoted 3 lines
Sorry I wasn't able to help much, but I hope that this clarifies things a bit, and helps you solve your problem.

Quoted 8 lines

Thanks. You are right, it works with solaar uninstalled, I only installed it to check the details of a device not recognized by the kernel.
So the patch as send to you before is then upstreamable. Is there anything more I need to do, to facilitate the upstreaming?
Best regards
Allan

Great to hear!

The patch you sent seems pretty good for upstreaming, I would maybe just split the Makefile changes into a separate patch and submit those separately, if that's something you actually want to upstream. Additionally, it seems to me like the mouse can work wired, so I would also add the USB PID of the wired connection to the hidpp driver, that way everything should work as expected on all interfaces.

Let me know if you need anything else.

Cheers,
Filipe Laíns

Allan Sandfeld Jensen

author

2024-04-13 08:53 UTC #4 lore raw

Quoted 92 lines · On Saturday 13 April 2024 10:33:29 CEST Filipe Laíns wrote:

Quoted 36 lines · Allan Sandfeld Jensen
Quoted 35 lines · On Friday 12 April 2024 21:53:31 CEST Filipe Laíns wrote:
Quoted 21 lines · Allan Sandfeld Jensen
Hello,
I am writing because you are listed as author of the hid-logitech-dj driver. I recently bought a Logitech Anywhere 3SB mouse, and found Linux
didn't recognize it. Thinking it was a simple case of new IDs not recognized, I quickly added them to the logitch HID++ drivers (patch attached), both for USB with the new receiver and for the Bluetooth direct connection.
I have noticed however that the patch while causing them to be recognized
and interacted with as HID++ devices, it has a flaw. The scroll wheel events are reported by the linux kernel as being in hires mode, while haven't actually enabled it on the mouse. You can fix that using Solaar,
but some piece is missing to enable it correctly in the driver. Since this is no longer a trivial fix. I wanted to reach out. Do you have any
suggestions?
Quoted 2 lines
Best regards
Allan
Hi Allan,
Thank you for reaching out.
What likely is happening here is Solaar overwriting the configuration that
the kernel driver sets, as that would happen after the driver talks to the
device.
Quoted 8 lines
Quoted 5 lines
The settings in question need support in both the kernel and the userspace
input stack (libinput) for them to work appropriately, it's not like configuring RGB or other sort setting on the device that works standalone.
We already have the support in the kernel and libinput. That is why I am expanding it to recognize this new device id.(?)
Yes, that sounds right.
Quoted 35 lines
Quoted 31 lines
I have, multiple times now, asked for Solaar to not expose these low level
settings that need support from other parts of the input stack, leaving them to the kernel to configure.
I have been inactive in the Solaar project for quite some time now, so I don't feel like yet again make a big deal out of this there, so that this
decision is reconsidered. I have already spent a significant amount of effort there, and nowadays I barely have energy to go through my day and deal with my all my responsibilities and other OSS project involvements, so
I sadly have no more energy to spare there.
My recommendation is: disable Solaar from running at startup, restart the
system, and see if that solves your problem. If it does, report this issue
again to the Solaar upstream, then depending on that outcome, make a decision on how to proceed. It may be that setting the high-resolution settings in Solaar, which are expected by the driver, works, but it might
not be super reliable, because since Solaar is overwriting the settings configured by the kernel driver, if anything in the kernel driver changes,
then the setting you have configured in Solaar might no longer be correct.
There are alternatives to Solaar that do not have this issue, like libratbag, but these generally are feature lacking on the productivity line
of Logitech projects.
Quoted 3 lines
Sorry I wasn't able to help much, but I hope that this clarifies things a
bit, and helps you solve your problem.
Quoted 8 lines
Thanks. You are right, it works with solaar uninstalled, I only installed it to check the details of a device not recognized by the kernel.
So the patch as send to you before is then upstreamable. Is there anything more I need to do, to facilitate the upstreaming?
Best regards
Allan

Quoted 9 lines

Great to hear!
The patch you sent seems pretty good for upstreaming, I would maybe just split the Makefile changes into a separate patch and submit those separately, if that's something you actually want to upstream. Additionally, it seems to me like the mouse can work wired, so I would also add the USB PID of the wired connection to the hidpp driver, that way everything should work as expected on all interfaces.

Right. I thought I had remove those changes. I had the weirdest issue when building the kernel, where echo wouldn't terminate. It worked when I replaced echo with another command, so I ended up using perl -e print. Still no idea, I assume some interaction between my shell and the combination of quiet and echo in a Makefile, but it doesnt matter, not part of the patch.

It doesn't seem like the mouse communicates over the USB cable, only draws power. This appears consistent with my old Anywhere 2S mouse.

So where should I send the patch now? It has been at least 15 years since I contributed anything to the kernel, and I understand sending patches to the central mailing list is frowned upon now. Do you take if from here, or do I need to send it to a submodule maintainer above you?

Best regards
Allan

From f998faa55c4f5988a958f7af50eacfcb0452451c Mon Sep 17 00:00:00 2001
From: Allan Sandfeld Jensen <[email protected]>
Date: Wed, 10 Apr 2024 15:23:40 +0200
Subject: [PATCH 2/2] Logitech Anywhere 3SB support

---
 drivers/hid/hid-ids.h            |  1 +
 drivers/hid/hid-logitech-dj.c    | 10 +++++++++-
 drivers/hid/hid-logitech-hidpp.c |  2 ++
 3 files changed, 12 insertions(+), 1 deletion(-)

drivers/hid/hid-ids.h +1 -0

index 2235d78784b1..4b79c4578d32 100644
@@ -849,6 +849,7 @@
 #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1	0xc539
 #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_1	0xc53f
 #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY	0xc53a
+#define USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER		0xc548
 #define USB_DEVICE_ID_SPACETRAVELLER	0xc623
 #define USB_DEVICE_ID_SPACENAVIGATOR	0xc626
 #define USB_DEVICE_ID_DINOVO_DESKTOP	0xc704

drivers/hid/hid-logitech-dj.c +9 -1

index c358778e070b..92b41ae5a47c 100644
@@ -120,6 +120,7 @@ enum recvr_type {
 	recvr_type_27mhz,
 	recvr_type_bluetooth,
 	recvr_type_dinovo,
+	recvr_type_bolt,
 };
 
 struct dj_report {

@@ -1068,6 +1069,7 @@ static void logi_hidpp_recv_queue_notif(struct hid_device *hdev,
 		workitem.reports_supported |= STD_KEYBOARD;
 		break;
 	case 0x0f:
+	case 0x10:
 	case 0x11:
 		device_type = "eQUAD Lightspeed 1.2";
 		logi_hidpp_dev_conn_notif_equad(hdev, hidpp_report, &workitem);

@@ -1430,7 +1432,8 @@ static int logi_dj_ll_parse(struct hid_device *hid)
 		dbg_hid("%s: sending a mouse descriptor, reports_supported: %llx\n",
 			__func__, djdev->reports_supported);
 		if (djdev->dj_receiver_dev->type == recvr_type_gaming_hidpp ||
-		    djdev->dj_receiver_dev->type == recvr_type_mouse_only)
+		    djdev->dj_receiver_dev->type == recvr_type_mouse_only ||
+		    djdev->dj_receiver_dev->type == recvr_type_bolt)
 			rdcat(rdesc, &rsize, mse_high_res_descriptor,
 			      sizeof(mse_high_res_descriptor));
 		else if (djdev->dj_receiver_dev->type == recvr_type_27mhz)

@@ -1773,6 +1776,7 @@ static int logi_dj_probe(struct hid_device *hdev,
 	case recvr_type_dj:		no_dj_interfaces = 3; break;
 	case recvr_type_hidpp:		no_dj_interfaces = 2; break;
 	case recvr_type_gaming_hidpp:	no_dj_interfaces = 3; break;
+	case recvr_type_bolt:		no_dj_interfaces = 4; break;
 	case recvr_type_mouse_only:	no_dj_interfaces = 2; break;
 	case recvr_type_27mhz:		no_dj_interfaces = 2; break;
 	case recvr_type_bluetooth:	no_dj_interfaces = 2; break;

@@ -1950,6 +1954,10 @@ static const struct hid_device_id logi_dj_receivers[] = {
 	  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
 		USB_DEVICE_ID_LOGITECH_UNIFYING_RECEIVER_2),
 	 .driver_data = recvr_type_dj},
+	{ /* Logitech bolt receiver (0xc548) */
+	  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
+		USB_DEVICE_ID_LOGITECH_BOLT_RECEIVER),
+	 .driver_data = recvr_type_bolt},
 
 	{ /* Logitech Nano mouse only receiver (0xc52f) */
 	  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,

drivers/hid/hid-logitech-hidpp.c +2 -0

index 3c00e6ac8e76..509142982daa 100644
@@ -4380,6 +4380,8 @@ static const struct hid_device_id hidpp_devices[] = {
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb023) },
 	{ /* MX Master 3S mouse over Bluetooth */
 	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb034) },
+	{ /* MX Anywhere 3SB mouse over Bluetooth */
+	  HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb038) },
 	{}
 };

Signature · 1 line

2.39.2

Filipe Laíns

reviewer

2024-04-13 09:25 UTC #5 lore raw

Quoted 111 lines · Allan Sandfeld Jensen

Quoted 92 lines · On Saturday 13 April 2024 10:33:29 CEST Filipe Laíns wrote:
Quoted 36 lines · Allan Sandfeld Jensen
Quoted 35 lines · On Friday 12 April 2024 21:53:31 CEST Filipe Laíns wrote:
Quoted 21 lines · Allan Sandfeld Jensen
Hello,
I am writing because you are listed as author of the hid-logitech-dj driver. I recently bought a Logitech Anywhere 3SB mouse, and found Linux
didn't recognize it. Thinking it was a simple case of new IDs not recognized, I quickly added them to the logitch HID++ drivers (patch attached), both for USB with the new receiver and for the Bluetooth direct connection.
I have noticed however that the patch while causing them to be recognized
and interacted with as HID++ devices, it has a flaw. The scroll wheel events are reported by the linux kernel as being in hires mode, while haven't actually enabled it on the mouse. You can fix that using Solaar,
but some piece is missing to enable it correctly in the driver. Since this is no longer a trivial fix. I wanted to reach out. Do you have any
suggestions?
Quoted 2 lines
Best regards
Allan
Hi Allan,
Thank you for reaching out.
What likely is happening here is Solaar overwriting the configuration that
the kernel driver sets, as that would happen after the driver talks to the
device.
Quoted 8 lines
Quoted 5 lines
The settings in question need support in both the kernel and the userspace
input stack (libinput) for them to work appropriately, it's not like configuring RGB or other sort setting on the device that works standalone.
We already have the support in the kernel and libinput. That is why I am expanding it to recognize this new device id.(?)
Yes, that sounds right.
Quoted 35 lines
Quoted 31 lines
I have, multiple times now, asked for Solaar to not expose these low level
settings that need support from other parts of the input stack, leaving them to the kernel to configure.
I have been inactive in the Solaar project for quite some time now, so I don't feel like yet again make a big deal out of this there, so that this
decision is reconsidered. I have already spent a significant amount of effort there, and nowadays I barely have energy to go through my day and deal with my all my responsibilities and other OSS project involvements, so
I sadly have no more energy to spare there.
My recommendation is: disable Solaar from running at startup, restart the
system, and see if that solves your problem. If it does, report this issue
again to the Solaar upstream, then depending on that outcome, make a decision on how to proceed. It may be that setting the high-resolution settings in Solaar, which are expected by the driver, works, but it might
not be super reliable, because since Solaar is overwriting the settings configured by the kernel driver, if anything in the kernel driver changes,
then the setting you have configured in Solaar might no longer be correct.
There are alternatives to Solaar that do not have this issue, like libratbag, but these generally are feature lacking on the productivity line
of Logitech projects.
Quoted 3 lines
Sorry I wasn't able to help much, but I hope that this clarifies things a
bit, and helps you solve your problem.
Quoted 8 lines
Thanks. You are right, it works with solaar uninstalled, I only installed it to check the details of a device not recognized by the kernel.
So the patch as send to you before is then upstreamable. Is there anything more I need to do, to facilitate the upstreaming?
Best regards
Allan
Quoted 9 lines
Great to hear!
The patch you sent seems pretty good for upstreaming, I would maybe just split the Makefile changes into a separate patch and submit those separately, if that's something you actually want to upstream. Additionally, it seems to me like the mouse can work wired, so I would also add the USB PID of the wired connection to the hidpp driver, that way everything should work as expected on all interfaces.
Right. I thought I had remove those changes. I had the weirdest issue when building the kernel, where echo wouldn't terminate. It worked when I replaced echo with another command, so I ended up using perl -e print. Still no idea, I assume some interaction between my shell and the combination of quiet and echo in a Makefile, but it doesnt matter, not part of the patch.
It doesn't seem like the mouse communicates over the USB cable, only draws power. This appears consistent with my old Anywhere 2S mouse.

Quoted 8 lines

So where should I send the patch now? It has been at least 15 years since I contributed anything to the kernel, and I understand sending patches to the central mailing list is frowned upon now. Do you take if from here, or do I need to send it to a submodule maintainer above you?
Best regards
Allan

The standard practice is to run scripts/get_maintainer.pl to find the recipients. In your case:

$ scripts/get_maintainer.pl drivers/hid/hid-logitech-hidpp.c
"Filipe Laíns" <[email protected]> (reviewer:HID LOGITECH DRIVERS)
Bastien Nocera <[email protected]> (reviewer:HID++ LOGITECH DRIVERS)
Jiri Kosina <[email protected]> (maintainer:HID CORE LAYER)
Benjamin Tissoires <[email protected]> (maintainer:HID CORE LAYER)
[email protected] (open list:HID LOGITECH DRIVERS)
[email protected] (open list)
$ scripts/get_maintainer.pl drivers/hid/hid-logitech-dj.c
"Filipe Laíns" <[email protected]> (reviewer:HID LOGITECH DRIVERS)
Jiri Kosina <[email protected]> (maintainer:HID CORE LAYER)
Benjamin Tissoires <[email protected]> (maintainer:HID CORE LAYER)
[email protected] (open list:HID LOGITECH DRIVERS)
[email protected] (open list)

Then you can just git-send-mail to all the recipients listed there.

Cheers,
Filipe Laíns