On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote: > Alan Hourihane wrote: > > > > On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote: > > > I've made some headway on this today, and could use some feedback based > > > on your BSD experience. I've attempted to move the packing of > > > drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing > > > is the actual IOCTL request number. I can easily use the Linux number, > > > but I thought it might be better to have some OS independent offset. > > > However, generating all the combinations of _IO, _IOR, _IOW and _IOWR > > > semantics in an OS independent way is going to be challenging. See > > > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line > > > 373 > > > > > > Here is an incomplete patch in case you are interested in the general > > > direction I was currently prototyping... > > > > > > Should I just use the Linux _IO* semantics and let other OS ports > > > twizzle this to get this working, or do you have any ideas on how we can > > > generate the proper semantics in a more general way. I think we will > > > need to generate these semantics at run time, not compile time. > > > > > Jens, > > > > The idea of offset's with an os dependent MAGIC_NUMBER sounds like > > the right idea. I also think that we go ahead and use the Linux _IO* > > semantics, as the *BSD just twizzles around these anyway at the moment. > > And until more OS's support the drm (or at least show some signs) then > > that's probably the best we can hope for. > > Okay, I'll use the Linux DRM semantics where are: > > ( (direction) << 30 | (size) << 16 | (type) << 8 | (request) << 0 ) > > where > > direction is: 0 for none, 1 for write, 2 for read and 3 for both > size is: size of record to be transfered > type is: 'd' for DRM drivers > request is: our OS independent offset > Jens,
Doesn't the request identify it's direction ? Also, we should be able to hide the type in the Linux os support and not need to pass this ? I've just taken a closer look at the xf86drmRadeon.c code, and in drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. Going down this road though, we'll be pushing that back into the 2d/3d code which I don't think is the right way to go. I'm thinking more of Jeff's solution now, and what we could do..... If we take a minimalist xf86drm.c which makes the libdrm.a loadable module. Then within xf86drm.c we identify which sub-drm module to load (i.e. the driver's libradeon_drm.a - or something like that) and load it. For the *BSD's this code is a symlink from the Linux directory. We can already load a kernel module based on name via drmOpenByName, we could just implement another drmSubOpenByName command to load the sub module based on it's name. We've also got easy backwards compatibility this way too. Alan. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
