weston and graphics tablet support?

[Peter Hutterer]

On Fri, Oct 28, 2016 at 12:32:00PM +0200, Armin Krezović wrote:
> Hi
> 
> On 28.10.2016 07:22, 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].
> > 
> 
> What infrastructure is toytoolkit missing?

proper events. right now, the events come from the compositor, are maybe
handled a little bit and passed straight into the client. but it's still
essentially a straight wayland-event to function pointer mapping. for tablet
events, the only sensible thing would be to accumulate them in the tool kit,
then pass them on as opaque event objects to the clients. otherwise, you'll
have handlers for pressure, tilt, distance, axis, etc. in every client and
they all have their own way of accumulating them until the frame event
arrives.

> What other compositor features besides the mode switching are missing?

Automatic and semantic mapping of the tablets to the right monitor. requires
libwacom to check if it's built-in and some heuristics to get the output
correct. e.g. Cintiqs are built into a monitor, but laptop-integrated need
to map to the built-in screen.

Ratio mapping for external tablets - a 16:10 tablet mapped onto 4:3 monitor
needs to have its area adjusted so that the input data isn't skewed. This
has a couple of other implementation questions - do you just clip
coordinates or do you fake a proximity out in the compositor when you leave
the active area?

Relative vs absolute mode switching - somewhere we need the decision which
input data to use and how to switch it on the fly. Admittedly, we probably
get by just leaving the mouse in relative mode and everything else in
absolute.

Once you want to actually use your pen in a serious manner, you need to
handle pressure curves as well. Could be done in the compositor or the
toolkit, jury's still out on that. But the pressure curve essentially means
that you can configure a physical:virtual pressure mapping to make the
tool behave like a pencil or a brush, etc.

> There's support for mode switching in libweston itself, such as
> weston_output_mode_switch_to_temporary and weston_output_mode_switch_to_native
> 
> What's wrong with them? Do they need some enhancements (I understand that not
> all backends support this - but I can implement it for X11 backend, and we
> can fake it for the headless one)? 

it's a different type of mode switch. forget about output stuff here, mode
switching for tablets means that one tablet button toggles through (or
directly selects) a mode. That mode then applies to the touch ring/strip and
optionally the buttons. So in mode 0, your ring may be a scroll wheel, in
mode 1 it zooms, in mode 2 it pans and in mode 3 it rotates. Button 1 may be
a left mouse button in mode 0, select the eraser tool in mode 1, etc.

This is all stuff that's way beyond something called "toytoolkit" :)

Cheers,
   Peter

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