Re: wayland tablet support redux

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

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
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)
wayland is that in the former all plugged in devices drive the
Core Pointer, whereas in wayland each tool in proximity (1 per
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
:). 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
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
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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]