It was a copy/past job. I'm working on rewriting a lot of it, the main point of the
patch is to
get devfs working. The pci ids are only needed if there is more than one card(under
linux) and
the code was copied from BSD so I just assumed that things would work there also.
I'm going to rewrite the device struct to match the one expected by linux...
struct pci_device_id {
unsigned int vendor, device; /* Vendor and device ID or PCI_ANY_ID
*/
unsigned int subvendor, subdevice; /* Subsystem ID's or PCI_ANY_ID */
unsigned int class, class_mask; /* (class,subclass,prog-if) triplet */
unsigned long driver_data; /* Data private to the driver */
};
1. There is no name feild.
2. There is no suported flag, so DRM_SUP can go.
3. I will take your E-Mail off it.
4. Dose BSD have a problem with the above struct?
--- Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Sun, 2002-07-14 at 21:33, Mike Mestnik wrote:
> > I patched my devfs patch so it can be used with the r200 branch. This was needed
>b/c my
> original
> > patch depended upon the shared structure introduced for BSD. BTW dose the R200
>work on BSD?
>
> My only concerns with your devfs patch (this one/the previous one):
>
> What is DRM_SUP for? No drivers need it. Matrox PCI is not supported
> on either platform afaik, and if it is in fact supported on Linux it's
> supported on BSD too but just hasn't been turned on. __REALLY_HAVE_SG
> is defined for Linux unconditionally, so no DRM_SUP_LINUX is necessary
> in the places you've used it (r128 pci). The only cases where one OS
> won't be supporting a subset of the cards (pci ids) supported by another
> will be when it lacks support for a specific feature (device-independent
> SG or AGP code, for example), or lacks support for the card entirely (in
> which case it won't build the device at all).
>
> Why #ifdef DEVICELIST? Do you think the pci id code will not be used in
> some cases (I hope not)?
>
This is to make ld work, trust me.
> Some remaining missing PCI IDs (xfree86/common/xf86PciInfo.h):
> i810:
> #define PCI_CHIP_I810 0x7121
> #define PCI_CHIP_I810_DC100 0x7123
> #define PCI_CHIP_I810_E 0x7125
> #define PCI_CHIP_I815 0x1132
>
> i830:
> #define PCI_CHIP_I830_M 0x3577
>
> r200:
> #define PCI_CHIP_R200_BB 0x4242
> #define PCI_CHIP_R200_QL 0x514C
> #define PCI_CHIP_R200_QN 0x514E
> #define PCI_CHIP_R200_QO 0x514F
> #define PCI_CHIP_R200_Ql 0x516C
> #define PCI_CHIP_RV200_QW 0x5157
> #define PCI_CHIP_RADEON_LW 0x4C57
>
> The comment above the device lists should be removed (my email and the
> site). The site is untrustworthy for pci ids, xf86PciInfo.h is much
> better for our purposes.
>
> Other than that, I really like the idea of new drivers coming with pci
> ids included.
>
> --
> Eric Anholt <[EMAIL PROTECTED]>
> http://people.freebsd.org/~anholt/dri/
>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by: Jabber - The world's fastest growing
real-time communications platform! Don't just IM. Build it in!
http://www.jabber.com/osdn/xim
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
