qemu carries a bunch of reverse keymaps in pc-bios/keymaps/, to map
keysyms it receives from vnc clients back to keycodes.  These keymaps
seem to be buggy and incomplete at times.  So, to tackle the issue once
for all, I've written a tool to generate those maps from xkb keyboard
layout data using libxkbcommon.

This patch series only adds the tool, it doesn't touch the maps in
pc-bios/keymaps/ yet.  I want some testing feedback first ...

How to test:
  (1) generate a map: "qemu-keymap -f testmap -l $layout"
  (2) use the map: "qemu -vnc $display -k testmap"

Gerd Hoffmann (3):
  keysym: add next and prior
  ui: move qemu_input_linux_to_qcode()
  Add qemu-keymap tool.

 configure          |  23 +++++
 Makefile           |   5 ++
 include/ui/input.h |   1 +
 ui/curses_keys.h   |   2 +
 ui/vnc_keysym.h    |   2 +
 qemu-keymap.c      | 243 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 ui/input-keymap.c  | 115 +++++++++++++++++++++++++
 ui/input-linux.c   | 113 -------------------------
 8 files changed, 391 insertions(+), 113 deletions(-)
 create mode 100644 qemu-keymap.c

-- 
2.9.3

On Mon, Jul 24, 2017 at 04:01:14PM +0200, Gerd Hoffmann wrote:
> qemu carries a bunch of reverse keymaps in pc-bios/keymaps/, to map
> keysyms it receives from vnc clients back to keycodes.  These keymaps
> seem to be buggy and incomplete at times.  So, to tackle the issue once
> for all, I've written a tool to generate those maps from xkb keyboard
> layout data using libxkbcommon.
> 
> This patch series only adds the tool, it doesn't touch the maps in
> pc-bios/keymaps/ yet.  I want some testing feedback first ...

Hmm, we recently split out the keymap database and code for generating
lookup tables (that was duplicated across spice-gtk, gtk-vnc, and libvirt)
into a shared git sub-module

  https://gitlab.com/keycodemap/keycodemapdb/

some other VNC clients were also switching to its use.

I was coincidentally working on a patch to get QEMU to use this too,
so all projects are aligned on the same data maps and thus share fixes
in this area.

IMHO that'd be preferable than doing something custom in QEMU only.

> How to test:
>   (1) generate a map: "qemu-keymap -f testmap -l $layout"
>   (2) use the map: "qemu -vnc $display -k testmap"
> 
> Gerd Hoffmann (3):
>   keysym: add next and prior
>   ui: move qemu_input_linux_to_qcode()
>   Add qemu-keymap tool.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Mon, Jul 24, 2017 at 03:18:25PM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 24, 2017 at 04:01:14PM +0200, Gerd Hoffmann wrote:
> > qemu carries a bunch of reverse keymaps in pc-bios/keymaps/, to map
> > keysyms it receives from vnc clients back to keycodes.  These keymaps
> > seem to be buggy and incomplete at times.  So, to tackle the issue once
> > for all, I've written a tool to generate those maps from xkb keyboard
> > layout data using libxkbcommon.
> > 
> > This patch series only adds the tool, it doesn't touch the maps in
> > pc-bios/keymaps/ yet.  I want some testing feedback first ...
> 
> Hmm, we recently split out the keymap database and code for generating
> lookup tables (that was duplicated across spice-gtk, gtk-vnc, and libvirt)
> into a shared git sub-module
> 
>   https://gitlab.com/keycodemap/keycodemapdb/
> 
> some other VNC clients were also switching to its use.
> 
> I was coincidentally working on a patch to get QEMU to use this too,
> so all projects are aligned on the same data maps and thus share fixes
> in this area.
> 
> IMHO that'd be preferable than doing something custom in QEMU only.

Oh actually ignore that - we're talking about different areas of
keymapping. The stuff I was doing was primarily targetted as the
SDL / GTK frontends in QEMU which must convert from X/GTK key
maps to QEMU's XT keycodes, where as you were talking about the
VNC keymaps when not using the QEMU scancode extension for VNC.
So they're complementary, not mutually exclusive.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On Mon, 2017-07-24 at 15:18 +0100, Daniel P. Berrange wrote:
> On Mon, Jul 24, 2017 at 04:01:14PM +0200, Gerd Hoffmann wrote:
> > qemu carries a bunch of reverse keymaps in pc-bios/keymaps/, to map
> > keysyms it receives from vnc clients back to keycodes.  These
> > keymaps
> > seem to be buggy and incomplete at times.  So, to tackle the issue
> > once
> > for all, I've written a tool to generate those maps from xkb
> > keyboard
> > layout data using libxkbcommon.
> > 
> > This patch series only adds the tool, it doesn't touch the maps in
> > pc-bios/keymaps/ yet.  I want some testing feedback first ...
> 
> Hmm, we recently split out the keymap database and code for
> generating
> lookup tables (that was duplicated across spice-gtk, gtk-vnc, and
> libvirt)
> into a shared git sub-module
> 
>   https://gitlab.com/keycodemap/keycodemapdb/
> 
> some other VNC clients were also switching to its use.
> 
> I was coincidentally working on a patch to get QEMU to use this too,
> so all projects are aligned on the same data maps and thus share
> fixes
> in this area.
> 
> IMHO that'd be preferable than doing something custom in QEMU only.

This is a different issue.  gtk-vnc & friends have to map keycodes from
one system (ps/2, evdev, xorg, ...) to another.  qemu has to map
keysyms back to keycodes, using a reverse keymap, in case the vnc
client doesn't support VNC_ENCODING_EXT_KEY_EVENT.

cheers,
  Gerd