Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add mappings for Pause, Break, ScrLK, SysRq #20

Open
almson opened this issue Mar 21, 2016 · 5 comments
Open

Add mappings for Pause, Break, ScrLK, SysRq #20

almson opened this issue Mar 21, 2016 · 5 comments

Comments

@almson
Copy link
Contributor

almson commented Mar 21, 2016

Recent Lenovo keyboards copy Apple by omitting Pause, Break, ScrLK, and SysRq keys. Since these keys are sometimes necessary for PCs (unlike for Macs), they're emulated using Fn+ combinations. I propose to support these same combinations in the driver without a configurable option, since I don't believe there exists a competing way to map them.

Break (Fn + B)
SysRq (Fn + S)
ScrLK (Fn + K)
Pause (Fn + P)

Reference: https://support.lenovo.com/ua/uk/documents/ht074004

@almson
Copy link
Contributor Author

almson commented Mar 21, 2016

Actually, Dell keyboards also sometimes don't have these keys. Dell didn't settle on a standard mapping. Looks like they're all over the place with different models. I would still adopt the Lenovo standard.

@Aetf
Copy link
Contributor

Aetf commented Mar 22, 2016

I would say we are making the driver a fully programmable one by adding more mapping options like this 😄. Then definitely we should get the underlying remapping logic right first.

@free5lot
Copy link
Owner

free5lot commented Jun 11, 2017

Well, I got the idea, but not sure if it is desired by people or not. Let this issue be a long term feature request.

@almson
Copy link
Contributor Author

almson commented Aug 20, 2021

The real reason for these keys is to use Magic SysRq. (Ie, we need at least SysRq.) Magic SysRq fixes OOM freezes and has other uses.

@fvsnippets
Copy link

Hi!
For the Magic SysRq issue, I am using a workaround that mixes udev, xmodmap (I know that this won't work on Wayland but there are alternatives for that... but I don't use wayland, yet) and loadkeys.

Basically what I do is:

  1. I remap my CapsLock physical key to sysrq keycode using udev. As far as I understand the kernel will know about this "mapping", so It can known when both "SysRq" (CapsLock) and "Alt" key are pressed in conjunction. It wil "take" the event and wont propagate it to the rest of the system (i.e. you can't use Alt+SysRq [CapsLock] for other actions).
  2. I (re)remap sysrq xmodmap keycode to Caps_Lock keysym. This is a mapping only know by the X environment.
  3. I (re)remap sysrq loadkeys keycode to Caps_Lock keysym. This is a mapping only know by the "consoles" (TTYs) environment.

So, CapsLock will continue acting as a normal CapsLock key without Alt being pressed. But with Alt pressed, CapsLock will act as SysRq.
As far as you don't need to use the Alt-CapsLock combination for other things, then this workaround should be enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants