[PATCH 2/2] xfree86: configure: remove vendor and card name matching rules

Alan Coopersmith alan.coopersmith at oracle.com
Thu Jun 10 12:41:57 PDT 2010


Dan Nicholson wrote:
> On Thu, Jun 10, 2010 at 7:04 AM, Guillem Jover <guillem at hadrons.org> wrote:
>> On Wed, 2010-06-09 at 07:27:32 -0700, Alan Coopersmith wrote:
>>> Tiago Vignatti wrote:
>>>> Vendor and board naming were never used to create the configure file a device.
>>>> This patch remove their references.
>>> I have been wanting for a while to move the autoconfiguration matching for
>>> video cards from a hardcoded list in the code to xorg.conf.d-style files
>>> like we use for input devices, and wonder if we'd want to use these in
>>> Match rules like the input devices have - though obviously we can do
>>> MatchPCIVendor "0x8086" just as well as MatchPCIVendor "Intel", and
>>> probably more reliably since pci.ids names can change without warning.
>> In case the latter was to get implemented, couldn't it just load the
>> pci.ids only if a MatchPCIVendor (or similar) appeared in the config
>> files, and thus only inflicting any slow down on such systems where
>> this was explicitly requested?
> 
> In Alan's example we're matching on the ID and not the string, but I
> suppose you could add a slowed down variant like MatchPCIVendorString
> or something that grabs the strings from pci.ids. But, yeah,
> definitely you'd only want to reach out to pci.ids if you really
> needed to.

Yeah, because after thinking about it some more, matching on vendor
string coming from pci.ids is a bad idea, since configs would break
when they update vendor names there (like "ATI" to "AMD" or "Sun" to
"Oracle"), or correct device name strings, unlike USB vendor strings
which come from the device and won't change arbitrarily.

I've seen enough diffs between versions of pci.ids go by as we check
in updates to know that it's not a source of stable name strings.

-- 
	-Alan Coopersmith-        alan.coopersmith at oracle.com
	 Oracle Solaris Platform Engineering: X Window System



More information about the xorg-devel mailing list