weston and graphics tablet support?

[Peter Hutterer]

On Mon, Oct 31, 2016 at 08:34:07PM +0100, Armin Krezović wrote:
> On 30.10.2016 23:59, Peter Hutterer wrote:
> > 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.
> > 
> 
> Can't this be done in the compositor?

nope, because this is a wayland protocol thing. libinput already gives you
one struct and you can get all the information off it. for the protocol it
has to be serialised though. and since the other end of the protocol is the
client, you can't de-serialise it in the compositor :)

Cheers,
   Peter

> >> 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
> 
> I agree with what Daniel has said. It would be nice to have a reference implementation,
> at least on the server side. And now that there's libweston, it can be utilized by
> others, too.
> 
> Thanks, Armin.
>