Re: qemu-system-x86_64: warning: Unknown X11 keycode mapping '<null>'.

[Daniel P . Berrangé]

On Mon, Mar 02, 2020 at 01:43:12PM +0100, Thorsten Glaser wrote:
> On Mon, 2 Mar 2020, Daniel P. Berrangé wrote:
> 
> > "x11vnc" suggests you had a regular X11 desktop session, and are
> > exporting it via VNC ?
> 
> No, x11vnc is a standalone VNC server.
> 
> > Can you tell me a bit more detail about how you launch this all.
> 
> Sure:
> 
> $ vncserver -geometry 1000x768 -name nowm :2
> $ (export DISPLAY=:2; exec </dev/null >>.xsession-errors; exec 2>&1; 
> icewm-session &)
> 
> (I could run icewm-session from ~/.vnc/xstartup but this way it
> inherits some more desirable environment variables.)
> 
> My ~/.vnc/xstartup looks like:
> 
>       #!/bin/sh
> 
>       xrdb $HOME/.Xresources
>       xsetroot -solid grey
>       uxterm &
> 
> > ...this suggests your running a VNC server, with embedded X11 server
> 
> Yes, indeed.
> 
> > >   - xprop -root
> > 
> > ...there's no _XKB_RULES_NAMES(STRING) property listed, which is the key
> > thing we'd expect to see for a modern X server. eg
> > 
> >   _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""
> > 
> > is what most X servers on Linux will report.

Or 'kbd' instead of 'evdev' is fine too

> 
> This is not a good assumption to make. For example, I’m also using
> xmodmap instead of xkb for my keyboard layout under the main X.org
> desktop. (It does carry the xkb information because Debian starts
> it that way, but I replace it with xmodmap right in .xsessioinrc.)

That shouldn't be a problem, as its a different level in the stack

There's two translations happening

 * The scancode emitted by the kernel and/or hardware device,
   and then translated/mangled by X11 and reported as the
   hardware keycode

 * The keysym which is the mapping from the hardware keycode
   done by XKB and/or Xmodmap

The 2nd point here doesn't matter for QEMU.

We're dealing with the first point in QEMU, taking the hardware
keycode and trying to undo the X11 mangling that was performed.
This mangling is different depending on whether the X11 server
is using 'evdev' or 'kbd' as its input driver.

So the key thing to understand is what values your X11 server
is using for the hardware keycodes.


> > Can you also say what QEMU version ?
> 
> qemu-system-x86 1:4.2-3
> 
> > So either your QEMU is fairly old, or you are using a keycode mapping
> > that QEMU has no understanding of (we support evdev, or the classic
> > xfree86 'kbd' mapping).
> 
> The latter is the Xmodmap one? If so, then okay.
> 
> > It would be highly unusual not to use one of
> > those two, but none the less, that appears to be the case here ?
> 
> I must admit not knowing all that much about the VNC servers.
> I used to use tightvnc, but that had issues with… somewhat I
> don’t remember, so I now use tightvnc’s client but X11vnc as
> standalone server. There’s also tigervnc, but that works even
> worse for me.

Ok, that's useful info to know.

> But if I can do anything to help debugging this, sure.

Can you launch 'xev' inside your VNC session and press the 'Page Up'
button and let me know what it reports the keycode and keysym.

Specifically I'm interested in this line of text:

    state 0x0, keycode 112 (keysym 0xff55, Prior), same_screen YES,

On evdev it reports 112 as hardware code which is 0x70 hex, while with
'kbd' it reports 99 which is 0x63 hex. These are the only two scenarios
QEMU knows how to cope with.

I'm strongly suspecting your X11 server will report something different
from either evdev or kbd driver hardware codes.

For that matter, if you have time to help, it would be interesting to
see what it reports for a random selection of other keys too. For
example:

  @
  #
  $
  `
  -
  +
  1
  2
  3
  a
  s
  d
  q
  w
  e
  ,
  .
  /


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