v3.4.0 — Bluetooth D-Bus leak fix, USB-only mode, Global Settings

Fixed

The Bluetooth reconnect loop leaked a D-Bus connection on every scan (#57)

Before each Bluetooth scan the driver asks BlueZ whether a TourBox is already connected, so it can disconnect one that a Bluetooth manager has grabbed. That check opened a connection to the system bus and never closed it — not on success, not on timeout, not on error. Nothing in the scan path released it either.

With a TourBox present this went unnoticed: the check runs once and the driver settles into a connection. With no TourBox present — powered off, or left at home — the reconnect loop ran the check every ~20 seconds and leaked a connection each time. That is about three a minute, which reaches dbus-daemon's default ceiling of 256 connections per user in a little over an hour.

The reporter started their PC with the TourBox disconnected and later found the driver holding 226 D-Bus connections, with the system bus logging "The maximum number of active connections for UID 1000 has been reached". Other applications could not get on the bus, Failed to get properties: No buffer space available appeared, and the session would not shut down normally. Stopping TuxBox dropped the machine from 281 connections to 55.

Measured here on a TourBox that was switched off, over identical two- and three-minute runs: the old code's open socket count climbed 5 → 11 in two minutes, one per retry cycle. The fixed code held flat at 4 across three minutes, with a single stable bus connection — the one bleak itself keeps and reuses correctly.

Reported by @barrysampson on KDE Neon (Ubuntu 24.04) with a TourBox Elite, including the connection counts and the correct diagnosis that the failed-scan path was to blame.

Failures while enumerating Bluetooth devices now log the reason as well. The report showed a bare Error while enumerating bluetooth devices every cycle, which said nothing about what went wrong.

Added

Choose which connection the driver uses (#58)

If you always use the cable, the driver no longer has to keep looking for a Bluetooth device that is never there. In the Configuration GUI, File → Global Settings → Connect via:

Option	Behaviour
Automatic (default)	USB if the cable is plugged in, otherwise Bluetooth — switching to USB as soon as the cable appears
USB only	Bluetooth is never scanned
Bluetooth only	/dev/ttyACM* is never probed

USB only genuinely leaves the radio alone: bleak is not even imported, and the driver holds no D-Bus connection at all. It also waits for the cable rather than exiting the way --usb does, so the service survives a login with nothing plugged in.

Unset means Automatic, so upgrading changes nothing for existing configurations. The --usb and --ble command line flags still override it.

Global Settings dialog

The [device] section of config.conf could only be edited by hand — including the global modifier_delay that the per-profile dialog referred to but gave no way to set. File → Global Settings now covers the connection mode, USB serial port, forced haptics, modifier delay and window check interval, and offers to restart the driver afterwards, since none of these are re-read while it is running.

Your comments in config.conf are preserved, only the settings you actually change are written, and a timestamped backup is taken before each save.

Changed

• The Bluetooth reconnect backoff now grows to 60 seconds instead of stopping at 10. Every failed attempt already costs a ~10 second radio scan, so the old fixed retry kept the adapter busy roughly half the time for as long as the TourBox stayed off — noticeable on a laptop running on battery. Retries stay quick at first (5s, 8s, 11s…) so a device switched on mid-session is still picked up promptly, then settle at one attempt a minute. That takes the idle duty cycle from about 50% to about 14%, and the delay resets as soon as a connection succeeds.
• The backoff wait is slept in slices, so stopping the service or switching to USB is still noticed within half a second rather than waiting out a minute-long delay.
• Migrating a legacy mappings.conf no longer drops the connection setting.

Upgrade

git pull && ./install.sh
systemctl --user restart tuxbox

If you disabled the driver because of #57, re-enable it with:

systemctl --user enable --now tuxbox

You can confirm the leak is gone by watching the driver's open socket count with no TourBox connected — it should stay flat:

watch -n 5 'ls -l /proc/$(pgrep -f "python -m tuxbox")/fd | grep -c socket'