More control over uinput devices (Keymapper 2.0 !?)

[jonasBoss]

First of all, this is a great project which enabled me to actually use all the buttons I have on my mouse.

However I feel there is a lot of unused potential. Here is my proposal how we could vastly Improve the functionality:

1. Make the uinput devices independent from the original evdev device.

Currently each evdev device gets it's own uinput device for remapped buttons.
There is a lot of software, especially games, which don't play nice with multiple input devices. They also don't always handle hotplugging of devices.

Making the uinput independent would allow us to unify events from different inputs. We could for example combine joystick and keyboard inputs to create a single Gamepad. The uinput could be persistent, which means unplugging the joystick would not have any effect on the uinput-gamepad. Therefore software using the uinput never experiences hotplugging.

2. Provide a choice whether the original event gets suppressed. (on a per input device and/or event basis)

when mapping keyboard keys to gamepad buttons it might be no issue to let the original keyboard untouched or even a bad idea to have some keys missing because they got remapped to a gamepad.

3. Allow for multiple physical events to be mapped to the same uinput event.

A user might want different buttons to trigger the same event or action.
This should be rather easy for buttons, but could prove difficult for axis when handling multiple simultaneus inputs.

4. Allow a single physical event to be mapped to multiple uinput devices, and events.

I am not quite sure why but I can't really say why not. Surely someone will find a use for it. If it is not to difficult to implement.

5. Create sensible preset and user configured uinput devices (standard devices like keyboard, mouse, gamepad, ...)

We can not really control how the system handles a device (it seems to be mostly determined by the available events) so it is a good idea to provide working preset for standard devices. The user should still have the possibility to define his own Uinput devices.

6. Enabling and disabling the remapping on a per uinput device basis.

plugging a new device (group) in would remap all events which are preset to map on an Currently active uinput device.

This obviously would need a lot of work. From looking through the code for a few hours I would say we need a lot of new frontend code, while the backend (deamon) could be reused for the most part.
The preset files would need to include information on the mapping target. And we would need to store information for the available uinput devices.

I can totally understand If this is out of scope for this project. But I will gladly help where I can. If there is no time or interest to implement such features in here I will probably start working on a fork. I am always happy to get some feedback and advice on this Idea.

[sezanzeb]

1. and 5.:

See #205, this might happen at some point

In the key-mapper-devices branch there is a small step in that direction. There is a keyboard uinput, but one per injection that gets recreated each time. I don't know yet how well uinputs do if multiple processes write to them.

2.:

Would be possible with a macro. For example mapping A to BTN_X: m(KEY_A, h(BTN_X)), this would hold down both keys.

4.:

Can you give an example please?

6.:

plugging a new device (group)

Ah, so you looked into the code a bit?

From looking through the code for a few hours

Confirmed

But I will gladly help where I can

Nice! :)

If you want, you could continue the idea started here: 4b5b3fa (a commit of the key-mapper-devices branch), and

• have the keyboard uinput as a global variable that every injection can import. The question is if it works correctly when child processes fork the main process. If it doesn't work, then maybe the injections should be threads instead. There are some thoughts on the concurrency model in #205
• add gamepad and mouse uinputs
• have a readable way of determining into which uinput an event should go. Either by wrapping each uinput into a class with a certain common interface, or by having one utility function that knows all of the standard uinputs. Or whatever you can come up with.

[sezanzeb]

I'll try to find time to adjust the tests for key-mapper-devices and merge it into main soon. I think it is a good first step in the right direction.

[jonasBoss]

So I did some more digging and testing. I have an Idea how we could go about implementing the uinput devices:

I don't think the key-mapper-devices branch goes in the right direction.

Currently deamon.autoload creates for each group an injector, which then spawns a new process. This new process now creates uinput devices (mapped, forwarded) and starts ConsumerControl.run() for each evdev in the group. ConsumerControl picks up all the events and distributes them to the appropriate uinput devices.

This will not work for unified uinput devices for two reasons (I think):

1. The different processes can probably not write to the same UInput. Luckily Injector can inherit from threading.Thread instead of multiprocessing.Process. I tested this and it works for the most part, there are issues when terminating because the threads need to be stopped properly. We should no longer use multiprocessing.Pipe maybe replace it with queue.Queue.
   This way all the threads have access to the same memory and can write to the same UInput.

2. The mapped UInput devices (consumer) need to be accessible by each ConsumerControl. I think they should be created by the deamon and stored in a global dictionary. This way each ConsumerControl can call each consumer.notify. Since the consumer can not know which ConsumerControl is sending a event the consumer.is_handled() function is obsolete. We should replace it with a consumer.can_handle() function and create a ConsumerControl.is_handeld_by() function which returns the correct consumer.
   The forwarded Uinput can remain as it is.

[sezanzeb]

1.:

I don't have experience with using queue.Queue. If you say that it is better suited then I'm open to seeing how it turns out in the code.

Have you considered using asyncio instead of threads?

2.:

The mapped UInput devices (consumer) need to be accessible by each ConsumerControl

