wl_tablet specification draft

[Peter Hutterer]

On 30/06/2014 16:33 , Pekka Paalanen wrote:
> On Mon, 30 Jun 2014 11:08:35 +1000
> Peter Hutterer <peter.hutterer at who-t.net> wrote:
>
>> On Sat, Jun 28, 2014 at 12:41:33PM +0300, Pekka Paalanen wrote:
>>> On Fri, 27 Jun 2014 13:04:59 -0700
>>> Bill Spitzak <spitzak at gmail.com> wrote:

[...]

>>>>
>>>> - The pen moves the seat's mouse cursor, always. If more than one cursor
>>>> is wanted the pen should be in a different seat. The user is not
>>>> manipulating more than one device at a time and does not want to see two
>>>> cursors.
>>>
>>> ...and then you said the exact opposite, plus you require the
>>> broken case where the same hardware events map to multiple
>>> completely different protocols (wl_pointer *and* tablet).
>>
>> that's not necessarily the worst thing, provided it doesn't happen at the
>> same time. with a "mode toggle" button the compositor could switch between
>> tablet events and absolute motion on-the-fly.
>
> That I completely agree with, but Bill did write "The pen moves the
> seat's mouse cursor, always." Always - implies that you sometimes get
> pointer and tablet events for the same action.
>
>> This is a change how tablets currently work in Linux but aside from that
>> it's actually the easiest and cleanest to implement.
>
> It sounds like it would work: just use wl_pointer protocol when the
> tablet controls the pointer, and tablet protocol when it is used as
> a... tablet, and let the compositor switch between the two modes. Still,
> never the both at the same time for same physical user action, right?
>
> That way the tablet protocol could be exclusively for the "whole tablet
> maps to the client/window/app-custom region", and you can ignore the
> "tablet maps to whole/all outputs" case as that would be handled by the
> wl_pointer mode alone. How would that sound?

doable, but I'm equally worried about how this may not actually be 
useful :) having the tablet map to a single output by default is 
sensible but having to switch between the modes is tricky at best. What 
if you want to click a button outside the current client? do you have to 
switch mode? or does the compositor automatically switch to wl_pointer 
based on the client? These are the questions I'm not sure yet how to 
answer. Having the compositor automatically switch mode if the client 
requests the tablet manager interface and use wl_pointer otherwise is 
doable but awfully close to the pointer emulation we're trying to avoid.

>>> Moving seat's "mouse cursor" means the tablet/pen controls the
>>> wl_pointer and sends wl_pointer events. I don't see any way around
>>> that.
>>
>> moving the visible cursor doesn't necessarily mean that it must translate
>> into the wl_pointer protocol. It's probably awkward at first if the pointer
>> moves and clients don't react to it but if we essentially require the
>> toolkits to support wl_tablet then this will go away quickly.
>
> I suspect it will be very hairy to make that work. Clients always set
> the pointer cursor image when the pointer enters a surface. If you move
> the cursor without using wl_pointer protocol, what happens with the
> cursor image?
>
> Also, you would have wl_pointer.enter and wl_tablet.pointer_enter or
> something which would both mean the pointer cursor is entering, but
> controlled by a different device. It just feels... not right, no?

yeah, sorry. I forgot that in wayland a lot more things are 
client-controlled than in X.

There's one more idea floating around but it's still just an idea: 
extend wl_pointer to wrap the current enter/leave events with additional 
tablet-specific ones. so instead of the current enter/motion/leave 
sequence you'd get proximity-in/enter/motion/leave/prox-out, with the 
prox-in event containing a tablet identifier. That would automatically 
allow the tablet to be used as pointer anywhere, and based on the 
version you just won't get the extra events. Still, it throws up a whole 
bunch of other issues that I'm not happy with, so I suspect this idea 
may be DOA.

Cheers,
   Peter