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

[Jasper St. Pierre]

If the client still has key focus, then it should get the key release.
That sounds like a compositor bug to me.

On Thu, Jul 16, 2015 at 10:28 AM, Arnaud Vrac <rawoul at gmail.com> wrote:
> On Wed, Jun 10, 2015 at 5:20 PM, Jasper St. Pierre <jstpierre at mecheye.net>
> wrote:
>
>> 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?
>
>
> There's a case where that doesn't happen: if the key press triggers the
> activation of an input method, which grabs the keyboard. The client still
> keeps the focus and has no way to know if has to stop generating key repeats
> for the key that triggered the activation.
>
> I'm getting exactly this issue, the keyboard grab is needed in the virtual
> keyboard to be usable with the arrow keys.
>
>>
>>
>> >> 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
>
>
> --
> Arnaud



-- 
  Jasper