I'm confused by "(consumer)" there. I guess you mean that for example the "key-mapper keyboard" uinput should be accessible by all consumerControls, and there should be only a single uinput of that kind?

Maybe you can give an example

This way each ConsumerControl can call each consumer.notify

Isn't this already happening?

Since the consumer can not know which ConsumerControl is sending a event the consumer.is_handled() function is obsolete

But is_handled doesn't have knowledge about the ConsumerControl already

[sezanzeb]

This way each ConsumerControl can call each consumer.notify

Global uinputs:

• key-mapper keyboard
• key-mapper gamepad

Each injection (thread/process/asyncio-coroutine, one per group) has a ConsumerControl

Each injection process has their own instances of the consumers. The ConsumerControl reads events and sends them to the consumers

Each consumer needs to know into which uinput to write the injected event to

---

or, is the idea that consumers are (just like the global uinputs) singletons throughout the whole daemon? I.e. one keycode_mapper is created in the beginning, and all injection processes use that one

[jonasBoss]

1.:
using Pipe is tasking the kernel to establish the communication, which seems like a lot of overhead considering we no longer have different processes.
I did look into asyncio shortly. here is a good blogpost to compare them: https://leimao.github.io/blog/Python-Concurrency-High-Level/
asyncio should work just as well I tested threads, only because it is the simpler solution to use for the existing code.

2.:

I guess you mean that for example the "key-mapper keyboard" uinput should be accessible by all consumerControls, and there should be only a single uinput of that kind?

that is the idea. lets say we have a gamepad and a mouse with a lot of buttons and we want to map buttons form the gamepad and the mouse to keyboard keys. Currently key-mapper would create two keyboards, one for the gamepad and one for the mouse. But we actually want only one keyboard uinput. Both the mouse and the gamepad should send the event to the same keyboard.

This way each ConsumerControl can call each consumer.notify

Isn't this already happening?

I don't think so. A ConsumerControl can not access a consumer (uinput) from a different Input device.

or, is the idea that consumers are (just like the global uinputs) singletons throughout the whole daemon? I.e. one keycode_mapper is created in the beginning, and all injection processes use that one

I was thinking this. But it should be way is simpler to keep the current structure and only create the Uinput globally.

Global uinputs:

• key-mapper keyboard
• key-mapper gamepad

• key-mapper user defined

Each injection (thread/process/asyncio-coroutine, one per group) has a ConsumerControl

Each injection process has their own instances of the consumers. The ConsumerControl reads events and sends them to the consumers

Each consumer needs to know into which uinput to write the injected event to

That sounds more in line with the current structure and should be simper to implement

[sezanzeb]

But we actually want only one keyboard uinput. Both the mouse and the gamepad should send the event to the same keyboard.

Yes

The keycode_mapper consumer has a state that is unique per injection. It keeps track of keys that are pressed in the source device.

That allows mapping a combination of a+b on keyboard 1 to something, while b is pressed on keyboard 2 without any side effects. If there is only one state for all injections, pressing b on keyboard 2 could trigger the combination that is configured for keyboard 1.

[sezanzeb]

I think it makes sense that each mapped device gets their own instances of consumers. They might do things that are very specific to a preset. If provided with events from all devices they might do unexpected things. Certain features might only be implementable if they are unique per injection.

joystick_to_mouse also has a state that is unique per device. It stores the ABS range of gamepads in self

[jonasBoss]

Do we have some well defined rules which key combinations should override other combinations when we have mapping keys like a+b+c, a+c and b+c+d?

I am currently working on refactoring keycode_mapper okay, more like the whole injection process. The goal is to have a super flexible mapping system. Each mapping can have unique parameters. key to key mapping already works and combination to key as well but if the keys and combinations overlap we get an whole lot of undefined behavior.

If you want to look at the current progress: https://github.com/jonasBoss/key-mapper/tree/refactored-injection
Should I already create a draft pull request?

In the end we should be able to map a joystick axis to a joystick axis and introduce an offset, expo, or any other transformation we can think of and all that on a mapping per mapping basis.

[sezanzeb]

Do we have some well defined rules which key combinations should override other combinations when we have mapping keys like a+b+c, a+c and b+c+d?

Only that

• a+b+c and b+a+c are equivalent
• a+b triggers before a+b+c, and both will eventually trigger. Similarly, a+b+c should trigger first, and then when pressing d, b+c+d should trigger.

In the case of a+b+c and a+c, I don't know what should happen. Maybe it should trigger both?

[sezanzeb]

If there is a pull request it will be easier for me to see all the changes, yes please

[sezanzeb]

I'm looking forward to what you are coming up with.

The current system is a bit complicated (due to those data structures among other things), but at this point it is also really stable. I hope that the existing tests work for your changes and are a help for you.

I tried my best to make the keycode_mapper as good as I could, but the nature of things really makes things difficult. Major problems were:

• scroll wheels don't report release events (which is why keycode_mapper is debouncing the release)
• joystick d-pads report -1, 0 and 1
• how a+b+c and b+a+c are equivalent
• and maybe more that I don't remember right now