Archives/input-remapper
2
0
Fork 0
mirror of https://github.com/sezanzeb/input-remapper synced 2024-11-08 07:10:36 +00:00
Code Issues Packages Projects Releases Wiki Activity

update HELP.md

Browse Source
This commit is contained in:
sezanzeb 2020-11-18 13:28:48 +01:00
parent d2417500fb
commit 38510d5390
1 changed files with 8 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
HELP.md
View File

@ -17,10 +17,8 @@ This was quite mature, pretty much finished and tested.
**The second idea** was to write special keycodes known only to key-mapper **The second idea** was to write special keycodes known only to key-mapper
(256 - 511) into the input device of your mouse in /dev/input, and map (256 - 511) into the input device of your mouse in /dev/input, and map
those to SHIFT and such, whenever a button is clicked. A mapping would have those to SHIFT and such, whenever a button is clicked. A mapping would have
existed to prevent the original keycode 10 from writing a 1. But Linux seems existed to prevent the original keycode 10 from writing a 1. But this device
to ignore anything greater than 255 for regular keyboard events (EDIT: I think doesn't have the capabilities set for those keycodes, so it won't use them.
this is because of the device capabilities), or even crash X in some cases when
something is wrong with the configuration.
**The third idea** is to create a new input device that uses 8 - 255, just **The third idea** is to create a new input device that uses 8 - 255, just
like other layouts, and key-mapper always tries to use the same keycodes for like other layouts, and key-mapper always tries to use the same keycodes for
@ -43,16 +41,11 @@ have to be stored somewhere as well. It would make the mess of configuration
files already needed for xkb even worse. This idea was not considered for files already needed for xkb even worse. This idea was not considered for
long, so no "third" branch exists. long, so no "third" branch exists.
**Fourth idea**: Based on the first idea, instead of using keycodes greater **Fourth idea**: Based on the second idea, instead of using keycodes greater
than 255, use unused keycodes starting from 255, going down. Issues existed than 255, use unused keycodes starting from 255, going down. For example
when two buttons with the same keycode are pressed at the same time, pressing key 10 triggers key-mapper to write key 253 into the /dev device,
so the goal is to avoid such overlaps. For example, if keycode 10 should be while mapping key 10 to nothing. This has the same problem, the device
mapped to Shift_L. It is impossible to write "!" using this mapped button capabilities ignore many of those keycodes. 140 works, 145 won't, 150 works.
and a second keyboard, except if pressing key 10 triggers key-mapper to write
key 253 into the /dev device, while mapping key 10 to nothing. Unfortunately
linux just completely ignores some keycodes. 140 works, 145 won't, 150 works.
EDIT: I think this is because of "capabilities", however, injecting keycodes
won't work at all anyway, see the fifth idea.
**Fifth idea**: Instead of writing xkb symbol files, just disable all **Fifth idea**: Instead of writing xkb symbol files, just disable all
mouse buttons with a single symbol file. Key-mapper listens for key events mouse buttons with a single symbol file. Key-mapper listens for key events
@ -90,6 +83,7 @@ keycode, use a custom mapping that starts at 255 and just offsets xmodmap
by 255. The correct capabilities need to exist this time. Everything below by 255. The correct capabilities need to exist this time. Everything below
255 is disabled. This mapping is applied to key-mappers custom /dev node. 255 is disabled. This mapping is applied to key-mappers custom /dev node.
It's pretty similar to the second idea.
# How I would have liked it to be # How I would have liked it to be