Re: [AD] More X Mode Setting

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On January 12, 2011, Peter Wang wrote:
> On 2011-01-12, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > I'm in the middle of refactoring the XRandR code. Not entirely sure when
> > it'll be done (soonish), but it is necessary.
> > 
> > Seems XRandR doesn't do anything without you telling it, and doesn't have
> > any notion about what relation one monitor is to the next, ie: theres no
> > LeftOf or Above type flags, so we have to calculate the right monitor
> > origins for each set of modes, to make sure multiple full screen
> > displays are right next to each other. And re-querying Xrandr can be a
> > tad expensive so I've added in the code to handle XRR notify events. But
> > it turns out it'll be more efficient to store our own custom XRR
> > structures rather than pointing to XRROutput structures, this way we'll
> > be able to detect what exactly changed (the change events in XRR are
> > rather coarse, just tells you that a CRTC or Output changed, and not
> > what inside changed).
> 
> I don't know if it would help you, but reconfiguring monitor setups is
> not something people do very often (if ever), so efficiency isn't a high
> priority.

True, but the XRandR query takes about half a second on my laptop, and we'd 
probably have to re do it every time we get an event. I don't think thats 
something we want to do. As we get an event for every change we make 
ourselves. So 2-4 events at least just for ex_dualies.

One thing I'm somewhat disappointed about is that all that work you did to 
make mmon display init lazy, has been made mostly redundant. Since now 
xdpy_create_display needs to init the mmon code. If we had a way to tell 
allegro to "ignore" multi monitor, we could make it so regular windowed 
allegro apps don't init it, but as of right now, we need to init the mmon code 
just to know if we want to init it. Its pretty silly.

> > If I'm able to work on it solid for the next couple days, I can see it
> > being done this weekend for sure. That includes a bunch of testing.
> > 
> > I really do wish the system vtable had a separate entry for creating a
> > fullscreen display. Would make the xdpy_create_display function[s] much
> > simpler and cleaner.
> 
> We can consider it for 5.1.
> 
> > All this extra time has let me figure out some funny things about X and
> > WMs though. Like we should NOT apply the PSize size hints to full screen
> > windows, and a few other funny things. But I'll have to retest them to
> > be sure it wasn't just the size hints getting set messing stuff up (it
> > seems to confuse most WMs to no end, with full screen windows).
> 
> Ok, thanks.

I've been trying to document /weird/ things as I go. The level of complexity 
in the X code is high enough that I can't fit more than a single execution path 
in my head at any one time, and theres probably 10 or more separate paths 
happening depending on the X version, the graphics driver, and what options 
were selected... So I've had to add a crap load of comments documenting 
various things I found I was having to "re-discover" every time I went into 
that code.

> Peter
> Allegro project manager (self-appointed)

:D

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx