[ANNOUNCE] xorg-server 126.96.36.1992
dbn.lists at gmail.com
Mon Mar 22 08:21:07 PDT 2010
On Mon, Mar 22, 2010 at 7:59 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> 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
> 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",
> - 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.
More information about the xorg-devel