[ANNOUNCE] xorg-server 220.127.116.112
dbn.lists at gmail.com
Mon Mar 22 07:59:18 PDT 2010
On Mon, Mar 22, 2010 at 7:15 AM, Stefan Dirsch <sndirsch at suse.de> wrote:
> On Mon, Mar 22, 2010 at 05:56:03AM -0700, Dan Nicholson wrote:
>> On Mon, Mar 22, 2010 at 3:12 AM, Stefan Dirsch <sndirsch at suse.de> wrote:
>> > On Sun, Mar 21, 2010 at 10:45:26PM -0700, Keith Packard wrote:
>> >> According to the published schedule, we're supposed to be closing in on
>> >> the release within the next couple of weeks. I'm pretty satisfied with
>> >> the current state of the code, but I'd love to hear about regressions
>> >> that people are finding so that we can clean things up before the
>> >> release.
>> > One serious regression compared to xorg-server 1.7.6 I've found during the
>> > weekend is that video driver autodetection no longer works with xorg.conf.d in
>> > place.
>> > For instance I'm using the following snippet to allow preferring fglrx and
>> > radeonhd driver if installed.
>> > --- hw/xfree86/common/xf86AutoConfig.c
>> > +++ hw/xfree86/common/xf86AutoConfig.c
>> > @@ -176,7 +176,11 @@
>> > case 0x1142: driverList = "apm"; break;
>> > case 0xedd8: driverList = "ark"; break;
>> > case 0x1a03: driverList = "ast"; break;
>> > - case 0x1002: driverList = "ati"; break;
>> > + case 0x1002:
>> > + driverList = "fglrx";
>> > + driverList = "radeonhd";
>> > + driverList = "ati";
>> > + break;
>> > case 0x102c: driverList = "chips"; break;
>> > case 0x1013: driverList = "cirrus"; break;
>> > case 0x3d3d: driverList = "glint"; break;
>> > This no longer works. If "fglrx" driver is not installed the Xserver just
>> > gives up, i.e. no longer tries to use "radeonhd", then "ati/radeon". There is
>> > no xorg.conf in place (I'm aware that this mechanism never worked with
>> > xorg.conf in place), but xorg.conf.d is. After removing xorg.conf.d the
>> > mechanism works again.
>> > If there is a way to specify priorities for video drivers in xorg.conf.d
>> > (matching vendor IDs) to replace that mechanism please let me know.
>> Can you show logs for the two cases?
> See them attached.
>> There isn't a mechanism for video driver matching besides that one,
>> either. Does the xorg.conf.d directory have any .conf files in it? One thing
>> that will happen is that if either xorg.conf or any .conf files in
>> xorg.conf.d are found, then the full autoconfig won't happen.
> Yes, I believe this is exactly what happens here. There is no xorg.conf, but
> .conf files in xorg.conf.d directory.
>> I'm guessing this person must not have had a xorg.conf before,
> Yes, that's correct. autoconfig only worked with *no* xorg.conf in place.
>> but I thought the video autoconfig would still kick in if there were no
>> Screen sections.
> No, once you have an empty xorg.conf you're lost, an empty xorg.conf.d
> directory is still ok though.
That makes sense. There are two ways to handle this.
1. Make the full autoconfig kick in when only xorg.conf is missing. I
don't think this is ideal since you could have a perfectly valid
configuration with only .conf files in xorg.conf.d. However, it might
work as a stopgap. Below diff would make this happen (gmail will hose
diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c
index 132e8bc..78eba05 100644
@@ -2480,7 +2480,7 @@ xf86HandleConfigFile(Bool autoconfig)
"Unable to locate/open config directory: \"%s\"\n",
- if (!filename && !dirname)
+ if (!filename)
2. Make the handling of missing sections from an existing
configuration behave more like the full autoconfig. In other words, if
there's a missing Screen section, generate multiple Screen/Device
pairs with fallbacks. I think this is the correct fix, but I'm not
that familiar with the autoconfig code so I don't think I could whip
up a patch that fast.
More information about the xorg-devel