lkml.org 
[lkml]   [2018]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[RFC PATCH 0/4] Add specific vt input's key map
Date
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(-)

--
2.18.0

\
 
 \ /
  Last update: 2018-08-23 00:00    [W:0.067 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site