Override redirect windows with keyboard grabs on Xwayland
Olivier Fourdan
ofourdan at redhat.com
Wed Jul 6 07:05:24 UTC 2016
Hi Adam,
> > 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?
No, I did not assume this, but I find focus management in X11 to be quite complicated in X11 window management alone, even more when it's coupled with a Wayland compositor managing both Wayland native surfaces and X11 windows, including O-R, so I try to remain as little intrusive as I can :)
> _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...
Yes, I guess there are cases where I can't avoid being a tad more intrusive...
> [...]
> 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.
Yes, definitely a good idea imho.
> > 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.
Sorry if my previous email made it sound like that, it's certainly not what I meant.
> 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.
Yes, agreed, I think adding an X11 compat protocol is the way to go.
I shall start gathering ideas and inputs when I'll get back from PTO.
Thanks
Olivier
More information about the xorg-devel
mailing list