Re: wayland tablet support redux

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

On Fri, Apr 01, 2016 at 10:41:21AM +0200, Bastien Nocera wrote:
> On Wed, 2016-03-30 at 16:46 +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.
>
> If you use the serial to construct the settings path, that means you
> can't replace your broken airbrush pen with another airbush pen because
> it would have separate settings. That's not likely what you want to
> do. 

I disagree. When a user buys a new device, the requirement to re-configure
is not unreasonable. And if you don't use the serial, you can't use multiple
tools of the same type with different configuration. That is a common setup
afaik, maybe not with airbrushes but with normal pens.

> This also doesn't give you information about the tool type (airbrush,
> inking pen, grip pen, etc.).
>
> It is however useful for applications to directly monitor the pen in
> use, which takes away gnome-settings-daemon from the loop to monitor
> and switch tool configuration on proximity changes.
>
> How would you export the configuration from the Wacom panel to the
> applications though?
>
> > 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.
>
> I still don't think that the serial is interesting, compared to the
> tool ID.

[...]

> > =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.
>
> Will the touch filtering for, for example, the Cintiq with Touch, be
> done in the underlying layers, or will that information be passed on to
> the application layer?

FTR, we have pen/touch arbitration in the kernel already for most devices,
but I'm happy to put this into libinput where needed.

Cheers,
   Peter