Skip to content

RFC Add specific vt input's key map

Remi Pommarel lkml 1 version In review

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest4 patches 3 repliesIn review

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/4drivers/tty/vt/keyboard.c: refactor getting/setting a keymap entrydrivers/tty/vt/keyboard.c+118 -830 replies
2/4drivers/tty/vt/keyboard.c: add keyboard config for each vt's inputdrivers/tty/vt/keyboard.c+171 -270 replies
3/4drivers/tty/vt/keyboard.c: Make key_down[] bitmap input dependentdrivers/tty/vt/keyboard.c+32 -140 replies
4/4drivers/tty/vt: add ioctl to manage input specific keyboard configsdrivers/tty/vt/keyboard.c drivers/tty/vt/vt_ioctl.c fs/compat_ioctl.c +2 more+151 -00 replies

Reviews trailers per patch

None of the 4 patches has a Reviewed-by or Acked-by.

PatchElie Roudninski
1/4T-b
2/4T-b
3/4T-b
4/4T-b

Trailers given in replies are filled; those carried in the patches from earlier versions are outlined with dashes.

Read the v1 thread

Cover letter [RFC PATCH 0/4] Add specific vt input's key map

This patchset adds a way to have a specific keyboard config (i.e. keycode to keysym map) for a vt attached input.

Because one can have different keyboards with different layouts on the same VT, it can be useful to be able to associate a different keymap with a different input. In order to do so this patchset introduces three new ioctls:

1) KDGKBIENT
Get an input key map's entry. If the input does not have a specific key map the requested entry is fetched from global key map.

2) KDSKBIENT
Set an input key map's entry. If the input does not yet have a specific key map, a new one is created with the current global key map content copied in.

3) KDSKBIRST
Reset an input key map. The input does not use a specific key map anymore and keycode translations are done with global key map.

In order to keep old behavior compatibility and not waste memory, an input uses the global key_maps[] array by default and KDGKBENT/KDSKBENT ioctls still get/set entries in this global key map. The specific key map is only allocated on the first call to KDSKBIENT.

A patch for loadkeys is ready to be sent to the ML if this patchset seems sane to you.

Here are some questions I had while doing this patchset:

- Maybe there is a way, I am not aware of, that can allow one to use different keyboard layout on same VT ?

- Is it ok to add new ioctl to old legacy code ? I added those ioctl the old way in order to match the header style. Maybe it is better to use the __IO* macros ?

- Should key_down bitmap be really input specific (i.e. PATCH 3/4) ?

- I am not quite sure about the meaning of keymap_count. IIUC, it is a counter of used keymap function arrays statically or dynamically allocated. If it is not the case, the modificiation in kc_setent() that decrements keymap_count even if a statically keymap function is removed with "K_NOSUCHMAP" (in PATCH 2/4) may be wrong ?

- kbd_detach_conf is a bit clumsy because it tries to copy a shared sparse pointer array without using GFP_ATOMIC.

- Is this patchset even a sensible idea ?

Remi Pommarel (4):
drivers/tty/vt/keyboard.c: refactor getting/setting a keymap entry drivers/tty/vt/keyboard.c: add keyboard config for each vt's input drivers/tty/vt/keyboard.c: Make key_down[] bitmap input dependent drivers/tty/vt: add ioctl to manage input specific keyboard configs

 drivers/tty/vt/keyboard.c | 531 ++++++++++++++++++++++++++++++--------
 drivers/tty/vt/vt_ioctl.c |   9 +
 fs/compat_ioctl.c         |   3 +
 include/linux/vt_kern.h   |   4 +
 include/uapi/linux/kd.h   |   9 +
 5 files changed, 452 insertions(+), 104 deletions(-)
Signature · 1 line
2.18.0