GTK hardware scancodes for wayland / detecting XWayland

Daniel P. Berrange berrange at redhat.com
Thu Jan 22 00:40:22 PST 2015


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:
> 
> > I'm trying to port GTK-VNC to work correctly under Wayland, both as
> > a native client and as an Xwayland client. The only place we have
> > any code that is specific to particular display servers is the keyboard
> > handling. We can't use the GdkEventKey keyval directly because that
> > results in having todo lossy keymap conversions in QEMU, so we need to
> > translate the key event to get the values in terms of XT scancodes
> > that we can send straight to QEMU. This involves a lossless translation
> > of the values that GTK reports in the hardware_keycode field of
> > GdkEventKey.
> >
> > Sadly there is no standard for what scancode values are reported in
> > the hardware_keycode field, so we need to add a custom remapping for
> > each display server.
> >
> > In traditional Xorg, the hardware_keycode is either reporting custom
> > set of scancodes defined by xfree86 X11 keyboard driver, or with modern
> > deployments using the Linux evdev scancodes with a simple offset-by-8
> > applied.
> >
> 
> Do we see any widespread deployment with the xf86-input-keyboard driver? I
> think you can rely on seeing evdev + 8 codes everywhere.

It's only seen on old systems - think RHEL-5 vintage.

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

> Detecting that we're a native Wayland client is easily done using
> > GDK_IS_WAYLAND_DISPLAY(), but I'm less sure on the best way to
> > detect that we're under XWayland. In fact ideally we'd not need
> > to detect Xwayland, but rather directly query the keymap used.
> >
> > 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
> 
> The ServerVendor simply returns "Fedora"
> > and not "XWayland", so that's out as a detection mechanism, and
> > there's no obvious wayland specific extension loaded that I can
> > use as a detection mechanism. I'm out of ideas of what aspect
> > of the connected display I can use to detect presence of Xwayland.
> >
> 
> After we fix the XkbGetKeyboard(); bug, would you need to detect Xwayland?

If XkbGetKeyboard were to work, that'd be just fine with me :-)

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


More information about the wayland-devel mailing list