Ubuntu
xorg-server package

Comment 55 for bug 267241

Revision history for this message

Bryce Harrington (bryce) wrote on 2009-03-07: Re: [Fwd: [Bug 267241] Re: [intrepid] Xorg fails to start with more than one display adapter]

#55

On Sat, Mar 07, 2009 at 05:35:25AM +0000, Mark Shuttleworth wrote:
> Thanks for this work Bryce, I think the two-card scenario is
> increasingly common and additional robustness in the face of that will
> be appreciated by many users.

I definitely agree. As an aside, getting X working on multiple video
cards back in Xinerama days was how I got into X.org in the first
place. So this is an area I've a lot of personal interest in seeing
work.

> Is the choice of the card with the "highest busid" the best we can do?
> Can X tell if a display is connected to the card, and if one card has a
> display, select that? That would handle the case where someone has dual
> cards with some sort of bridge, but only one display connected to one of
> the cards.

X by itself isn't able to detect monitor connections; this probing is
done by the video driver. The video driver is selected based on which
video card is identified as the primary, so it's sort of a chicken and
egg problem.

I can think of a few workarounds, such as when multiple cards are
present, to load up vesa on each and see what's connected, then make the
determination of which card to use, pick the appropriate driver and load
it, etc. This could make for a slow boot process though, so doesn't
feel elegant, and it could take a fair bit of plumbing work, and it'd
definitely need to be done in conjunction with upstream.

I looked through all of upstream's multi-card bugs (there's a couple
dozen or so). I didn't find one with a clear plan of action, but the
problem is definitely well known.

I've a feeling the landscape here is going to change considerably once
we are on kernel mode-setting, since a lot of the decision making about
what displays to bring up moves to the kernel. It is possible that the
driver upstreams want to wait until this architecture's in place before
putting work into multi-card setups.

> Another common case is laptops that have a high power and a low power
> video chipset, both connected to the same screen. I don't know how X
> sees that today, or how it handles it.

Right, we have a bug on this one, and it also is known upstream:

https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/312756

Bryce

I definitely agree.  As an aside, getting X working on multiple video
cards back in Xinerama days was how I got into X.org in the first
place.  So this is an area I've a lot of personal interest in seeing
work.

X by itself isn't able to detect monitor connections; this probing is
done by the video driver.  The video driver is selected based on which
video card is identified as the primary, so it's sort of a chicken and
egg problem.

I can think of a few workarounds, such as when multiple cards are
present, to load up vesa on each and see what's connected, then make the
determination of which card to use, pick the appropriate driver and load
it, etc.  This could make for a slow boot process though, so doesn't
feel elegant, and it could take a fair bit of plumbing work, and it'd
definitely need to be done in conjunction with upstream.

I looked through all of upstream's multi-card bugs (there's a couple
dozen or so).  I didn't find one with a clear plan of action, but the
problem is definitely well known.

I've a feeling the landscape here is going to change considerably once
we are on kernel mode-setting, since a lot of the decision making about
what displays to bring up moves to the kernel.  It is possible that the
driver upstreams want to wait until this architecture's in place before
putting work into multi-card setups.