weston and graphics tablet support?

Jason Gerecke killertofu at gmail.com
Mon Oct 31 23:28:19 UTC 2016

On 10/27/2016 10:22 PM, Peter Hutterer wrote:
> Time to discuss graphics tablet support in weston: I had a patchset for some
> earlier version of the tablet protocol, since then we've added a few bits
> and bobs, including the mode switching support.
> Short story behind this email is: I seriously question the point of having a
> tablet implementation in weston. I know it's supposed to be the test bed for
> protocols (fwiw, we already have mutter + GTK support for tablets). But in
> order to test this particular protocol, a lot of supporting infrastructure
> has to be there that libtoytoolkit doesn't have. In addition, there are a
> couple of things to be added to the compositor support, especially for mode
> switching, that I question the value of having this in weston at all [1].
> Some or most of this work will likely end up being an unused (and thus
> untested) code path, the compositors that care about a niche feature like
> graphics tablet support are unlikely to be the ones that use libweston.
> So right now, I'm tending to *not* implementing tablet support for weston.
> Any opinions? Yay? Nay? Banana!?
> Cheers,
>    Peter
> [1] yes, you can attribute some of all this to laziness

I'm sure you can guess that I'm in favor of adding support to Weston and
libtoytoolkit, but hopefully I can provide some sound reasons to back up
that opinion.

While pen input may not be as ubiquitous as the mouse/touchpad or
keyboard, it isn't exactly uncommon either. The tablet PC user expects
to be able to use their pen anywhere they could use a mouse: opening
applications, moving/resizing/closing windows, interacting with dialog
boxes and application UI, etc. The pen is just as capable of clicking
and dragging as a mouse or finger and is used for those purposes almost
as much as for drawing/writing.

libtoytoolkit use is niche enough that that perhaps it is acceptable to
say that clicking/dragging and other basic UI interactions should be
effectively "broken" in the name of simplicity. On the other hand, it
would be nice if the toolkit was responsive to at least a minimal
degree. I do so much hate having to dig in my drawer for a mouse just
because an application doesn't recognize my pen or puck.

As for Weston, I have a much harder time accepting that it should go
without support. Doing so effectively says that Weston is not suitable
for use by artists with applications like GIMP and Krita. Certainly the
reference compositor is free to ignore applications and use-cases that
it finds irrelevant, but (as I already mentioned), artists and pens
aren't exactly uncommon.

Further, leaving support out of Weston just leaves the barrier that much
higher for developers of other compositors. Developers aren't going to
implement from-scratch support for hardware they don't have, and aren't
going to be able to justify the expense of buying a tablet when there
are more important bugs/features impacting their userbase. Having
reference code available is useful and doubly-so to have a working
implementation included in the library you're building on (libweston).
Tablets currently see use in environments where "niche" compositors
(e.g. nested remote desktop or single-application workstations) would
likely see use.

I also believe that getting support into (lib)Weston would ensure
improved quality compared to the alternative since the code would be
used by multiple small compositors who would have a reasonably diverse
combined userbase. Sure it won't be as large as e.g. Mutter, but it
should be sufficient and certainly better than the number of users
individual implementations would have.

Finally, I should note that adding support for tablets doesn't mean that
the support has to be 100% feature-complete. Leaving out support for
those parts of the protocol which are more complex and less used (e.g.
mode switching; maybe even pads TBH) may be reasonable.

Now instead of four in the eights place /
you’ve got three, ‘Cause you added one /
(That is to say, eight) to the two, /
But you can’t take seven from three, /
So you look at the sixty-fours....

More information about the wayland-devel mailing list