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

[Arnaud Vrac]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150716/01392a6a/attachment.html>