| Message ID | 4887001.GXAFRqVoOG@twilight (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | hid-logitech-dj support for Anywhere 3SB | expand |
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. 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
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.(?) > 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
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. Let me know if you need anything else. Cheers, Filipe Laíns
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
On Sat, 2024-04-13 at 10:52 +0200, Allan Sandfeld Jensen wrote: > 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 > 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" <lains@riseup.net> (reviewer:HID LOGITECH DRIVERS) Bastien Nocera <hadess@hadess.net> (reviewer:HID++ LOGITECH DRIVERS) Jiri Kosina <jikos@kernel.org> (maintainer:HID CORE LAYER) Benjamin Tissoires <benjamin.tissoires@redhat.com> (maintainer:HID CORE LAYER) linux-input@vger.kernel.org (open list:HID LOGITECH DRIVERS) linux-kernel@vger.kernel.org (open list) $ scripts/get_maintainer.pl drivers/hid/hid-logitech-dj.c "Filipe Laíns" <lains@riseup.net> (reviewer:HID LOGITECH DRIVERS) Jiri Kosina <jikos@kernel.org> (maintainer:HID CORE LAYER) Benjamin Tissoires <benjamin.tissoires@redhat.com> (maintainer:HID CORE LAYER) linux-input@vger.kernel.org (open list:HID LOGITECH DRIVERS) linux-kernel@vger.kernel.org (open list) Then you can just git-send-mail to all the recipients listed there. Cheers, Filipe Laíns
From 7bbe473e227ae1a16e604a3b94fa168db27fed1a Mon Sep 17 00:00:00 2001 From: Allan Sandfeld Jensen <allan.jensen@qt.io> 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(-) diff --git a/Makefile b/Makefile index e00c12240191..ae2e6b53ebdf 100644 --- a/Makefile +++ b/Makefile @@ -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) diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index 9e38ffaadb5d..d1043cd635dd 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -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 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