On Mon, Mar 22, 2010 at 7:59 AM, Dan Nicholson <[email protected]> wrote: > On Mon, Mar 22, 2010 at 7:15 AM, Stefan Dirsch <[email protected]> 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 <[email protected]> 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[0] = "apm"; break; >>> > case 0xedd8: driverList[0] = "ark"; break; >>> > case 0x1a03: driverList[0] = "ast"; break; >>> > - case 0x1002: driverList[0] = "ati"; break; >>> > + case 0x1002: >>> > + driverList[0] = "fglrx"; >>> > + driverList[1] = "radeonhd"; >>> > + driverList[2] = "ati"; >>> > + break; >>> > case 0x102c: driverList[0] = "chips"; break; >>> > case 0x1013: driverList[0] = "cirrus"; break; >>> > case 0x3d3d: driverList[0] = "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 > the formatting). > > diff --git a/hw/xfree86/common/xf86Config.c b/hw/xfree86/common/xf86Config.c > index 132e8bc..78eba05 100644 > --- a/hw/xfree86/common/xf86Config.c > +++ b/hw/xfree86/common/xf86Config.c > @@ -2480,7 +2480,7 @@ xf86HandleConfigFile(Bool autoconfig) > "Unable to locate/open config directory: \"%s\"\n", > xf86ConfigDir); > } > - if (!filename && !dirname) > + if (!filename) > return CONFIG_NOFILE; > }
On second thought, this probably isn't going to entirely work since you'll never end up parsing the .conf files in xorg.conf.d. So, I think solution #2 needs to be investigated. > 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. -- Dan _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
