weston and graphics tablet support?

[Armin Krezović]

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?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 837 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161031/362dc79e/attachment.sig>