Web lists-archives.com

Re: wayland tablet support redux




Hey Bastien!,

On Fri, Apr 1, 2016 at 10:41 AM, Bastien Nocera <hadess@xxxxxxxxxx> 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.
>
> 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?

Hmm, need we? AFAIK apps like gimp/inkscape haven't abandoned their
per-device pressure curves, etc.

As things currently go, libinput won't offer as many configuration
toggles. Some should be provided by the compositor itself (eg. abs vs
rel motion), some will be pushed down to hwdb (eg. thresholds to get
tip down/up events), and some are better handled in the app (eg.
pressure curves).

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

The tool ID is indeed useful if you want to match devices/tools
against libwacom in the app side. This kinda vendor dependent though,
we have a wp_tablet_tool.hardware_id_wacom event which I'm not sure
how to make visible in gdk api, a GdkDeviceTool:wacom-id property
opens the door for icky checks if we add more vendor-specific
properties, and a generic GdkDeviceTool:vendor-id property might come
out ambiguous.

>
>> =...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.
>>
>> 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.
>
> Do we receive information about which tool this eraser is attached to?

Not immediately. The GdkDevices created are per tablet, on each tablet
detected we add 1) slave pen+eraser devices and 2) a master pointer
driving those. It's only in proximity_in when we can match a tool and
the master/slave pair it will emit events from. I'm still thinking how
would proper GdkSeat API look to query tablet devices though, matching
GDK_SOURCE_PEN devices with their corresponding GDK_SOURCE_ERASER
device has always been kinda flaky (well, we've got vendor/product ids
now, but it's still kinda mix and match).

>
> The API for the eraser should match what is done for the tools above.
>
>> =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.
>
> How will you know that a GdkDeviceTool that you instantiated for tablet
> #1 is usable for tablet #2?

You don't till you receive a proximity_in with that tool and tablet.
Probably also worth pointing out that this makes lifetime of tools in
the compositor somewhat nebulous.

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

As peter says, that happens well beneath the app/toolkit. If devices
are able to handle simultaneous input without precision/rate loss, I
see the wayland input model being able to forward this arbitration
further, although I think some filtering must happen somewhere, you
probably don't want the side/palm of your hand to count as "touch"
when you're holding the pen.

Cheers,
  Carlos
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
https://mail.gnome.org/mailman/listinfo/gtk-devel-list