GTK hardware scancodes for wayland / detecting XWayland

[Daniel P. Berrange]

On Thu, Jan 22, 2015 at 01:30:26PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 22 January 2015 at 08:40, Daniel P. Berrange <berrange at redhat.com> wrote:
> > On Wed, Jan 21, 2015 at 04:32:46PM -0800, Jasper St. Pierre wrote:
> >> On Wed, Jan 21, 2015 at 7:03 AM, Daniel P. Berrange <berrange at redhat.com>
> >> wrote:
> >> > First I wanted to confirm what will be reported in hardware_keycode
> >> > for both Wayland native and XWayland ? In my limited testing it
> >> > appears that in both cases GTK is getting evdev scancodes with the
> >> > same offset-by-8 applied as Xorg+evdev uses. Is this correct and is
> >> > that guaranteed to stay with this mapping long term ?
> >
> >> Yep, this is correct. To be more specific, Wayland uses evdev keycodes
> >> directly, and GDK adds the 8 to make them match the X11 scancodes as used
> >> in the XKB maps.
> >>
> >> https://git.gnome.org/browse/gtk+/tree/gdk/wayland/gdkdevice-wayland.c#n1304
> >
> > Perfect, thanks for confirming.
> 
> It's probably 'correct' for your intents and purposes. It is
> absolutely, 100%, not technically correct.
> 
> Scancodes are defined to have no meaning beyond what the keymap
> assigns to them. In particular, what happens if you have a Wayland
> session which is itself nested rather than a base system compositor?
> 
> You can try to infer meaning from scancodes aside from the keymap and
> it'll probably work, but this was explicitly not guaranteed under X11,
> and it's certainly not under Wayland either.
> 
> >> > We have some existing code that uses the XkbGetKeyboard() call
> >> > to query the keymap name[1], but this does not return any data when
> >> > run under Xwayland.
> >>
> >> Hm, that's strange. We do set up an XKB keymap using the internal Xorg
> >> APIs. We should fix it so that XkbGetKeyboard(); works properly in
> >> Xwayland. I'm quite sure the XKB map we send across has the KcCGST, so we
> >> should be able to fill it in.
> >>
> >> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xwayland/xwayland-input.c#n346
> 
> This is also a hack. Especially under X11 if you rely on xmodmap
> working, the returned keymap from XkbGetKeyboardByName might not bear
> any resemblance to the name of the keymap which was loaded. (Not a
> problem we have under Wayland, mind, but still.)
> 
> Long story short, you're hacking around the entire keymap
> infrastructure and relying on guarantees which are absolutely not
> guaranteed. It works for the majority of cases, but if (when) it
> breaks, I really don't have a good answer to that.

So originally VNC clients would just pass the keysyms across to the
wire to the remote VNC server which gave them straight to the display
server without needing any remapping/translation anywhere in the
VNC client or VNC server

The problems arise when we add virtualization into the mix. When the
VNC server is QEMU, it can't give the keysyms straight to the display
server. It has to inject them into the virtual machine's emulated
keyboard, which only accepts scancodes.

In the original QEMU VNC server, QEMU would accept the keysym from
the client and try to convert that back into a scancode. To do this,
it needed to know the keymap, so you had to launch QEMU server with
a manual keymap arg that matched both your client keymap and the guest
OS display server keymap. Even when you did that, the conversion QEMU
did was lossy so it would be impossible to use certain key sequences
in virtual machines.

So QEMU defined a VNC extension, where it accepts scancodes from the
client, instead of keysyms. Now QEMU doesn't have to do any translation
itself, it can just inject the scancodes it gets from the client straight
into the guest emulated keyboard. So now you "merely" need to make sure
your client display server and guest OS display server have the same
keymap, which is a big improvement on what we had before from the user's
POV.

NB, this raw scancode extension is only used when talking to a QEMU based
VNC server - when talking regular VNC servers GTK-VNC still passes the
keysyms directly.

Of course this still leaves us with the problem that the VNC client needs
to get scancodes from the display sever it runs under. This is still a
sucky problem, but it is better to use the hardware_scancode value
directly, than to try to reverse engineer it from the keysym in QEMU.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|