This is a personal tracker item for myself.
The pcitable and Cards databases need to be updated to more closely
reflect the actual list of hardware supported by current xorg-x11.
Also, pciids.sf.net needs to be updated and various corrections
made.
This is a rather time consuming ordeal to get all of these updated
to be accurate, so I felt it best to log this tracker, and try to
break it down into smaller tasks that can be prioritized more
easily.
Overview:
All of the video drivers in current X.org X11 need to be eyeballed
one at a time to determine what PCI IDs they support, and that needs
to be compared with our pcitable to see what entries are missing,
and get them added, and then add to the Cards database as well.
That often involves surfing hardware vendor's websites to get Windows
INF files also, as X drivers often have mistakes in their lists,
which uncover mistakes in pcitable, and needs to be merged with
pciids.sf.net, yada yada yada - essentially the biggest nastiest
hairball. <grin> Very tedious, which is why the list is often
out of date.
As such, my priority is to focus on the drivers that are the most
commonly used and most frequently change for now. Right now, in
rough order of priority, this includes:
- radeon
- nv
- i810
- via
- sis
- savage
Other drivers may be out of date, but rarely change, and are much
lower priority, but still need to be accounted for in the long run
for completeness.
Future problems to solve:
Each architecture supports a different set of drivers, however our
pcitable and Cards database are a single database shared between
all architectures. That means that we either:
1) Have one common database that is shared between all architectures,
which is accurate for x86, and inaccurate for all other
architectures.
or
2) We fork the hwdata package and maintain separate instances of it
for each arch, having to add/remove/change new stuff in multiple
locations.
or
3) We put per arch files all in one hwdata package, and have it
generate the lists at build time for the proper architecture.
or
4) We modify the pcitable and Cards file formats to be able to have
ifarch/ifnarch data.
The problem is more complex than that though, because some hardware
is supported on some architectures only in PCI form factor or only
in AGP form factor. In other cases, certain driver features need to
be disabled like DRI, or certain extra driver options are needed
on PCI cards but not AGP, or other serious convolutions. We've
managed to "get by" to date, but that does not mean this is a good
solution, nor that it is "good enough" for the future. I believe
we need to strive to be "better", and that a new solution is needed
for the future, which needs to be well designed from the beginning,
and not just implemented as a quick ugly hack, or a simple add on
to what we have that is a half solution.
So, for the short term, we can "get by" with what we have now,
and just update these files for current X support.
In the long term though, I want to move video related configuration
metadata into a separate set of database file(s). I believe it
would be better to move to a metadata file featureset that more
closely resembles Windows .INF files, as that keeps both the
PCI ID data, and the video card data and configuration info in one
place for that hardware. This is not a small task however, and
while I do have a draft design for this new format, it is something
that I would like to have done upstream on freedesktop.org as a new
X driver metadata standard, and perhaps even a general driver
metadata standard like .INF files. pcitable works fine for the
kernel, as all kernel drivers are monolithic in one place and
probably always will be, but X drivers, while monolithic now, will
be changing in the future, and when we move to the model where we
have modular drivers upstream, and in the distro, we need to make
driver updates more scaleable. It makes sense to keep the metadata
_with_ the driver. That way the metadata can be autogenerated also
during driver building. The end result is metadata files that are
always up to date with what the driver supports, and lower engineering
maintenance costs. Users have less "my card isn't detected" bug
reports, and it's more robust all around.
"Short term" above, I define as FC2, FC3, RHEL4 at least. Long
term I define as FC4 and later, and RHEL5 and later. It may even
be longer than that because I want to have it done upstream rather
than internally, and I want it to be done right, and not rushed
to get into a particular release, possibly broken, or possibly
missing features, and then have to support the broken setup for
compatibility in the future. So a lot of this is pie in the sky
rambling right now, but it is nonetheless a problem that needs to
be solved in the OSS X world, if Linux is to be taken seriously
on the mass market of desktop systems out there in the future, which
is one of the goals on our plate for RHEL5 era.
Ok, enough of an essay to myself. Now back to the job at hand.