[Panel-devel] Xinerama problems on Intel cards

[Jason Stubbs]

On Sunday 25 November 2007 13:16:18 Aaron J. Seigo wrote:
> On Saturday 24 November 2007, Jason Stubbs wrote:
> > On Sunday 25 November 2007 08:12:11 Aaron J. Seigo wrote:
> > > On Saturday 24 November 2007, Jason Stubbs wrote:
> > > > The attached patch does essentially the same in
> > > > Corona::loadDefaultSetup(). This handles the desktop part, but kwin
> > > > would also need to be updated to handle maximizing correctly.
> > >
> > > if this indeed is a real problem, we'll also need it in
> > > Containment::setScreen where the geometry is set for desktop
> > > containments after they've set up. which would implyu that it would
> > > make sense to have a "QList<QRect> Plasma::screenGeometries()" method
> > > in plasma.cpp. i don't think it needs a hash, a list should do, no?
> >
> > The key of the hash is holding which screen the geometry represents. I'm
> > not really familiar with xinerama or multiple displays so I'm not sure
> > how important that information is...
>
> woah; so the screens aren't even guaranteed to go up in order (e.g. 0, 1,
> 2, 3?) that's truly messed up, and if so i wonder whose brilliant idea that
> was =/

http://pastebin.ca/795784 is his xrandr output, and
http://pastebin.ca/795782 is his plasma startup messages

The screens do go up sequentually, but screen 0 is disconnected.

> in any case, yeah, commit the patch though we need the screen geometry code
> in plasma.cpp as a convenience method as we'll also need it for
> Containment::setScreen()

Actually, I'd like to see if I can get hold of the guy again. Thinking about 
it, this hack would probably cause the panel to default to off-screen when 
the disconnected device has a larger height than the connected device.

What do you think about optionally linking against the xrandr extension and 
doing like the xrandr cli util does to check whether screens are connected? 
That would seem safest (and most correct) in the long run...

-- 
Jason Stubbs