Re: wayland tablet support redux

[Peter Hutterer <peter hutterer who-t net>]

On Wed, Mar 30, 2016 at 04:46:43PM +0200, Carlos Garnacho wrote:
> Hey all,
>
> Now that 3.22 is open, and that the v1 of the wayland tablet protocol
> is formalized, I'll be attempting to merge wip/wayland-tablet again.
> Some random concepts:
>
> =What's new in the branch=
> The main new API feature is GdkDeviceTool, it (almost, more on this
> ahead) univocally represents physical tablet tool (usually a pen),
> these structs contain a GdkDeviceToolType saying the kind of tool it
> is (pen, eraser, airbrush,...) and their serial number if available.
>
> The idea behind this struct is that interested apps can do per-tool
> tracking/configuration/etc, using a same tool will always result in
> the same GdkDeviceTool pointer reported in events, etc. And the serial
> number can be used to compose GSettings paths and whatnot.
>
> The branch also resuscitates proximity events, they are a thing again,
> and I added some kind of support for these for X11/XI2.
>
> There's though low-range tablets that don't report serials (and most
> usually, you can't use further/different tools than the one coming
> with the device), in wayland it's the compositor which takes care of
> creating the separate tool interfaces for those, in x11 we create
> extra GdkDeviceTools with serial=0, which are shared for all devices
> for all devices with these characteristics.
>
> =...but we had already an eraser device?=
> Yes, and in the branch we still do, all events from the eraser tool
> will be sent with a GDK_SOURCE_ERASER device, and all other tools will
> be always sent with a GDK_SOURCE_PEN device. That's kind of
> unfortunate and something that'd be great to switch on 4.0.

can you explain what exactly you mean here? IMO the various device types are
a high-level approximation at best anyway and while we have it in libinput
and the protocol, I'm not sure things like PENCIL/etc. need to be exported.
if you can't use something like libwacom, you're pretty much lost anyway for
the device type (short of pen, mouse, eraser).

> Another option could have been going the other way around, and adding
> extra GdkInputSources and devices. I don't think that option scales as
> well.
>
> =Relationship between tablets and tools=
> The typical noncontroversial setups are those with one tablet+one
> tool, or multiple tablets each with their own tool. Things complicate
> soon though when you add multiple tools and multiple compatible
> tablets, tools can then be used interchangeably across tablets.
>
> This is one thing that IMO the wayland protocol got right, both
> tablets and tools are announced by the seat, it is tools which do
> "emit" the events, have axes, etc. And you can only relate a tool to a
> tablet on proximity_in.
>
> And this is something we kind of do too in gdk. In the end you
> shouldn't expect that a given GdkDeviceTool will always be accompanied
> with the same GdkDevice in events. The difference here is that in gdk
> it is GdkDevices which have axes, "emit" events, etc. In order to keep
> doing this, slave pen/eraser devices do change their axes in order to
> resemble the tool in proximity_in, just like master devices currently
> do in x11 on slave device switch. The end message is the same,
> event->xxx.axes is only guaranteed to map correctly to the current
> device axes at the time of dispatching the event.
>
> This also affects the lifetime of objects, unplugging a tablet will
> tear down the associated GdkDevices, but GdkDeviceTools may stay
> indefinitely longer.

I think it's also important to point out that in libinput (and thus by
inflection the X11 driver and the compositor) create the tools on the first
proximity in. This is a departure from the previous approach where the base
set of tools, sufficient for 99% of the use-cases, were available as soon as
the tablet was plugged in. This is not the case anymore, clients cannot
rely on this anymore. I haven't looked yet how you solved this, but I
suspect it's done in the straightforward manner (tool shows up, tool is no
available in GTK :)

Cheers,
   Peter

> =Tablets and pointer cursors=
> One fundamental difference between X11 (with default XI2 behavior) and
> wayland is that in the former all plugged in devices drive the Virtual
> Core Pointer, whereas in wayland each tool in proximity (1 per tablet,
> effectively) will get their own.
>
> This leads to differences in how are those are tablets mapped to
> GdkDevices, which I expect GdkSeat to help even out. in wayland we'll
> create a separate "master pointer" device for each tablet, its cursor
> can be set independently, etc. GTK+ has been prepared for the most
> part to deal with multiple pointers since 3.0, and it finally pays off
> :). The difference is that these several pointers come from the same
> seat, so they should all be able to interact with popup menus, etc.
> This is one place where GdkSeat grabs came to help, those will perform
> the input redirection for all devices in the seat, with the practical
> result that all of pointer/touch/tablets will be able to select
> something in the popup, dismiss the menu, etc... just as it happens
> when all slave devices drive the same master pointer.
>
> There is however a potential porting effort here for some applications
> or widgets outside gtk+. If you need to keep track of motion events,
> query device positions, etc. You better track gdk_event_get_device()
> too, any app that was cheaply ported to 3.x using
> gdk_device_manager_get_client_pointer() thinking "the pointer" is
> sufficient and single enough will potentially get things wrong, but
> then again, it's been potentially broken since 3.0. This is something
> that GtkGesture is already prepared for FWIW.
>
> Cheers,
>   Carlos