|
|
|
@ -1,11 +1,16 @@
|
|
|
|
|
# The problems with overwriting keys
|
|
|
|
|
|
|
|
|
|
If you had one keyboard layout for your mouse that writes SHIFT keys on
|
|
|
|
|
keycode 10, and one for your keyboard that is normal and writes 1/! on
|
|
|
|
|
keycode 10, then you would not be able to write ! by pressing that mouse
|
|
|
|
|
button and that keyboard button at the same time. Keycodes may not clash.
|
|
|
|
|
|
|
|
|
|
**The first idea** was to write special keycodes known only to key-mapper
|
|
|
|
|
**Initial target** You write a symbols file based on your specified mapping,
|
|
|
|
|
and that's pretty much it. There were two mappings: The first one is in the
|
|
|
|
|
keycodes file and contains "<10> = 10", which is super redundant but needed
|
|
|
|
|
for xkb. The second one mapped "<10>" to characters, modifiers, etc. using
|
|
|
|
|
symbol files in xkb. However, if you had one keyboard layout for your mouse
|
|
|
|
|
that writes SHIFT keys on keycode 10, and one for your keyboard that is normal
|
|
|
|
|
and writes 1/! on keycode 10, then you would not be able to write ! by
|
|
|
|
|
pressing that mouse button and that keyboard button at the same time.
|
|
|
|
|
Keycodes may not clash.
|
|
|
|
|
|
|
|
|
|
**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
|
|
|
|
|
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 X/Linux seem
|
|
|
|
@ -13,8 +18,8 @@ to ignore anything greater than 255 for regular keyboard events, or even
|
|
|
|
|
crash in some cases. Mouse click buttons can use those high keycodes though,
|
|
|
|
|
but they cannot be remapped, which I guess is another indicator of that.
|
|
|
|
|
|
|
|
|
|
**The second 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
|
|
|
|
|
**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
|
|
|
|
|
SHIFT as already used in the system default. The pipeline is like this:
|
|
|
|
|
|
|
|
|
|
1. A human thumb presses an extra-button of the device "mouse"
|
|
|
|
@ -30,9 +35,10 @@ SHIFT as already used in the system default. The pipeline is like this:
|
|
|
|
|
mapping to print the overwritten key "1" into the session.
|
|
|
|
|
|
|
|
|
|
But this is a rather complicated approach. The mapping of 10 -> 50 would
|
|
|
|
|
have to be stored somewhere as well.
|
|
|
|
|
have to be stored somewhere as well. It would make the mess of configuration
|
|
|
|
|
files already needed for xkb even worse.
|
|
|
|
|
|
|
|
|
|
**Third idea**: Based on the first idea, instead of using keycodes greater
|
|
|
|
|
**Fourth idea**: Based on the first idea, instead of using keycodes greater
|
|
|
|
|
than 255, use unused keycodes starting from 255, going down. Issues existed
|
|
|
|
|
when two buttons with the same keycode are pressed at the same time,
|
|
|
|
|
so the goal is to avoid such overlaps. For example, if keycode 10 should be
|
|
|
|
@ -41,17 +47,21 @@ 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.
|
|
|
|
|
|
|
|
|
|
So back to the second idea.
|
|
|
|
|
**Fifth idea**: Instead of writing xkb symbol files, just disable all
|
|
|
|
|
mouse buttons with a single symbol file. Key-mapper listens for key events
|
|
|
|
|
in /dev and then writes the mapped keycode into /dev. For example, if 10
|
|
|
|
|
should be mapped to Shift_L, xkb configs would disable key 10 and key-mapper
|
|
|
|
|
would write 50 into /dev, which is Shift_L in xmodmaps output. This sounds
|
|
|
|
|
incredibly simple and makes me throw away tons of code. Branches for all that
|
|
|
|
|
stuff exist to archive it instead of loosing it forever.
|
|
|
|
|
|
|
|
|
|
# The various mappings
|
|
|
|
|
|
|
|
|
|
There are three mappings:
|
|
|
|
|
# The various mappings
|
|
|
|
|
|
|
|
|
|
The first one is in the keycodes file and contains "<10> = 10", which is
|
|
|
|
|
super redundant but needed for xkb.
|
|
|
|
|
There were two mappings: The first one is in the keycodes file and contains
|
|
|
|
|
"<10> = 10", which is super redundant but needed for xkb. The second one
|
|
|
|
|
mapped "<10>" to characters, modifiers, etc. using symbol files in xkb.
|
|
|
|
|
|
|
|
|
|
The second one maps "<10>" to characters, modifiers, etc. using symbol files
|
|
|
|
|
in xkb.
|
|
|
|
|
|
|
|
|
|
The third mapping reads the input keycodes from your mouse (also known as
|
|
|
|
|
system_keycode here) and writes a different one into /dev (also known as
|
|
|
|
|