GTK hardware scancodes for wayland / detecting XWayland
Jasper St. Pierre
jstpierre at mecheye.net
Wed Jan 21 16:32:46 PST 2015
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.
> 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
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 there are any suggestions that'd be great, otherwise I'll go
> the somewhat sucky approach of seeing if the WAYLAND_DISPLAY env
> variable exists and infer that we're using Xwayland based on
> "GDK_IS_X11_DISPLAY && getenv(WAYLAND_DISPLAY) != NULL"
>
> Regards,
> Daniel
>
> [1] https://git.gnome.org/browse/gtk-vnc/tree/src/vncdisplaykeymap.c#n150
> --
> |: 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
> :|
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
--
Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150121/384a7ffd/attachment.html>
More information about the wayland-devel
mailing list