From: Eric A. <et...@lc...> - 2003-10-22 03:08:05
|
http://people.freebsd.org/~anholt/dri/files/drm-unique-2.diff Here's my first shot at the changes for unique handling in the DRI. It includes a new ioctl, DRM_IOCTL_SET_VERSION. This takes in a struct containing numbers for the major/minor version of the device independent DRM interface and major/minor of the device dependent interface version (the version numbers we're familiar with for the DRM modules). If the DI interface version is 1.1, we set the busid based off of the PCI device we probed as. It's in the pci:oooo:bb:dd.f format as Linus requested. The *_dri.c in the DDX have been converted to use a new libdri function DRICreatePCIBusID which also creates a busid in that format. libdrm understands both of these formats. If the DI interface version doesn't get set, then the DRM behaves in the same way as before (haven't tested it again to be sure yet). Nothing uses the DD interface version number yet, but there's a simple hook in there for it. The setversion ioctl returns the actual versions of the DI and DD interfaces in the structure that was passed to it. Things I'm thinking about: - What should the DRM do if the minor number for either DI or DD interface is greater than the DRM knows about? - Need to limit setting of the general interface version to root (X Server) probably. Not an issue with the current version, though. - Can we deprecate SET_UNIQUE? My idea is that the ioctl would still function, but call set_busid like the new interface version does and then return an error if the unique being set is not equivalent to the device's. This would break some DRI setups with multiple cards of a single type in a system with an old X Server. - Do we want to put some reserved fields in the SET_VERSION ioctl in case we want to extend it in some manner in the future? - Do we want to create an ioctl to get the PCI ID from the DRM? If we do, I would also like to put the IRQ number in there, too. I want to deprecate the irq-from-busid feature (particularly given the concerns about domains), at least lobotomizing it to only check that the busid info passed in matches the device's and then return the irq for the device. - Should the libdri minor version be bumped for the new DRICreatePCIBusID function? Is using xf86LoaderCheckSymbol the way to see if it's available, and does it need to be in the symbol lists for the drivers? - I would like to move xf86drm.c to shared/drm/ (it's a shared file anyway). Is there any value in the /proc/ support in it any more? - drm.h should probably get re-merged and put into shared/ -- Eric Anholt et...@lc... http://people.freebsd.org/~anholt/ anholt@FreeBSD.org |
From: Michel <mi...@da...> - 2003-10-22 22:18:09
|
On Wed, 2003-10-22 at 04:56, Eric Anholt wrote: > - What should the DRM do if the minor number for either DI or DD > interface is greater than the DRM knows about? Return DRM_ERR( EINVAL ) ? > - Do we want to put some reserved fields in the SET_VERSION ioctl in > case we want to extend it in some manner in the future? The versioning could be used to extend it? :) > - Should the libdri minor version be bumped for the new > DRICreatePCIBusID function? I think so. > Is using xf86LoaderCheckSymbol the way to see if it's available, That or the minor version I guess, whichever is more convenient. > and does it need to be in the symbol lists for the drivers? Yes, or it will probably be reported as unresolved when the dri module isn't loaded. > - I would like to move xf86drm.c to shared/drm/ (it's a shared file > anyway). [...] > - drm.h should probably get re-merged and put into shared/ Sounds good. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer |
From: Eric A. <et...@lc...> - 2003-10-22 21:19:00
|
On Wed, 2003-10-22 at 13:59, Michel D=E4nzer wrote: > On Wed, 2003-10-22 at 04:56, Eric Anholt wrote:=20 > > - What should the DRM do if the minor number for either DI or DD > > interface is greater than the DRM knows about? >=20 > Return DRM_ERR( EINVAL ) ? Okay, that's what it's doing. > > - Do we want to put some reserved fields in the SET_VERSION ioctl in > > case we want to extend it in some manner in the future? >=20 > The versioning could be used to extend it? :) That would be messy, unfortunately, on BSD at least. The ioctl handler checks that the data size the user specified and that got copied in by the kernel matches the size the kernel expects. Actually, I suppose it would be doable, by marking the specific ioctl as expecting the smaller of the two sizes, making the size check be usersize >=3D kerenelexpectedsize, and then the specific ioctl handler would special-case the larger size. So I guess as long as there's no real expectation of needing to extend it, it can be ignored. > > - Should the libdri minor version be bumped for the new > > DRICreatePCIBusID function? =20 >=20 > I think so. >=20 > > Is using xf86LoaderCheckSymbol the way to see if it's available,=20 >=20 > That or the minor version I guess, whichever is more convenient. >=20 > > and does it need to be in the symbol lists for the drivers? >=20 > Yes, or it will probably be reported as unresolved when the dri module > isn't loaded. Okay, I'll do these. --=20 Eric Anholt et...@lc... =20 http://people.freebsd.org/~anholt/ anholt@FreeBSD.org |