Alan Hourihane wrote:
>
> On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote:
>
> I'll use the Linux DRM semantics which 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
> >
Alan,
I've gotten away from this encode on the driver side. We'll have four
drmCommand* entry points to identify direction. Size is an explicit
parameter. Type is embedded in the DRM os specific layer and is always
'd'.
> Doesn't the request identify it's direction ?
request is now an OS independent offset that goes from 0 to 0x3f, and
just identifies the DRM command.
> Also, we should be able to hide the type in the Linux os support and
> not need to pass this ?
Yes.
> 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.
Yes, there is a little more than packing and unpacking. For large
routines, complicated routines, we could even share code between 2D and
3D drivers. I'd rather see a few additional binary modules in the
existing 2D and 3D drivers than N*M new standalone modules, where N is
the number of drivers and M is the number of supported OS's.
> 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.
If the submodule is OS dependent we get in to the N*M combinations,
problem. If the submodule is OS independent, it might as well go into
the driver.
> We've also got easy backwards compatibility this way too.
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
