Override redirect windows with keyboard grabs on Xwayland

[Adam Jackson]

On Mon, 2016-07-04 at 03:10 -0400, Olivier Fourdan wrote:

> That mechanism would probably not work as is with O-R windows for a
> couple of reasons:

Your descriptions here seem to assume the inability to fix the
compositor, which to me seems... insane? _Nothing_ xserver can do in
this situation is going to make this be handled reasonably all on its
own, we have to assume a cooperative compositor. So...

>  - the WM is not supposed to manage O-R windows (well, a compositor
> has of course, but the WM doesn't get a MapRequest and most WM will
> do as little as possible with O-R).

Yes, a traditional X window manager will mostly ignore o-r windows. But
a compositor has to draw them, and under xwayland must also route input
to them. Which means the compositor has the opportunity to _not_ draw
them and _not_ route input to them.

>  - O-R are not listed in the window list so even if the compositor
> would have set the demand attention flag, the shell would probably
> ignore it.

Again: that it is not in the window list does not mean it could not be
in the window list.

> Besides, what happens here is that O-R is already covering the entire
> screen (thus most likely cover any shell notification as well), and
> it feels natural for the user to start typing as the screen is
> covered and a nice text input is displayed :)

Again: that it is painted and responds to input is not mandatory. The
conditions described here (o-r, the size of an output, etc) are things
the compositor is aware of before it decides to map the wayland
surface. X can give it more information (GrabNotify or whatever), but X
can only request politely that wl behave nicely.

> We do (well, in gtk-shell no not strictly standard) have a "present"
> protocol that allows a Wayland client to ask the compositor to raise
> and focus a surface, we could use this with Xwayland to achieve that,
> but I suspect mutter would most likely deny such request on O-R (and
> being gtk-shell, that wouldn't work with any other compositor).

Sure, I wouldn't want to depend on gtk_shell either. Perhaps a better
idea is to write our own x11_compatibility protocol and use it if it's
there. The compositor would of course be free to honor that protocol
only for Xwayland servers it happens to be managing, or to not
implement it at all if it doesn't care about mixed x11 and native
wayland surfaces.

> Thing is, weston seems to do this right so there should be a way to
> achieve that in mutter as well.
> 
> The approach I took in my patch for GNOME bug https://bugzilla.gnome.
> org/show_bug.cgi?id=752956 is to not deny focus for O-R that are
> fullscreen (either on a single monitor or the whole screen):
> 
> https://bugzilla.gnome.org/attachment.cgi?id=330053&action=diff
> 
> It does fix the issue, but I am not sure this can be acceptable in
> GNOME.

If gnome considers purity of essence to be more important than correct
functionality, well, that's an opinion they can have I guess. I'm happy
to see X extended to give the compositor more information and better
control. But I don't see a reasonable way of fixing this entirely
within xserver. The compositor has to want to get this right.

- ajax