bluez-5.77 broke logiops

[domryba]

Hello, after update bluez to version 5.77 logiops works well, only after a fresh system boot. But when I, eg resume my machine from sleep, or simply reconnect my mouse, logiops stops working, and I got this:

[DEBUG] Failed to add device /dev/hidraw4 on try 1, backing off for 500ms
[DEBUG] Failed to add device /dev/hidraw4 on try 2, backing off for 1000ms
[DEBUG] Failed to add device /dev/hidraw4 on try 3, backing off for 2000ms
[DEBUG] Failed to add device /dev/hidraw4 on try 4, backing off for 4000ms
[DEBUG] Failed to add device /dev/hidraw4 on try 5, backing off for 8000ms
[WARN] Failed to add device /dev/hidraw4 after 5 tries. Treating as failure.

Everything works pretty good, when I downgrade bluez to 5.76.

• Arch Linux,
• MX Master 3S via bluetooth.

EDIT: After woke up, when I restart bluetooth.service logiops works correctly.

[c-kr]

Can confirm. Same problem here with MX Master 3S on Arch with bluez 5.77. Downgrading to 5.76 resolved the issue.

[im-calvin]

+1 can confirm that downgrading to 5.76 resolved the issue. I'm on Arch so I followed these instructions: https://wiki.archlinux.org/title/Downgrading_packages

[MrTomRod]

On my system (Fedora 40, GNOME), logid has to be restarted whenever I log in. With bluez 5.77, the driver stops working if I lock my screen. Then, even restarting the service does not help:

$ journalctl -f -u logid.service
logid[19347]: [WARN] Failed to add device /dev/hidraw7 after 5 tries. Treating as failure.

Downgrading bluez-5.77-1.fc40 to bluez-5.73-3.fc40 helped, but I still have to restart the service after login.

Happy to help debugging the issue!

#Edit: Fedora only has logiops-0.3.3-4 in its repos. I compiled logiops from source (0.3.4, commit 237fa5f) and the problem persists. logid --verbose debug didn't show anything useful.

[rogsme]

I'm having this same issue, can confirm that sudo systemctl restart bluetooth.service makes logiops work again.

[lazarosgogos]

On my system (Fedora 40, GNOME), logid has to be restarted whenever I log in. With bluez 5.77, the driver stops working if I lock my screen. Then, even restarting the service does not help:

$ journalctl -f -u logid.service
logid[19347]: [WARN] Failed to add device /dev/hidraw7 after 5 tries. Treating as failure.

Downgrading bluez-5.77-1.fc40 to bluez-5.73-3.fc40 helped, but I still have to restart the service after login.

Happy to help debugging the issue!

Edit: Fedora only has logiops-0.3.3-4 in its repos. I compiled logiops from source (0.3.4, commit 237fa5f) and the problem persists. logid --verbose debug didn't show anything useful.

Having the exact same issue. Should anyone have any insights we can look into this together to find a solution :)

I believe it's a combination of the latest bluez updates (I had bluez-5.69 installed and logiops worked flawlessly) and something logiops does in a sequence that doesn't allow it to function properly.

Any ideas welcome. How could we tackle this?

[spoutn1k]

Have you tried #460 ? It fixed a bunch of people's issues, I'm running the patch and my setup is working as usual after the update to 5.77

[c-kr]

Thanks @spoutn1k for your suggestion but isnt this fix only for the bolt receiver and not for bluetooth connected devices?

[MrTomRod]

@spoutn1k It also fixes the issue for me! Thanks for the heads up!

[spoutn1k]

@c-kr: @lazarosgogos mentions it is something in a sequence that is fucky, and this patch changes a sequence of action. Just a shot in the dark !

[c-kr]

I tried the patch and it did not help. After the first disconnect/sleep logid is unable to reconnect

[lazarosgogos]

@spoutn1k Just like @c-kr , I tried the fix and it did not work either. After disconnecting the device and reconnecting it, a service restart must be issued for the driver to work properly. Thank you for the proposal, however.

I think the solution lies in looking carefully at what changed between bluez-5.69 and bluez-5.73 or -5.77 to try and figure out what messes with HID++ inputs.

[c-kr]

bluez 5.76 works fine. If someone has a lot of time one way would be to git-bisect all changes between both versions and find the problematic commit

[dpecos]

I can also confirm that downgrading to bluez 5.76 fixes the issue.

[lazarosgogos]

@dpecos @c-kr Really good to know. What distro are you using?

[dpecos]

arch, btw

:-D