mouse major lag

[zorgluf]

Hi,
First a big thanks for this great project, it was exactly what I was looking for, if I make it working I will work on some epaper UI implementation since it's my target of use.
Anyway, I just installed bthidhub today (so including latest commit). Everything went smoothly when following the readme (using bullseye raspbian). Connected 1 host (ubuntu 24.04) and 1 mouse (Logi MX master). But a major lag when using the mouse (>2-3s) on host.
I noticed the python process is taking 100% cpu on rasp, even without activity, even when disconnecting both host and mouse.
I tried to profile the remapper.py using cProfile, most of the process is lost inside the asyncio glib routines. Since I am not familiar with asyncio, I don't know what it really means...
I can provide the profile file if pertinent.
Any help welcome, thanks in advance.

[Dreamsorcerer]

I noticed the python process is taking 100% cpu on rasp, even without activity, even when disconnecting both host and mouse.

One issue I found since the upgrade to bullseye is that the switch to master wasn't working. I think this could create an infinite loop.

Locally, I have added a return False as the first line of is_slave() in bluetooth_devices.py, to avoid this. Though I recall lag being significantly reduced when in master mode, so not ideal (but will hopefully get the CPU lower and your lag to <1 second).

I might try the installation on bookworm tomorrow and then see if those commands will work then..

[Dreamsorcerer]

I've also seen the CPU stuck at 100% a couple of other times, which were resolved with a sudo systemctl restart remapper. Haven't figured out what caused those yet...

[zorgluf]

One issue I found since the upgrade to bullseye is that the switch to master wasn't working. I think this could create an infinite loop.

Nice tip, indeed the "proc.communicate()" never return. When your read the stdout line by line it works (proc.stdout.readline(), but never reach the EOF.
If I take the same code inside a seperate test script it works. Maybe it’s due to the use of subprocess inside asyncio tasks ? Sorry, not really familiar with asyncio, so I will be no help on this.
As a work-around, I rewrite the is_slave() with bloking subprocess.Popen call, and it works. Should not have a huge impact since it’s not called very often. I can write a PR if interested, but it’s not a clean fix.
Anyway, it fixes the 100% CPU.

Unfortunately, it does not solve my initial problem : the huge lag is still here, even if the CPU is low. What I experienced is not really a constant lag, but more a low process queue of BT events : if I move the mouse (very) slowly, it’s ok, but if I make a lot of movements, the lag can go up to 10s or more.
I will try to get a hand on an other mouse to see if it’s hardware related.

[Dreamsorcerer]

As a work-around, I rewrite the is_slave() with bloking subprocess.Popen call, and it works.

Hmm, that is weird. Will see if it still happens on bookworm (could be a bug in Python 3.9 that has since been fixed...). Otherwise, I'll have to debug a bit further and see what's happening with asyncio.

Unfortunately, it does not solve my initial problem : the huge lag is still here, even if the CPU is low. What I experienced is not really a constant lag, but more a low process queue of BT events : if I move the mouse (very) slowly, it’s ok, but if I make a lot of movements, the lag can go up to 10s or more.

Hmm, odd. What I get currently, is if I move the mouse constantly, then it feels like it takes maybe 10% longer to process than the rate of events coming in. So, after moving the mouse for 10s, it'll continue moving for about 1s as it catches up. I guess one possibility is that your mouse sends events even more frequently (I'm using an MX Master 3 primarily).

If it is just performance issues, then maybe a newer Python version in bookworm could also help there.

There was also talk about GATT here, though I don't know anything about it myself: #29

[Dreamsorcerer]

Also, are you using the original Zero W, or the new Zero 2?

[Dreamsorcerer]

Hmm, so I have bookworm installing fine now at https://github.com/Dreamsorcerer/bthidhub

But, it seems to be hitting an error when trying to send the message to the connected host over bluetooth.

The switch to master seems to be working fine now though.

[zorgluf]

Also, are you using the original Zero W, or the new Zero 2?

I should have started with that... I am using an hold rasp 2 for testing purpose since my pi0 is still used for an other project. I was thinking the device to be the same, or at least more powerfull, but with similar behavior with python libs. Testing on pi0, I don’t have any such huge lag. Some slow downs however, but might be due to re-using the same SDcard from rasp 2 (didn’t have time to remaster it).
Anyway, it solves my issue and I can start working on some dev for epaper UI or filters.
Really sorry to take your time on such mistake... Thanks a lot for your help.

PS: Should I start dev on https://github.com/Dreamsorcerer/bthidhub fork or stick to this repo ?

[Dreamsorcerer]

PS: Should I start dev on https://github.com/Dreamsorcerer/bthidhub fork or stick to this repo ?

Use that one, I'm migrating the project. Just don't want to redirect from this repo until I have the BT sending fixed.

[Dreamsorcerer]

I am using an hold rasp 2 for testing purpose since my pi0 is still used for an other project.

I think it probably is performance then. I'm not sure if they are the same architecture or not, but the Zero says it's 1GHz, whereas the Pi 2 is 900MHz. If we were able to parallelize it across multiple cores, then it'd perform better on the Pi 2, but that's not how the code currently works.

[Dreamsorcerer]

Another thing for performance I'll look at, is adding Final to module-level variables. This should improve performance when compiled with mypyc.

[Dreamsorcerer]

Hmm, I'm not sure what's happening at the moment. It seem to be getting something from bluez over dbus which has a SocketPathCtrl and SocketPathIntr. Then when it tries to connect to a socket using those paths it fails because the path doesn't exist. (e.g. /tmp/BTIHS_48:68:4A:7A:DF:A9_Ctrl).

Did you try the bookworm install?

[Dreamsorcerer]

Ah, I found it. Some systemd thing. So, bluez sees /tmp/, but on the root filesystem, that is actually /tmp/systemd-private-ae0ff0aa62824c299bdbfbd61cc57d54-bluetooth.service-DLlSUO/tmp/.

Not sure what I need to do to fix it though. Run remapper in the same group as bluez or something?

[zorgluf]

Hum, didn't know this behaviour of systemd. Is it related to this privatetmp option https://serverfault.com/questions/786211/access-files-in-system-tmp-directory-when-using-privatetmp ?

[Dreamsorcerer]

Yeah, just figured that out. Think I'm just going to patch it out. The problem is probably because we are patching out the Debian build with our custom build. The Debian build may have patches or something to expose the sockets somewhere else.

[Dreamsorcerer]

OK, should all be working now, would be great if you could try the bookworm install.
I was wrong about the switch to master though, need to look closer at that to see what's happening.

Any further questions or anything, open in the new repo.