[PATCH wayland-protocols] Add the tablet protocol

[Peter Hutterer]

On Mon, Nov 09, 2015 at 02:33:39PM -0800, Jason Gerecke wrote:
> On Fri, Nov 6, 2015 at 4:11 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> > Having read this more carefully, the cursor scheme absolutely will not work.
> >
> > The main problem is that the client may want to choose a cursor for a tool
> > based on the location at which it came into proximity. It cannot set this
> > cursor until after it gets the proximity event. If this desired cursor is
> > different than the one the tool currently has set then that incorrect cursor
> > will be seen, at least briefly.
> >
> I'm afraid I don't understand what meaningful difference there is
> between the scheme here and wl_pointer. As you point out, there is a
> brief window of time when the incorrect cursor can be seen with _both_
> protocols. Its a simple result of the fact that a client _can't_ know
> that it needs to change the cursor until _after_ it receives some kind
> of focus event ('enter' or 'proximity_in'). I suppose the client could
> provide a reference to the surface over which a particular
> 'set_cursor' should take effect (and then have the compositor keep
> track of all those references) but I'm sure that has its own issues.
> 
> > A further problem is that there has to be an easy transition between clients
> > that don't use the tablet api and those that do. Operation of gui widgets
> > that work equally well with mouse or tablet should not change just because
> > the client has decided to enable the tablet interface. The primary problem
> > is that the pointer position must move to the last tablet tool positiion
> > whether or not the client is using the tablet interface. This then means
> > there cannot be more than one cursor (since they would be right atop each
> > other).
> >
> While I absolutely agree that GUI widgets should work equally well
> with a tablet as a pointer, the "primary problem" is not that the
> pointer has to be moved; widgets can work just fine if they're aware
> of the tablet protocol. The fundamental problem that prevents things
> from "just working" is that tablets don't send wl_pointer events of
> any kind.
> 
> There's certainly a compatibility benefit to having the tablet
> controlling the pointer, but it isn't always appropriate. 

note that the protocol doesn't *prevent* a compositor from emulating
wl_pointer events for tablet events. the weston implementation here doesn't
do so because I think it's a bad idea (for the reasons you outlined anyway)
but in theory nothing stops anyone from doing so.

> Although you
> can get away with it in the most common case of a non-display tablet
> mapped to the entire desktop, it gets annoying _fast_ when a tablet
> which is mapped to just a portion of the desktop (e.g. a display
> tablet on a multi-head system) since you /don't/ generally want the
> mouse cursor to move: you just want the UI elements you click on to
> respond. Putting tablets into separate seats might be a solution to
> this, but it seems like its ripe for causing other unintended problems
> (e.g. clicking on a text box and then not being able to type since the
> keyboard focus isn't associated with the same seat as the tablet).
> 
> Leaving support for the tablet protocol up to the client gives me
> pause, but its less frightening once you consider that practically any
> non-toy application will be written with the aid of a toolkit. As long
> as the toolkits do the right thing, so will applications built on
> them. Its the same situation with touch: authors who don't use a
> toolkit can write applications that don't function with a touchscreen,
> but most applications will work fine since toolkits know they need to
> handle wl_touch.
> 
> > My recommendation:
> >
> > - Proximity-in jumps the cursor and pointer position to the location but
> > does not change the cursor. It will however send proximity-in events to the
> > client (it will also send proximity-out to other clients using the tablet
> > interface, and normal wl_pointer exit events to clients not using the tablet
> > interface).
> >
> > - Client should respond to proximity-in by setting the wl_pointer cursor to
> > whatever is desired. Notice this is identical to how clients not using the
> > tablet interface respond to wl_pointer::enter events.
> >
> > This will 'blink' still, as the current cursor is also possibly not equal to
> > the desired cursor. This could be fixed, but if so the exact same fix must
> > be done to enter events or you really are not solving anything. Also note
> > that hiding the cursor is not acceptable, it will be perceived as a blink if
> > the cursor was correct and near the location of the proximity-in.
> >
> Disagree with these two recommendations as outlined above.
> 
> > - Proximity-in and enter events "freeze" the cursor at it's current
> > location, and it does not move until the client sets the cursor image.
> >
> Wouldn't this alone solve the issue of the wrong pointer being
> displayed for a split-second? I'm not sure if its the compositor's
> place to "freeze" the cursor until a client responds (that sounds a
> little dicey, especially with hung clients), but it could be an
> interesting approach.

freezing a cursor at a location makes the system look unresponsive as
opposed to just one application not updating a cursor quickly enough.
plus, if a client does not needing a cursor image for the tablet we may
freeze the cursor and wait for a request that never comes.
there's room for a wl_godot protocol, this is not it though :)

Cheers,
   Peter