[PATCH wayland-protocols] Add the tablet protocol

[Carlos Garnacho]

Hey,

On Mon, Nov 16, 2015 at 8:04 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> Bill,
>
> On Monday, 16 November 2015, Bill Spitzak <spitzak at gmail.com> wrote:
>>
>> There is a need to distinguish proximity-out from exit events. It is quite
>> possible to move the stylus so that the focus enters another client without
>> doing a proximity-out. Clients are interested in distinguishing these.
>
>
> This is true, hence my suggestion.
>
>>
>> I really feel the best method is to say a "seat" has a keyboard focus and
>> a pointer focus, and let the stylus manipulate the pointer focus. Thus the
>> client will get enter/exit events as the stylus is moved around above the
>> tablet, and proximity in/out when it is moved toward/away from the tablet
>> (it may also get a fake proximity-in event on enter).
>
>
> Pointer and tablet/touch are separate. X11 integrated them, and _that_ was a
> huge mistake. From our point of view, this is a closed topic.
>
> We've been over it time and time again, we've seen the ways the alternate
> model - though it seems attractive at first, which is why we did it for X11
> - fails, and we're not going back there.
>
>>
>> I really feel the cursor stuff is a huge mistake. It adds lots of
>> complexity for almost no actual gain. Witness how much code you had to add
>> to toytoolkit to support it. It adds complexity to clients as the client has
>> to pass which tool to subroutines for no reason other than to allow them to
>> change the correct cursor. The clients cannot assume the tool has the
>> "right" cursor and therefore they are required to have code to change it, so
>> this removes no complexity from clients. It is also hugely inconsistent with
>> how normal pointer enter events are handled in Wayland.
>
>
> It's not 'no actual gain', it's integral to the model.
>
>>
>> The only argument you had was that the cursor is more likely to be
>> correct, so when the proximity-in event happens, the cursor that appears has
>> a higher chance of being the same as the one the client sets and there will
>> be less blinking. However this can be implemented by the compositor without
>> any client api. Just have the compositor remember what cursor was used and
>> set that as a guess on the enter event. The client can remain completely
>> unaware of whether a cursor is remembered per-tool, or per-surface, or per
>> tool*surface, or whatever.
>
>
> The reason the protocol does not do this, is because when the cursor is
> different, you go from the other-surface cursor, to the old new-surface
> cursor, to the new new-surface cursor, very rapidly. It's ugly, and a
> bandaid for clients not responding quickly enough.

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.

Cheers,
  Carlos