Re: Override redirect windows with keyboard grabs on Xwayland
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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Override redirect windows with keyboard grabs on Xwayland
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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Override redirect windows with keyboard grabs on Xwayland
Hey Adam, > This feels a lot like any other "app wants attention" case where you > should just get a pulsing button or bouncing icon in the taskbar. The > o-r window might be mapped and focused from Xwayland's perspective but > there's nothing compelling wayland to actually show or focus it > promptly, you know it's o-r, you know it's full-screen sized, and you > have control of the display so when you _do_ put it up you can vignette > it and add a Get Me Out Of Here checkbox in the upper-right or > whatever. That mechanism would probably not work as is with O-R windows for a couple of reasons: - 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). - 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. 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 :) > I guess the thing you don't really get is a GrabNotify to let the wm > know what's going on, though maybe you could infer it from FocusOut. > There also appears to be no "wants attention" request in any wayland > protocol, which is perhaps suboptimal. But if we had that, xserver > could just emit that when an active grab fires, and then once the > window gets focus the grab works just as well as it ever would. 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). 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. Cheers, Olivier ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Override redirect windows with keyboard grabs on Xwayland
On Fri, 2016-06-17 at 03:49 -0400, Olivier Fourdan wrote: > Hi all, > > First of all, sorry for cross posting, but I am not really sure where > the issue is to be addressed... > > I am looking into https://bugs.freedesktop.org/show_bug.cgi?id=96547 > and concluded this is actually the same as https://bugzilla.gnome.or > g/show_bug.cgi?id=752956 > > Basically, long story short, we have clients in X that map a full- > screen override redirect window with a keyboard/mouse active grab for > the user to enter a password. > > Because override redirect windows are not managed by X11 window > managers, these won't focus the O-R window by themselves but that's > not a problem on X11 thanks to the active grab. > > Things get more complicated with those clients on Xwayland, because > the X11 active grab cannot be honoured in Wayland, and therefore the > window may or may not get focused automatically, depending on the > compositor/WM. In the worst case, the user might type his/her > password in some other (focused but hidden underneath) window without > even knowing it! This feels a lot like any other "app wants attention" case where you should just get a pulsing button or bouncing icon in the taskbar. The o-r window might be mapped and focused from Xwayland's perspective but there's nothing compelling wayland to actually show or focus it promptly, you know it's o-r, you know it's full-screen sized, and you have control of the display so when you _do_ put it up you can vignette it and add a Get Me Out Of Here checkbox in the upper-right or whatever. I guess the thing you don't really get is a GrabNotify to let the wm know what's going on, though maybe you could infer it from FocusOut. There also appears to be no "wants attention" request in any wayland protocol, which is perhaps suboptimal. But if we had that, xserver could just emit that when an active grab fires, and then once the window gets focus the grab works just as well as it ever would. - ajax ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
