GTK hardware scancodes for wayland / detecting XWayland

[Daniel Stone]

Hi,

On 22 January 2015 at 13:46, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Thu, Jan 22, 2015 at 01:30:26PM +0000, Daniel Stone wrote:
>> 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.

Yeah, I'm pretty familiar with the problem. There's also the issue of
needing to pass scancodes to other OSes which have their own hardcoded
keymaps and different symbol interpretations.

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

Aye, it makes total sense, but does make for a huge impedance mismatch.

evdev + 8 is about the safest assumption you can make, but it is an
assumption that can well break, and if it does then I don't think
there's really a good way around it. I'm half-tempted to mandate for a
future version of wl_keyboard that all scancodes are evdev + 8 and
anything else can go hang.

Cheers,
Daniel