partially merging wip/wayland-tablet ?
- Date: Tue, 07 Jul 2015 15:26:29 +0200
- From: Carlos Garnacho <carlosg@xxxxxxxxx>
- Subject: partially merging wip/wayland-tablet ?
I'd like to raise some attention on wip/wayland-tablet, especially the
API changes it involves, and the possible behavioral changes that could
wl_tablet itself is not there yet, the last drafts are really solid,
but currently relies on non-master branches all along the stack.
Because I expect little to no changes, I feel it's safe to start
proposing the extra API around, along with the X11 support.
All API changes are held so far in the first commits, until:
58310d2 GdkDeviceTool: Add GdkAxisFlags info to tablet tools
Some notes about the API:
* The most notable addition is GdkDeviceTool, these are related to
GDK_SOURCE_PEN/ERASER devices, and are created by GDK as new tools are
used. GdkDeviceTool basically represents different physical pens, and
work as a long-lived reference to it, the pointer can be used for
comparisons as long as the device lives, and there's a getter for the
serial ID, which may complement gdk_device_get_vendor/product_id() at
the time of creating gsettings keys and whatnot.
There can be multiple tools per GDK_SOURCE_PEN device, the
GDK_SOURCE_ERASER device will only get the corresponding eraser tool.
If this were to be done from scratch, I would go for a
GDK_SOURCE_TABLET device (representing the tablet itself) with all
tools (representing pens) depending on it. This is perhaps the one
oddity as there's no other backward compatible way.
* IMO It's time to admit that the GdkAtom-based axis getters API is
kind of a failure and should be deprecated... it will require ad-hoc
hacks in wayland (still in the todo), and the whole "hunt for driver
specific strings" doesn't make it a too friendly API.
Luckily, the GdkAxisUse based API wasn't deprecated, the enum is even
expanded in the branch, adding a GDK_AXIS_DISTANCE, which we can honor
at least on Wayland.
* The branch also adds GdkAxisFlags (basically GdkAxisUse turned into
flags), and gdk_device_get_axes(), these come out useful since on
wayland the current tool determines the axes. This is a more direct
mapping of the hw behavior, which the X11 driver tapped by just
exposing all possible axes on all tools.
This means that on Wayland slave devices' axes switch on the fly,
similarly to how the master device changes axes on slave switch.
And some thoughts on the final merge:
The one "major" behavioral change between wayland and X11 here is that
wayland tablets get their own pointer onscreen, so the mouse pointer
stays unaffected. On GTK+3/X11, by default everything goes through the
Virtual Core Pointer.
When mapping this into GDK terms, there's 2 most obvious choices:
- Creating a master device per tablet: This allows for setting per
-tablet cursors, as wl_tablet allows, but it might require a bit of
porting effort (esp. around simultaneous interaction scenarios,
checking master devices, maybe setting per-device grabs). GTK+ itself
is ready for that, so it would be ugly at worst, but not broken.
- Creating tablets as detached slaves: This would be actually very
similar to the GTK+2 days. Slaves don't have a cursor, so these
shouldn't be honored, and users would need to
gdk_window_set_device_events() manually for these in order to receive
events at all. Overall a bit of a step back IMO.
The branch goes for the first option, the scenario is hard enough to
trigger, and apps slowly coming from the gtk+2 days should already have
similar checks around to cater for pointer+extension devices. So this
strikes me as least painful and most consistent with our GTK+3 story.
The branch also cheats a bit, and sets the master keyboard as the
paired keyboard for all per-tablet master pointers, just so events have
meaningful modifiers. This is somewhat inconsistent wrt
gdk_device_get_associated_device() on master devices (each of these
supposedly pointing to the other, this will no longer be true for
tablet devices). I doubt this will bring in any real problems, it is
worth pointing out though.
And that's it for now I think... opinions?
gtk-devel-list mailing list