GTK hardware scancodes for wayland / detecting XWayland

[Daniel Stone]

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.

A more sophisticated answer would be to derive the meaning of the keys
from the keymap itself. But this is also pretty fraught with danger.

Cheers,
Daniel