On Thu, Jul 31, 2003 at 09:02:08AM -0700, Ian Romanick wrote:Keith Whitwell wrote:
It would be simple to add some checking to ensure the chipid is recognized by the 3d driver, just hasn't been done yet.
Let me work up a patch that does this in a more generally way. The current big switch-statement is somewhat unpleasant. Do the embedded drivers have a header file where they get PCI IDs? I assume that xf86PciInfo.h is not available. :)
Notice that in order to more easily build 2D drivers of the CVS branch with the latest released stable driver SDK, it makes more sense to move the pci id information out of the xf86PciInfo.h file and into each individual drivers. With the new (well, new as in 4.x or something such) driver architecture, the xf86PciInfo.h is not really needed anymore, since each driver knows how to detect supported cards himself.
Maybe doing something similar for the 3D drivers would be a step in the right direction, instead of importing the monolitic xf86PciInfo.h file.
Agreed. The direction I plan to go is have a Python script that will process pci.ids and generate a table using the data there (much like is done in the Linux kernel's PCI driver). Basically, the table will be of structures like so:
struct driPCIInfoRec {
uint_fast16_t device_id;
uint_fast16_t device_vendor;
uint_fast16_t subsystem_id;
uint_fast16_t subsystem_vendor; const char * device_name;
const char * device_driver; union {
int i;
void * p;
} device_data;
};The script will pull the first 5 fields from pci.ids, and the remaining 2 will be supplied as parameters. The last field could store things like G200 vs. G400 for the MGA driver, or TCL vs. no-TCL for the Radeon driver, etc.
Where would we want such a script to live in the tree? We wouldn't want it to run as part of the build process because pci.ids may not always be available. We'd want to "periodically" run the script against an known good pci.ids to generate the .h files for each driver and commit the new .h files. There are some scripts like that in Mesa, but I don't think they exist in the DRI tree.
This does make one subtle, but VERY important change to the policy carried out by the driver's init function. Right now all of the drivers will try to run even if they don't recognize the PCI ID. If we go this route, that will change. If a device ID isn't in the table, the driver will bail. Given what Keith and Michel had said about the embedded branch, I think this is the better way to go. Thoughts?
The nice part about doing it this way is that, as new devices come out, we just have to make sure that pci.ids is up to date (a good idea anyway!) and regenerate / commit the .h files for the drivers. I had shared Michel's maintainence worries over the old switch-statement based approach, and I think this solves that.
BTW, what about the drm modules, do they recognize the hardware also, or do they not care about being loaded or not.
I think they check, but I'm not sure. I'd have to look.
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
