Re: hid-logitech-dj support for Anywhere 3SB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Saturday 13 April 2024 10:33:29 CEST Filipe Laíns wrote:
> On Sat, 2024-04-13 at 10:20 +0200, Allan Sandfeld Jensen wrote:
> > On Friday 12 April 2024 21:53:31 CEST Filipe Laíns wrote:
> > > On Fri, 2024-04-12 at 11:10 +0200, Allan Sandfeld Jensen wrote:
> > > > 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
> > > 
> > > 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.
> > 
> > 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.
> 
> > > 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.
> > 
> > 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.
> 
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 <allan.jensen@xxxxx>
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(-)

diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 2235d78784b1..4b79c4578d32 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -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
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index c358778e070b..92b41ae5a47c 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -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,
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 3c00e6ac8e76..509142982daa 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -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) },
 	{}
 };
 
-- 
2.39.2


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux