[PATCH wayland-protocols] Add the tablet protocol

[Bill Spitzak]

On Mon, Nov 16, 2015 at 11:55 AM, Carlos Garnacho <carlosg at gnome.org> wrote:

> It's probably worth pointing out that his concerns are moot, there is
> no blinking, or rather, has an easy solution in compositors.
>
> When a tool physically enters in proximity over a surface, the cursor
> should be effectively invisible, the client below it will emit
> wp_tablet_tool.set_cursor in response to proximity_in, and it will be
> set accordingly from the previous invisible state. If the tool moves
> across surfaces, the cursor won't be modified until the new focus
> surface calls wp_tablet_tool.set_cursor, just like it happens with
> wl_pointer.set_cursor and wl_pointer.enter. When the tool physically
> leaves proximity, the cursor would be made invisible, destroyed, or
> whatnot.
>
> Compositors may of course want to set a default cursor if the
> proximity_in happened outside a surface, so that there's something
> visible until the tool enters a surface, but this is easy enough to
> detect before even showing the cursor. AFAICS the only source of
> "blinking" would be compositors invariably setting a visible cursor
> before the client has an opportunity to do so, that sounds somewhat
> sloppy though.
>

I'm not sure why you think I am arguing for an old point, as Carlos
describes exactly the same thing I am thinking of.

His proposal removes the need for there to be a per-tool cursor in the
client api. The client only sets the cursor for the most recent tool, and
the user can only see one cursor. IMHO this can be done in the easiest way
by reusing the wl_pointer api, rather than adding new api that clients will
just be forced to select between because only one of the api's works at any
time.

He is proposing the "strong" version of what I said, which is that the
cursor is actually frozen (not moving or changing) until a cursor-set is
received from the client that has focus. If this is a good idea it probably
should be done for normal pointer enter events as well. The benifit of this
is that it obeys the "every frame is perfect" rule of Wayland.

I was assuming a "soft" version that works like the current pointer enter
events, where the cursor does not change but follows the pointer without
waiting for the client to set the image. The cursor image is thus a "guess"
by the compositor. IMHO the best "guess" is to leave the cursor unchanged
from whatever it is now, as this will reduce the number of transitions when
the guess is wrong, and it is how enter events work currently. However a
compositor could try to save a "guess" that tracks the cursor per-tool,
per-surface, or even per tool+surface combination. None of that should be
visible in the client api however.

Changing the cursor on proximity-in outside any client is an interesting
problem. I think the compositor should be entirely in charge of this,
though "guessing" that it is the same as the most-recent client, which
seems to be the proposal here, may be reasonable. The compositor is still
going to need an image to use if no client has gotten a proximity-in yet,
so this does not remove the need for it to supply something without client
help.

I also have no idea what you mean by this being a repeat of some mistake
done by X11. I am not changing in any way what events are being received by
the client compared to the current proposal, therefore if my idea is wrong,
so is the current proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151116/1d7bb2c9/attachment.html>