[PATCH wayland] protocol: define further the behavior of input on the presence of grabs

[Jasper St. Pierre]

On Wed, Jun 10, 2015 at 4:50 AM, Carlos Garnacho <carlosg at gnome.org> wrote:
> On mar, 2015-06-09 at 11:03 -0700, Jasper St. Pierre wrote:
>> What is the value of clients having this information?
>
> The same there is in having wl_touch.cancelled. See the cases in the
> original email in the thread.
>
>> I think we've
>> tried to hide grab semantics from the point of view of the client and
>> simply say "we can revoke input at any time, including in response to
>> a request you make", which gives us, the compositor, a lot more
>> leeway
>> with future possibilities.
>
> Sure, I'm all for that. What I'd really want is having a way to tell
> clients we do so. I'm totally fine with documenting the places where
> this potentially happens on a per-case basis, even if the final wording
> is "compositor dependent", same as for seat.release_input emission.
>
> That said, toolkits/clients will surely expect some consistence across
> compositors, so the leeway is relative.
>
>>
>> Grabs were a major pain point in X11 since they were overspecified,
>> so
>> we're trying to not fall into that same trap again.
>
> I'm sure there is a lot of ground between "let's not overspecify" and
> "let's go shopping".
>
> It would be convenient first to identify what are the sore points with
> X grabs. AFAICT, most of these come from grabs not being easily
> transferred, and the WM/screensaver/etc not being more of a client to
> revoke/break grabs. On wayland the compositor is completely free to do
> as it pleases, with and without this change I'm proposing.

Yeah, transferring grabs race-free, a lack of being able to override
or revoke grabs are the top two. But focus management + grabs in X11
is tricksy and sort of awkward: if I take a keyboard grab, key focus
can still navigate around as usual, we'll just get NotifyWhileGrabbed
as our detail.

> However, one thing that X did well is defining a consistent event
> delivery model when grabs were being taken (well, except for touch
> events...), so both the grabbing and the pre-grab windows are well
> aware of what's going on, I think one is due in wayland, at least face
> to clients.

Did it? I don't know of any model that lets me know when a client has
taken a grab or ungrabs their existing grab. The exception is that I
believe if I'm the key or pointer focus, I'll get a FocusOut / Leave
event with the "NotifyGrabbed" detail, and when the grab is dropped
(and I am still the key focus / pointer focus, which is not
guaranteed!), we'll get the reverse event with "NotifyUngrabbed".

And in X11, this is actually good, because such an event would be
racy: some other client might have taken a grab in such a time. And it
happens all the time because of passive grabs, including X11's own
implicit passive grab on the pointer.

Anyway, this model matches well with wl_keyboard.leave /
wl_pointer.leave being sent at the start of device grabs.

>>
>> For instance, if the user is in a game that has a keyboard grab and
>> presses Alt-Tab to switch out, the client should just have its
>> keyboard grab revoked without having to have that as a possibility in
>> the protocol spec. Same thing with tray icon behavior, etc.
>
> sure, in that case you'd still get wl_keyboard.leave and the client can
> properly undo the key press / mods. But notice there is always a need
> to know when to undo (eg. in your example above, the game might have
> bound Alt to "release flares", if you first press Alt and then Tab, and
> the client doesn't get the Alt key release, you don't want to leave
> that stuck when you focus back)

The client gets a wl_keyboard.leave. Is that not good enough? What use
cases does this new event solve?

>> Clients need to cope with losing mouse and keyboard focus at any
>> time,
>> and with seats going away at any time. It's just how it is.
>
> Toolkits are nothing else than giant state machines, they rely on a
> meaningful event order, or some proper notification when things go
> south. If you mess with that, you'll get clients in inconsistent
> states, including:
>
> - stuck buttons
> - gestures listening to vanished touch sequences, unable to trigger
> anymore
> - stuck repeat keys
>
> Cheers,
>   Carlos



-- 
  Jasper