On OpenSUSE Tumbleweed with kernel 6.11.8-1 and firmware version from 20241125 it is not possible to pair the device with a Logitech Master MX 3S mice. Other bluetooth devices are working. Pairing the same hardware commbination works with Ubuntu 24.04 (noble) running kernel 6.8.0. The maintainer from OpenSUSE suggested to file a bug report here, since he has the opinion, it is an upstream problem. The bug report for opensuse is here: https://bugzilla.opensuse.org/show_bug.cgi?id=1233733
On Pop_os with kernel 6.12.3 not possible to pair the device with a Logitech Master MX 3S mice. On Pop_os with kernel 6.9 it is works.
Hi, I think this is the exact same issue encountered on the Starlite Mk V I have bisected the issue with a generic LE bluetooth keyboard here: https://github.com/StarLabsLtd/firmware/issues/180#issuecomment-2732540740 And currently have that keyboard working on the Starlite Mk V with kernel 6.13.8 as it was working before with kernel 6.1.131 lts. The change made to have it work is the following: ``` commit 49de268ad2d7f217579090da90a5d93cad281477 (HEAD -> refs/heads/blackikeeagle-starlite-btintel) Author: BlackEagle <ike.devolder@gmail.com> Date: Tue Mar 18 09:06:21 2025 +0100 Bluetooth: btintel, don't reclassify signal for GfP2 and GaP Should fix issue with LE devices not being found or able to connect. diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c index d496cf2c3411..4ecebae58792 100644 --- a/drivers/bluetooth/btintel.c +++ b/drivers/bluetooth/btintel.c @@ -3249,9 +3249,6 @@ static int btintel_setup_combined(struct hci_dev *hdev) break; case 0x18: /* GfP2 */ case 0x1c: /* GaP */ - /* Re-classify packet type for controllers with LE audio */ - hdev->classify_pkt_type = btintel_classify_pkt_type; - fallthrough; case 0x17: case 0x19: case 0x1b: ``` https://gist.github.com/BlackIkeEagle/630e76164d9eca5f1eb617888c7f1576 This is not the real fix I guess since that reclassification of the pkt_type is not there for no reason. But the skipping of it works around the issue Hopefully this helps someone to find the actual issue
It might be related to https://github.com/bluez/bluez/issues/1138
(In reply to Ike Devolder from comment #2) > Hi, > > I think this is the exact same issue encountered on the Starlite Mk V > > I have bisected the issue with a generic LE bluetooth keyboard here: > https://github.com/StarLabsLtd/firmware/issues/180#issuecomment-2732540740 > > And currently have that keyboard working on the Starlite Mk V with kernel > 6.13.8 as it was working before with kernel 6.1.131 lts. > > The change made to have it work is the following: > > ``` > commit 49de268ad2d7f217579090da90a5d93cad281477 (HEAD -> > refs/heads/blackikeeagle-starlite-btintel) > Author: BlackEagle <ike.devolder@gmail.com> > Date: Tue Mar 18 09:06:21 2025 +0100 > > Bluetooth: btintel, don't reclassify signal for GfP2 and GaP > > Should fix issue with LE devices not being found or able to connect. > > diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c > index d496cf2c3411..4ecebae58792 100644 > --- a/drivers/bluetooth/btintel.c > +++ b/drivers/bluetooth/btintel.c > @@ -3249,9 +3249,6 @@ static int btintel_setup_combined(struct hci_dev *hdev) > break; > case 0x18: /* GfP2 */ > case 0x1c: /* GaP */ > - /* Re-classify packet type for controllers with LE audio */ > - hdev->classify_pkt_type = btintel_classify_pkt_type; > - fallthrough; > case 0x17: > case 0x19: > case 0x1b: > ``` > > https://gist.github.com/BlackIkeEagle/630e76164d9eca5f1eb617888c7f1576 > > This is not the real fix I guess since that reclassification of the pkt_type > is not there for no reason. But the skipping of it works around the issue > > Hopefully this helps someone to find the actual issue These are not the same controller as the bug description suggests, so if you are having something with GfP2/GaP that is probably something different.
(In reply to Luiz Von Dentz from comment #4) > (In reply to Ike Devolder from comment #2) > > Hi, > > > > I think this is the exact same issue encountered on the Starlite Mk V > > > > I have bisected the issue with a generic LE bluetooth keyboard here: > > https://github.com/StarLabsLtd/firmware/issues/180#issuecomment-2732540740 > > > > And currently have that keyboard working on the Starlite Mk V with kernel > > 6.13.8 as it was working before with kernel 6.1.131 lts. > > > > The change made to have it work is the following: > > > > ``` > > commit 49de268ad2d7f217579090da90a5d93cad281477 (HEAD -> > > refs/heads/blackikeeagle-starlite-btintel) > > Author: BlackEagle <ike.devolder@gmail.com> > > Date: Tue Mar 18 09:06:21 2025 +0100 > > > > Bluetooth: btintel, don't reclassify signal for GfP2 and GaP > > > > Should fix issue with LE devices not being found or able to connect. > > > > diff --git a/drivers/bluetooth/btintel.c b/drivers/bluetooth/btintel.c > > index d496cf2c3411..4ecebae58792 100644 > > --- a/drivers/bluetooth/btintel.c > > +++ b/drivers/bluetooth/btintel.c > > @@ -3249,9 +3249,6 @@ static int btintel_setup_combined(struct hci_dev > *hdev) > > break; > > case 0x18: /* GfP2 */ > > case 0x1c: /* GaP */ > > - /* Re-classify packet type for controllers with LE audio */ > > - hdev->classify_pkt_type = btintel_classify_pkt_type; > > - fallthrough; > > case 0x17: > > case 0x19: > > case 0x1b: > > ``` > > > > https://gist.github.com/BlackIkeEagle/630e76164d9eca5f1eb617888c7f1576 > > > > This is not the real fix I guess since that reclassification of the > pkt_type > > is not there for no reason. But the skipping of it works around the issue > > > > Hopefully this helps someone to find the actual issue > > These are not the same controller as the bug description suggests, so if you > are having something with GfP2/GaP that is probably something different. Oh, I did not realize it could be a different chip, I looked at the opensuse report and saw the same firmware `ibt-0040-2120.sfi`. Do I have to create a new ticket for this? Some info about my bluetooth: ``` mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Device revision is 2 mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Secure boot is enabled mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: OTP lock is enabled mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: API lock is enabled mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Debug lock is disabled mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Minimum firmware build 1 week 10 2014 mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Bootloader timestamp 2019.40 buildtype 1 build 38 mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: DSM reset method type: 0x00 mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Found device firmware: intel/ibt-0040-2120.sfi mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Boot Address: 0x100800 mrt 23 00:53:25 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Firmware Version: 151-5.24 mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Waiting for firmware download to complete mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Firmware loaded in 1917199 usecs mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Waiting for device to boot mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Device booted in 17233 usecs mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-0040-2120.ddc mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Applying Intel DDC parameters completed mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Firmware timestamp 2024.5 buildtype 1 build 151 mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Firmware SHA1: 0x00000000 mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Fseq status: Success (0x00) mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Fseq executed: 00.00.02.36 mrt 23 00:53:27 archlinux-Yjk4NzBh kernel: Bluetooth: hci0: Fseq BT Top: 00.00.02.36 ```