First time posting, but I’m not sure if this has been documented before.
For background, the main thing I use Bluetooth for is game controllers - I swap between a good dozen of them often, depending on the game or emulation system. But a few of them seem to have a common issue - an 8bitdo SN30 Pro and a Retro-Bit Wireless-BT Sega Saturn, using Xinput modes respective to each.
They work fine, except for whenever there isn’t any input within a 3 second window, then the next button press has a noticeable lag–as if it’s trying to wake up. This is consistent over wireless, but not a problem when using them over USB, as to be expected.
BUT, if I also connect either a DualShock 3, or a Switch Pro Controller, and let them idle in the background while paired, then there’s absolutely no wakeup lag on the 8bitdo/Retro-bit pads. Similar can be said if I pair both SN30 and Saturn controllers and, just for example, I jiggle the directional pad around in circles on one while cautiously tapping buttons on the other in the same interval where the lag would present itself–where it doesn’t.
So, it sounds like it must be a Bluetooth adapter sleep issue?
To make a weird story short, my wireless setup is a BCM94360CD inside this PCIe adapter, and the BT device is recognized by lsusb as: Bus 001 Device 004: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth)
I’m completely inexperienced with Bluetooth on Linux atm, but is there some kind of adapter power savings I’m missing? This is a desktop without TLP or anything like it installed.
ThatOneSong - Welcome to EndeavourOS …
not sure how helpful this will be, but I have a bluetooth wireless mouse that shows a similar behavior. In my case, it’s a battery-saving feature of the BT mouse. Not anything I can address through Linux modules/configuration nor through my laptop hardware settings. I’ve just learned that after not using the mouse for a while I need to give the mouse-wheel a scroll or click one of the buttons and wait a second or two for it to wake up.
You might want to search to see if you can find any background on the controllers in question to see if they put themselves to sleep for any battery saving.
Appreciated, but I couldn’t find any such thing on either controller. And I doubt it’s a power savings on the pads themselves - they’re supposed to sleep after a minute at least.
Plus considering the ‘wakeup’ latency is completely mitigated by simply having a DualShock or Switch ProCon idling in the background, it leads me to believe it’s nothing to do with the pads but the Bluetooth adapter itself.
It’s a Broadcom though; it honestly wouldn’t surprise me, nor be the first time it just does weird shit on its own. I’m planning on getting a replacement WiFi/BT adapter in the future, but it would still give me peace of mind if there is in fact some adapter power savings that I’m missing here.
1 Like
Self-bumping update:
I’ve held off on posting further assuming it may have been a symptom of my (admittedly aging) Broadcom wireless chipset, so in the interim I bought a new in-box Intel AX200 desktop kit that conveniently works directly with my motherboard. It should provide Bluetooth 5 functionality and improve matters.
However, while noticeably improved, I can still feel the wakeup lag with my more conventional controllers, and is still only fixed by using/having a Switch controller or DualShock on the same line.
Searching elsewhere has also yielded no results at all pertaining to this issue; everything else only seems to assume general lag, whereas in this case I can tell it’s at a driver/adapter level and not the controllers. I’m not even sure if Bluetooth power savings are a thing on Linux, short of TLP–which considering this being a desktop, doesn’t sound all too useful.
I’m still seeking resolution on this, unfortunately.