Re: [AD] More X Mode Setting

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On January 12, 2011, Peter Wang wrote:
> On 2011-01-06, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > On January 6, 2011, Thomas Fjellstrom wrote:
> > > On January 6, 2011, Peter Wang wrote:
> > > > On 2011-01-05, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> > > > > I'm a little stuck here. It didn't seem to lock up for trentg on an
> > > > > older
> > > > 
> > > > > ubuntu, but here on debian with a really new X/Mesa/whatever I get 
this:
> > > > I'm can't reproduce the deadlock on my machine.
> > > > 
> > > > I saw that in some places you forgot to release system->lock, e.g.
> > > > after XGetInputFocus fails.  I assume you've checked the allegro.log
> > > > so it shouldn't be the cause.
> > > 
> > > Hmm, that might be it. though the deadlock seems to be on the event
> > > queue, or so gdb seems to think.
> > 
> > Yeah, you were right. I think it was the randr restore_mode call. All
> > nice and smooth now.
> 
> What's the status of your patch?

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

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.

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

> 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