3 ms·

That's one of the reasons why custom keyboards are in demand: you can do all the remapping on firmware level (QMK, etc) and they will work in any application an

by sesm 3y ago

That's one of the reasons why custom keyboards are in demand: you can do all the remapping on firmware level (QMK, etc) and they will work in any application and any OS.

danhau 3y ago
I have been using Vortex POK3R keyboards for a while now and I really enjoy their IJKL arrow keys. I like it so much that it has become a hard requirement for any new keyboard for me. Unfortunately, this rules out most keyboards without flashable firmware support.
- eviks 3y ago
  Isn't this type of arrow layer also the easiest to rebind in software (using mod+JKL: to not have to move hand off home row) so you could continue to use any hardware keyboard?
zokier 3y ago
That is very rose-tinted view of the situation. Crucially the keyboard can not bypass the input handling layer of OS, it can only send simple scancodes. That has huge implications on how KB firmware level key remappings work; you can only send scancodes that the OS has in the keymap, and the resulting key press event is still completely dependent on the current keymap. Furthermore, to accomplish more complicated mappings the keyboard will end up sending multiple scancodes, possibly with modifiers, on single keypress, which can make creating application level keybindings problematic. Ultimately I think the USB HID protocol is bit too crude for these programmable keyboards, because now I need to juggle two sets of keymaps (one on KB side and another on OS side) to accomplish what I want, and it in no way works reliably across computers or OSs. Either that, or OSs should provide better facilities for remapping stuff and handling arbitrary layouts so that keyboards can revert back to being dumb again.
- csdvrx 3y ago
  > That is very rose-tinted view of the situation. Crucially the keyboard can not bypass the input handling layer of OS, it can only send simple scancodes This. Also, even if trying to do without a keyboard (I can't carry one anywhere I go, but I can prepare scripts and environments!), "advanced" scripts can confuse the input handling layer. > Either that, or OSs should provide better facilities for remapping stuff and handling arbitrary layouts so that keyboards can revert back to being dumb again. Even if you have better facilities, it's never perfect: I have a Caps to Esc+Control directly on the wayland composer that is quite reliable: Hyprland has advanced options to do key binding and remapping (https://wiki.hyprland.org/Configuring/Binds/ https://wiki.hyprland.org/Configuring/Binds/) which is a wonderful thing to have when your workflow is keyboard centric. However, gvncviewer sometimes gets its Caps status confused, and I have to close it and start it again to have access to the unshifted symbols (while it still works for the letter... so it does something like Shift Lock, and while I would love it to work well I can't spend time on just 1 application that refuses to work well with the settings every other application seems to be fine with.
eviks 3y ago
Except that firmware is blind to the state of the application (or even which app you're using), which hampers the dream of any OS/any app

by sesm 3y ago

That's one of the reasons why custom keyboards are in demand: you can do all the remapping on firmware level (QMK, etc) and they will work in any application and any OS.

danhau 3y ago

I have been using Vortex POK3R keyboards for a while now and I really enjoy their IJKL arrow keys. I like it so much that it has become a hard requirement for any new keyboard for me. Unfortunately, this rules out most keyboards without flashable firmware support.

eviks 3y ago
Isn't this type of arrow layer also the easiest to rebind in software (using mod+JKL: to not have to move hand off home row) so you could continue to use any hardware keyboard?

zokier 3y ago

That is very rose-tinted view of the situation. Crucially the keyboard can not bypass the input handling layer of OS, it can only send simple scancodes. That has huge implications on how KB firmware level key remappings work; you can only send scancodes that the OS has in the keymap, and the resulting key press event is still completely dependent on the current keymap. Furthermore, to accomplish more complicated mappings the keyboard will end up sending multiple scancodes, possibly with modifiers, on single keypress, which can make creating application level keybindings problematic. Ultimately I think the USB HID protocol is bit too crude for these programmable keyboards, because now I need to juggle two sets of keymaps (one on KB side and another on OS side) to accomplish what I want, and it in no way works reliably across computers or OSs. Either that, or OSs should provide better facilities for remapping stuff and handling arbitrary layouts so that keyboards can revert back to being dumb again.

csdvrx 3y ago
> That is very rose-tinted view of the situation. Crucially the keyboard can not bypass the input handling layer of OS, it can only send simple scancodes This. Also, even if trying to do without a keyboard (I can't carry one anywhere I go, but I can prepare scripts and environments!), "advanced" scripts can confuse the input handling layer. > Either that, or OSs should provide better facilities for remapping stuff and handling arbitrary layouts so that keyboards can revert back to being dumb again. Even if you have better facilities, it's never perfect: I have a Caps to Esc+Control directly on the wayland composer that is quite reliable: Hyprland has advanced options to do key binding and remapping (https://wiki.hyprland.org/Configuring/Binds/ https://wiki.hyprland.org/Configuring/Binds/) which is a wonderful thing to have when your workflow is keyboard centric. However, gvncviewer sometimes gets its Caps status confused, and I have to close it and start it again to have access to the unshifted symbols (while it still works for the letter... so it does something like Shift Lock, and while I would love it to work well I can't spend time on just 1 application that refuses to work well with the settings every other application seems to be fine with.

eviks 3y ago

Except that firmware is blind to the state of the application (or even which app you're using), which hampers the dream of any OS/any app