KarsMulder
Handling of bluetooth input devices (no persistent device name, device may be unavailable at startup)
Scenario: I want to use evsieve to handle a bluetooth remote. I have two issues with that scenario:
The bluetooth remote does register as /dev/input/event*, but not as /dev/input/by-id/* or /dev/input/by-path/*. So I don't have a persistant device name. How can I handle that?
The bluetooth remote is not connected at startup and may get disconnected because of sleep modes during runtime. The last situation can be remedied by "persist=reopen", but I don't know how to handle the first situation.
Basically I would like to have a mode like "evsieve should handle all input devices, regardless of the when they become available to the system". Is this possible?
The bluetooth remote does register as /dev/input/event*, but not as /dev/input/by-id/* or /dev/input/by-path/*. So I don't have a persistant device name. How can I handle that?
Sorry, the current state of evsieve does not provide an easy solution for your problem.
If you're technically inclined, maybe it would be possible to write a custom udev rule which creates a symlink to your bluetooth device whenever it gets connected? The Arch wiki shows that it can create symlinks (and in fact, it is probably the very thing creating most of your links in /dev/input/by-id in the first place), and according to this stackoverflow post, it seems to be possible to trigger udev on bluetooth devices.
The bluetooth remote is not connected at startup and may get disconnected because of sleep modes during runtime. The last situation can be remedied by "persist=reopen", but I don't know how to handle the first situation.
For reasons mentioned in issue #2, this is currently still not possible either. It may become possible in the future if I were to seriously pick up development again.
