We need a global keymap #1685
Comments
|
https://medium.com/@damko/a-simple-humble-but-comprehensive-guide-to-xkb-for-linux-6f1ad5e13450 https://stackoverflow.com/questions/51942865/how-hid-scancodes-are-mapped-to-evdev-codes
https://source.android.com/devices/input/keyboard-devices#hid-keyboard-and-keypad-page-0x07 |
|
An improved variant encodes keyboard layer information: {
LPinky = {
main = "0x001e"; # has no layers -- damn, needs solution. emulate layers with a layer modifier combo?
atreus = {
layer1 = "0x001e"; # KEY_A
layer2 = "0x0006"; # KEY_5
layer3 = "0x0066"; # KEY_HOME
};
};
}There is a problem, though: layers and modifiers are potential substitutes on keyboards that support layers. If a keyboard supports layers, one would probably always want to prefer layers over modifiers since those can piggyback on the layer muscle memory already trained for actual key symbol output in a text input situation. To accommodate for this circumstance, and to stay true to the ideals of muscle memory identifiers, we would have to define a layer emulation mechanism for non-layer keyboards, potentially waving modifier keys all-together (or at least certain combinations to be used for emulated layer switching) — if you really mindful of preventing Repetitive Strain Injuries when traveling with your laptop without your custom keyboard or working with your environment on a foreign machine, you could map them to a foot pedal switches which you would still have to carry. (But then I guess, we would have to settle on not relying on kxb but work with evdev events directly... hmmm) {
board = {
main = {
layermods = {
layer1 = [ ];
layer2 = [ "0x007d" ]; # KEY_LEFTMETA
layer3 = [ "0x007d" "0x0038" ]; # KEY_LEFTMETA + KEY_LEFTALT
};
};
};
}If that was to work, people would possibly opt for using two layers (firmware implemented or emulated through this proposal) + classical modifiers (implemented in the application) to get acceptable performance in a mixed keyboard scenario. |
|
Here's my understanding of your proposal: What problem would this alleviate?
Questions How does this compose with the varying existing software working with keybindings?
Technically, how do you propose this should work? Implementing something with evdev seems completely out of scope for Home Manager (and sounds like another key daemon IMO). |
If there exists Example: {
# assume sway-ish
config = ''
bindcodes ${f([LPinky Rpinky],2,[])} command
''
# TODO: add sugar to the syntax
# if this is an illegal keychord in app,
# which it is in sway, then f shall alert out
}So far so good. But this assumes global statefulness of the selected keyboard for the current generation. And most applications cannot bind to keycodes directly, so global keylayout state is conclusively assumed, too. I suppose, application support migh be so poor in some instances, that the only workaround that could reliably produce acceptable outcomes is deduplicating configs for keylayouts*keyboards and invoking applications from a wrapper that selects config based on:
Of course, if an application supports adaptive behaviour per keyboard / keylayout, then a conditional configuration should be crafted by means of discovering keyboards and keylayouts from the configuration. Seems like trouble. But pain is temporary, glory is forever. And this broken system (mnemonics 2 muscle memory 2 command) ought to be fixed in favor of true ergonomics (muscle memory 2 action).
I think, while I could give a relatively good answer for chording, a solution for sequences is a little more involved. First, hotkeys are always chorded. It is only a modal keyboard driven command language that requires for sequenced input. In principle, the same shortcutring of mental load should apply (muscle memor 2 action VS mnemonic 2 muscle memory 2 action). An implementation of sequencs would be very much application specific, but at first glance We might rather think of ways to treat Imagine:
On the other hand, after this initial thought, it occurs to me that the more probable use case might be that a modal command mode is initiated by simple chording ( |
|
It occurs to me that in addition to a location identifier ( Those can have alternate bindings such as: {
up = [
LRing
RRing
];
}so |
|
Please also note, if we attempt a solution as a community, we start to generate upstream backpressure so the problem gets a fair chance of a genuine fix throughout. RSI is a relative recent medical condition: I prospect at an overall level input ergonomics are still in its infant state. Why does it matter? Only a global (location identified!) keymap will unlock the next level (of practically configurable) input ergonomics. ("as first seen on nix" TM) |
|
I just so noticed that In the absence of a solution, the signature would have to be |
|
Do i understand this correctly?:
If this is right, we get the problem that for every existing keybinding we have to define a new "default" keybinding. e.g. I love thinking about alternative keyboards and stuff like that but in my experience the general user absolutely hates if any shortcut changes for no matter what reason... |
|
@Melkor333 Your interpretation is correct. But with a little twist: A new user would globally across home-manager "train" its layout onto the position key names ( If
|
|
Thank you for your contribution! I marked this issue as stale due to inactivity. If this remains inactive for another 7 days, I will close this issue. Please read the relevant sections below before commenting. If you are the original author of the issue
If you are not the original author of the issue
Memorandum on closing issuesIf you have nothing of substance to add, please refrain from commenting and allow the bot close the issue. Also, don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort. |
|
I desist from promoting this, but encourage anyone to take this as inspiration. |
Issue description
That is what — in principle — we need (here encoded as sway config):
Ctrl+His not rendered asBackSpaceto the terminal program.in configs throughout we would then write:
Meta
Maintainer CC
Technical details
evdev keycodes are invariants across the entire software stack and are the source representation most suitable to map into a coordinate based location reference. Alternatively, we might want to use
xkbscancodes as utilized incat /usr/share/X11/xkb/keycodes/evdevwhich are catched through evdev config on input events of interest and offset by 8 vs evdev codes. KBX does map those codes to internal symbols representation which resemble location identifiers for most keys (eg<AE01>), but keys that have a special shape on traditional keyboards (eg<SPACE>). Hence kbx internal symbols are not a reliable location identifier, for example on an Atreus.how sway/i3 identify them keyboards:
Applications prefer key codes if supported; and if not depend on keyboard layout, which configuration needs to accommodate for.
All applications: same goes with one degree of freedom less for firmware remaps (atreus example).
cat /proc/bus/input/devicesThe text was updated successfully, but these errors were encountered: