Hierarchy-based multi-keyboard capture

[AlienKevin]

I use both a Bluetooth keyboard and the laptop keyboard, so it would be nice to support both simultaneously. However, I imagine this would not be very simple so I request a (what I perceive) simpler step towards this goal: list all the names of keyboards you want to support in order of preference and pick the next one on the list when the current one disconnects. A sample config file might look like this:

Name="<Bluetooth keyboard name>"
Name="<Laptop keyboard name>"

So when the computer starts, the first Name will be picked. When the Bluetooth keyboard is disconnected, look for the next Name in line and try to connect that. If all the Names are not available, output error message.

[donniebreve]

The repo I forked initially does something similar to what you are asking for, so it is possible. I will take a look at it.

[AlienKevin]

Excellent! I wish I could help but unfortunately, I don't know much about C and Linux system.

[donniebreve]

Didn't mean for this to close, as it's not completely fixed.

From what I can tell, doing what you originally asked for would be very difficult. I will still look at it though.

For now, I've added the ability to put multiple device entries in the config file, and the application will cycle through them in order and attempt to bind to the device. Although it isn't automatic, when you plug in or unplug your other keyboard, you could now simply restart the touchcursor service and it should pick up the correct keyboard.

[NeKJ]

In my opnion, the proper way would be to be able to hook on all keyboards, not only on the first one. And with a udev rule (or systemd perhaps?) you could sent a sighup signal which will look for new or removed keyboards to attach to/unattach from.

[donniebreve]

Completely agree, and the way the dvorak project does it is by creating a new instance of the application for each keyboard that appears.

[NeKJ]

I can work on it at the weekend, just need a few pointers to start. Can you describe what needs to be done so I can jumpstart on it?

[donniebreve]

If we go the path of spawning a new instance for each keyboard, then you would follow the dvorak project and use systemd triggers, which I am not very familiar with. I'm also unfamiliar with udev. If we go the path of what we are doing in the macOS port, we would provide some interface to choose the active input keyboard. Maybe some terminal ctl executable?

I'm slightly partial to the second option just because it would more closely resemble the macOS port.

Just for information, the Windows port hooks in with the OS and automatically receives all keyboards input.

[NeKJ]

We should choose the most performant and least costly way. I think the right way is to have an different instance, or maybe a thread for each keyboard input. I don't know about the macOS way. And I think that the original Windows version has issues (especially with performance, as it stutters and is slow when the system under high system load). I prefer to keep things as simple as they can be.

I know Systemd and udev well enough to implement whatever it is need to make it work. However I don't have a clue how are we supposed to refresh the keyboard list and attach/dettach instances/threads on them. Would the be difficult?

[1999shaswat]

Didn't mean for this to close, as it's not completely fixed.

From what I can tell, doing what you originally asked for would be very difficult. I will still look at it though.

For now, I've added the ability to put multiple device entries in the config file, and the application will cycle through them in order and attempt to bind to the device. Although it isn't automatic, when you plug in or unplug your other keyboard, you could now simply restart the touchcursor service and it should pick up the correct keyboard.

How to do this? How to write config file to get this functionality?

[donniebreve]

@1999shaswat just put two lines in the config with the keyboard name. If the program can't find the first, it will try the second.

[donniebreve]

46 brought this up again. I think we should implement something like a systemd or udev trigger to create a separate instance for each keyboard.

Do we need a *ctl application to terminate/restart all instances of touchcursor-linux?

[Adda0]

I agree that creating a separate instance for each keyboard in the list currently present in the system is the right way of implementing this functionality. However, I am not sure which way of creating said instances would be the best for our uses. The suggested systemd or udev triggers should work fine, I believe. That is just a guess, though. And restarting multiple instances can be done in multiple ways. For example, some options shown in Restart multiple instances of a service with one command could be used. Or Manage multiple service instances with systemctl, which would make use of exactly what I am thinking about using for #42 (use of @ for the service name with possible debug options after @ when running the service).

Right now, I am working on #27. I have a working prototype in C++ with a reference config file, for example, test config file. The prototype implements options to set multiple hyper keys, set mappings for only a specific hyper key alone, and set mappings common to all hyper keys. #47 is already included. After some much-needed code clean-up, the prototype should be pretty usable, even if just as a derivative of touchcursor-linux if we do not want to port touchcursor-linux to C++. Implementing the same in C would be… painful, but of course, entirely possible. However, to my knowledge, the changes proposed in this issue should be applicable to both versions. Therefore, hopefully, we can think of a way to make them work with either version.

[alexmlh]

Hello, thank's for the program. Can you add support for multiple hyper keys ... it would be great!!