Re: RFC: FULLSCREEN_MONITORS property

[Havoc Pennington <hp redhat com>]

Hi,

Here are a bunch of questions ;-)

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.

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)?

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.

Havoc