search

erjiang / huion-keys

Linux program to create custom bindings for Huion tablet hotkeys
GNU General Public License v3.0
13 stars 4 forks source link

Better tablet detection #5

Closed NeoTheFox closed 3 years ago

NeoTheFox commented 3 years ago

I decided I want to emulate the Windows driver after seeing it in action, but since you already said before that you prefer keeping it simple I'm going to split the groundwork into smaller improvements that you would be able to pick and choose.

On the Windows (and OSX) driver the dial uses its middle button to switch between 3 different possible bindings. This allows to quickly switch between rotation, zoom, and brush size, for example. However, as far as the underlying USB protocol is concerned the middle button on Q620M is just Button 9, and the actual dial reading never changes as you toggle the modes.

This means that implementing this behavior requires distinguishing between different tablet models in-software and some specific code has to be written on a per-model basis. This change keeps a record of models and makes adding new VIDs and PIDs very trivial for other tablets.

erjiang commented 3 years ago

On the Windows (and OSX) driver the dial uses its middle button to switch between 3 different possible bindings.

We could generalize this by allowing multiple key bindings to be specified for a button. (Not sure about config syntax though.) This way you don't need to change behavior based on tablet.

erjiang commented 3 years ago

Looking at the patch, I'm not sure why TABLET needs to be a global. I assume it's because you want to change behavior based on tablet model, but I'm hoping we can avoid model-specific behavior so that adding more tablets in the future doesn't require looking through a bunch of tablet-specific if-else statements.

NeoTheFox commented 3 years ago

Button 9 in the code would have to either circle what bindings other keys have or be bound to anything itself, this is unavoidable, I believe. However, there is indeed no reason to lock any tablet into this behavior, since any button on any tablet could benefit from circling the bindings, and some users may prefer to bind Button 9 to something else and avoid circling instead (something not possible with "Official" drivers!). But knowing the exact model could help with logs, mindful default config generation, and potentially allowing per-model configuration. I would imagine if someone has a few tablets with different button positioning it would be a general QoL improvement to bind them per-model.

For toggling behavior, my draft idea was to check if the config has dial_cw and dial_ccw keys in it, or dial_cw_a, dial_cw_b and so on in. Then have Button 9 switching between _a, _b, and _c bindings. Potentially with an OSD that shows the current mode when switching, implemented a different software piece like xob that huion_keys.py gets piped into to decouple the code.

erjiang commented 3 years ago

Cherry-picked the .gitignore change but did the tablet-search code slightly differently. See 13e40d0