All of lore.kernel.org
 help / color / mirror / Atom feed
From: Remi Pommarel <repk@triplefau.lt>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	linux-kernel@vger.kernel.org
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
	Kees Cook <keescook@chromium.org>,
	Elie Roudninski <xademax@gmail.com>,
	Remi Pommarel <repk@triplefau.lt>
Subject: [PATCH 0/4] Add specific vt input's key map
Date: Tue, 11 Sep 2018 22:23:55 +0200	[thread overview]
Message-ID: <cover.1536695070.git.repk@triplefau.lt> (raw)

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:

- 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 ?

- 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.

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


             reply	other threads:[~2018-09-11 20:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-11 20:23 Remi Pommarel [this message]
2018-09-11 20:23 ` [PATCH 1/4] drivers/tty/vt/keyboard.c: refactor getting/setting a keymap entry Remi Pommarel
2018-09-11 20:23 ` [PATCH 2/4] drivers/tty/vt/keyboard.c: add keyboard config for each vt's input Remi Pommarel
2018-09-11 20:23 ` [PATCH 3/4] drivers/tty/vt/keyboard.c: Make key_down[] bitmap input dependent Remi Pommarel
2018-09-11 20:23 ` [PATCH 4/4] drivers/tty/vt: add ioctl to manage input specific keyboard configs Remi Pommarel
2018-09-12 14:35 ` [PATCH 0/4] Add specific vt input's key map Alan Cox
2018-09-12 17:03   ` Remi Pommarel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1536695070.git.repk@triplefau.lt \
    --to=repk@triplefau.lt \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xademax@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.