Re: [AD] More X Mode Setting

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On January 17, 2011, Peter Wang wrote:
> On 2011-01-15, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > On January 14, 2011, Thomas Fjellstrom wrote:
> > > On January 14, 2011, Peter Wang wrote:
> > > > What's the reason for tracking which monitor a window is on?
> > > > Sorry if it's obvious.
> > > 
> > > The main reason is that its used to track which monitors are in use, so
> > > we can black list multi-displays in x multi-head mode even with true
> > > xinerama enabled (glx seems to have issues with it, at least it was
> > > causing hangs, I'll have to test again to make absolute sure it wasn't
> > > locking issues, but I'm pretty sure it wasn't).
> 
> If I've understood right (correct me where I've missed something):
> the reason we're unable to lazy init the mmon code is so that we'll have
> enough information to prevent opening windows on multiple adapters when
> using traditional(?) multi-head (ScreenCount > 1) or
> Xinerama (ScreenCount == 1).  And the blacklisting is not required if
> using RandR.

Not quite I don't think. Its to check if we have Nvidia's TwinView, or 
traditional Multi-Head. Right now I'm using the difference between xrandr's 
"CRTC" count and Xinerama's Screen count to tell if TwinView (or something 
like it) is enabled, since TwinView only exports a single large Desktop, and 
fakes separate desktops with FakeXinerama.

If we have True Xinerama, its most likely that XRandR won't even be available, 
and we'll fall back to XFVM.

If we are using traditional multihead, we have to black list multi displays, 
and if we have TwinView, we need to blacklist XRandR (Since much of the code 
is useless under TwinView, as there is no (clean) way to fetch or set modes on 
individual monitors).

> If that's right, we should be able to query _only_ which extensions are
> in effect, _without_ getting detailed information about monitors and
> screen modes, and decide if the blacklisting code is required.  That
> would be pretty lazy for the common cases (single adapter, or using
> randr).

We might be able to get away with that, but we still have the issue of 
TwinView. As long as the user never sets the "new adapter" or "new adapter 
position" I think we might be able to lazy init. Otherwise we need to query 
things like the number of adapters and their offsets when creating a display.

At least thats if we're using xrandr, or true Xinerama (I think). If we have 
traditional multi-head, we absolutely need to be careful with making sure we 
give X and glX the same X Screen id, or I think we can run into trouble (might 
cause the visual loading code to fetch the wrong list of visuals).

I did say the code was a bit complex...

And in case you're wondering, the only other way to detect if we have TwinView 
is to link to NVidia's NVCtrl lib, which is only distributed as a static 
library, so we can't even ldopen it and check that way. And I really don't 
want to have to make NVCtrl a hard dependency.

tl;dr:

We might be able to get away with lazy init by checking if we're under XRandR, 
that the "new adapter" or "new display pos" are set, if they are -1, and that 
we're not setting a FULLSCREEN display, we can skip mmon, hopefully.

That all said, I don't think it may even be necessary. Are you still seeing 
that ugly monitor blanking on even windowed displays? I haven't seen any on 
either my desktop (older Xorg with latest nvidia driver) or my laptop 
(bleeding edge xorg with bleeding edge intel driver). The only annoying thing 
is that the XRandR XRRGetScreenResources function can take upwards of 
200-500ms to call.

> Peter
> 
> ---------------------------------------------------------------------------
> --- Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx