[ANNOUNCE] xorg-server 1.7.99.902

[Dan Nicholson]

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[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