jonasBoss

I am not sure what the issue is. Can you describe in more detail what you did in the logs, and what you expected? The last two key presses in...

Inputremapper only considers the `EV_KEY` events and they all report the code 240. Which explains your issue. According to the [linux kernel docs](https://www.kernel.org/doc/html/latest/input/event-codes.html?highlight=wheel_hi_res#ev-msc) `EV_MSC` can be anything. So it is...

Possibly the same issue: #452

> I wonder if syn-reports are guaranteed to wrap only single complete key events, and if waiting for the final syn-report never causes additional latency I think so according to...

> Would any other class besides `Reader` and `EventReader` require changes? Yes, most likely many others. We use the `InputEvent` all over the codebase as a hash or part of...

Yes this is probably possible, but I don't like it. I think we are better off creating a seperate class for the InputConfiguration (which is also used as a hash)...

@sezanzeb I think we need to include the origin of each event for a mapping. Otherwise we will not be able to fix both, this issue and #517 You know...

This needs a better solution than my attempt from above. #517 demonstrates a different failure mode rooted in the ambiguity of just using the event type, code and group name...

the name will not work for a razer naga trinity, but at least the `phys` is unique ``` phys = 'usb-0000:29:00.3-1/input0', uniq = '00000000001A', version = 65537, name = 'Razer...

This should be a good example for a `RelToRelHandler`