Alan Hourihane wrote: > > 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.
Linus is pretty clear that he'd only accept a single module per driver - ie a radeon.o, but not a drm_core.o + drm_radeon.o combo. Keith _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
