Re: RFC: FULLSCREEN_MONITORS property

["David Trowbridge" <trowbrds gmail com>]

> First, a background point. Owen and I had a long thread with Kevin
> Martin a couple years ago (which was in private mail I think,
> unfortunately). Anyway, the claim I was making then was that Xinerama is
> overloaded to mean at least two things:
>
>   a) "I have one big monitor that happens to be made up of multiple LCD
>     panels / CRTs" - e.g. a video wall, is the extreme case
>   b) "I have two monitors and wish to be able to move windows between
>     them" - most commonly a plain dual-head or triple-head setup
>
> When we talk about "Xinerama support" in the window manager and widget
> toolkit, normally it means to act as if Xinerama is case b). That is,
> the WM will do things like interpret FULLSCREEN as for only one monitor;
> put DOCK windows on only one monitor; maximize to only one monitor; and
> so forth.
>
> All of this "Xinerama support" is busted if we are really in case a).
>
> Anyway, my claim at the time was that X should just claim to have a
> single monitor in case a), that is, apps have no interest in the
> Xinerama info in case a), because the multiple monitors are really a
> hardware implementation detail and not of interest. But at the very
> least, we might want some kind of global property (set by e.g. the
> desktop environment) that would tell the WM and the toolkit to ignore
> Xinerama.
>
> So second, why does FULLSCREEN go to only one monitor; it's because
> we're in case b), "Xinerama support," and assuming that the two monitors
> are supposed to be more or less separate. Common use-cases here include
> having a status display such as a bunch of stock tickers or server
> status readouts on one monitor and having your email/etc. on the other,
> or just having email/web on one and programming on the other, or whatever.
>
> Third, what is the case with VMWare? I'm guessing VMWare is totally
> weird in that it's essentially doing hardware configuration - assign one
> monitor to the VM and another monitor to the host, or something? Maybe
> you can walk through the rough use-case and what your configuration GUI
> for this might be like.

Our use case is that we're exposing multiple monitors to the guest.  The most
basic case is that you have two monitors on the host, and want to go fullscreen
over both, and see two monitors in the guest.  As Phil said, we allow any
contiguous combination of monitors, so people with three heads could have a
two-headed guest on two of them, and still interact with their host on
the third.

We don't really have any configuration GUI for this.  The basic user procedure
is that they go to fullscreen on one monitor, which becomes their "primary"
monitor.  We then present a toolbar on that monitor which has a button to extend
the window onto another monitor.  Since our primary market for this product is
software dev/test, it's really handy to be able to switch between multi-monitor
layouts at the click of a button.

> I'm having trouble thinking of something other than VMWare that might
> want the hint you proposed, is why I'm calling it weird... doesn't mean
> we can't do this hint, just that we shouldn't overload it with other
> user-cases that aren't the same.
>
> Fourth, excluding VMWare, what hints are missing...
> we could add _NET_WM_FULLSCREEN_ALL_MONITORS or something, but I think
> that might be wrong. It might be more correct to implement a property,
> to be honored by both WMs and toolkits, that essentially says "ignore
> Xinerama, this is case a) not case b)" - and then the existing
> _NET_WM_FULLSCREEN would cover all the monitors, and other "Xinerama
> awareness" would also be disabled.
>
> Can anyone come up with a use case (other than VMWare) that would need
> to force fullscreen to all monitors in case b)?

As I suggested in the bug report, blender wants to go fullscreen across all
monitors.  An all monitors hint would apply to them, but this would also work,
since it's a lower level request.  It requires a little more lifting
on the application
side, but not more than a few lines of code.  This sort of display is fairly
common in the sorts of applications you see from the graphics world, since in
a lot of cases, artists want to live completely inside their environment.

I imagine any other applications that want this would probably just want all
monitors, but people could potentially ask for a subset with devil's pie.


> Fifth, I guess we could complicate things by allowing combinations of a)
> and b) - "these two monitors form one monitor and this third monitor is
> separate"
>
> Sixth, I can imagine wanting to switch between a) and b) depending on
> context; maybe you play your flight simulator with your three monitors
> as one big screen, but when doing anything else you want three separate
> monitors. This quickly becomes a serious programming and UI nightmare...
> perhaps the proposed hint would fix it though by providing an "escape hatch"
>
> Finally, what is the interaction with dynamic changes... metacity
> reloads the xinerama info when it gets configure notify on the root
> window iirc... I think xrandr can dynamically change the xinerama info.
> It seems like there's a race created with the FULLSCREEN_MONITORS
> property. This may be a minor problem though.

There is a race.  I'm thinking it work to recompute the bounding rect
for any applicable
windows when the xinerama configuration changes.  There might be a
momentary flicker
between waiting for the application to update its requested monitors
and the window
manager updating it, but changing a xinerama configuration is fraught
with flicker anyways.

-David