Auto-highlighting row selections and buttons when a key from the tourbox is pressed.

[Skynse]

I'm going to be picking up some new drawing software that I'm hyped about (Kala) so I'll probably be using my tourbox frequently again. There was one feature I think would make things easier when it comes to mapping.

I created a macropad and some software for it and the desktop app auto highlights or scrolls to row selections, or combos that have been added. What do you think of an addition like this to tuxbox?

Implementation-wise, I don't think it'd be so hard to implement since the row items are already there. Could set it up as a PR after a day if it matches the vision.

[AndyCappDev]

Thanks for the idea, and have fun with Kala!

Good news: most of this is already in TuxBox, and I just re-tested it with 3.6.0 and your new list changes. With the GUI window focused, pressing any button or turning any dial on the TourBox selects that control's row in the Controls Configuration table. It also highlights the control on the controller picture. It's documented under Using Physical Buttons to Select Controls in the GUI guide.

How it works: the driver has a built-in TuxBox GUI profile that switches on when the GUI is focused. It's hidden from the profile list, so it's easy to miss. In that profile, each control sends a Ctrl+Alt+Shift shortcut (F1–F12 or 1–8), and the GUI turns that shortcut back into a row selection. It relies on window detection, so it only works if TuxBox can tell which window is focused on your desktop.

Could you give it a try? If nothing happens when you press a button with the GUI focused, run ./venv/bin/python -m tuxbox.window_monitor from the tuxbox directory and switch between windows. That shows whether TuxBox can see which window is focused on your setup. Let me know your desktop/compositor either way.

The part that doesn't exist yet is combinations. Holding Tall and turning the knob currently selects Tall, then Knob, as separate rows, not the Tall + Knob row in the combinations table. If that's the part you're after, I'd be happy to look at a PR. It's not quite as simple as the single-control case, though. The TuxBox GUI profile doesn't treat any button as a modifier, so the GUI would need a way to tell that one button is still held when a second control fires. Before you start coding, could you outline here how you'd approach that?

[Skynse]

To be fair, I actually haven't rebooted my computer since installing tuxbox from yesterday. That's probably why it isn't working. Will give it a spin and see if there are any issues

[Skynse]

For combinations, I would create a state class storing a set of which keys are pressed (if a global state class doesn't exist), then create a set of pressed keys. I would then check to see if (modifier, control) exists in the combination list.

Before I think about that though, I have to investigate a problem with my tourbox lite not being recognized after rebooting.

I use Fedora 44, Linux 7.2.4-200.fc44.x86_64 running KDE.

edit: Seems to be working now after disconnecting and reconnecting it a bunch of times. Driver wasn't running because i had not enabled it for autostart so it's not a problem

[Skynse]

The approach I had in mind regarding the highlighting would've relied on the raw input bytes being read by the GUI to know which keys are being pressed.

It would essentially be

firmware -> raw HID 0xNN byte -> some hid_bridge.py -> UI layer for processing

I could then keep a set of pressed keys that have not been released, and if two of them are being pressed at the same time, do a lookup.

I'll read more of the driver code first. It was an interesting thought, but not very necessary if the UI already highlights the main control list, especially if the bytes are already abstracted through a function key mapping like Ctrl+Alt+Shift+F-key etc

[Skynse]

Can confirm that after going through the set up more carefully, everything does seem to work in order now. They way I did things before was by manually clicking, which was how I tested the last PR (was safe since I didn't change how keys were picked up)

Screencast_20260929_033029.webm

[Skynse]

I definitely think these should be checkboxes though. Was having a hard time figuring out which one was highlighted lol

[AndyCappDev]

Glad it's all working now, and thanks for the screen recording!

On the combinations: agreed, it's probably not worth it now that single controls are selected automatically. Reading the raw bytes in the GUI wouldn't work while the driver is running anyway, because the driver already holds the USB port or the Bluetooth connection.

On the modifier buttons: I'd like to keep them as toggle buttons. They look like keys, which fits a shortcut editor, and the checked state already has a clear outline in your screenshot (Shift).

Two quick questions:

• Is your Lite the USB or the Bluetooth model? We have a confirmed tester for the USB Lite but not yet for the Bluetooth one. If yours is Bluetooth, I'd like to add you to the Community Testers list in the README.
• The recognition trouble after rebooting, where it took several reconnects: if that happens again, could you open an issue with the output of journalctl --user -u tuxbox -b? I'd like to see what the driver logged while it wasn't finding the device.

[Skynse]

I use the USB version. The connection problem was a result of the driver not actually running. Had to enable it with systemctl so it's all good