On Wed, 2004-05-19 at 11:25, Ian Romanick wrote:
> Jon Smirl wrote:
> > --- Alan Cox <[EMAIL PROTECTED]> wrote:
> > 
> >>s/OpenGL/Some drawing library/ - providing its using the kernel
> >>interfaces we don't care what. (eg the bogl console driver is very
> >>small, the opengl one would probably be rather larger and nicer)
> > 
> > I wasn't thinking that the kernel interface was standardized. For example DRM
> > has some common IOCTLs and then hundreds of per chipset ones. There is no
> > standard bitblt or draw char IOCTL.
> 
> IMO, this is a long standing problem with the DRM.  The main issue is 
> that there's only one version number associated with each DRM module. 
> What's needed is a device independent version and a device dependent 
> version.  In a sense, it needs something like an extension mechanism. 
> Right now, some drivers support a vblank wait ioctl and some don't.  The 
> ones that do support it, support it the same way.
> 
> If we could extend the DRM API in a device independent manner, we could 
> solve some of this.  When I thought about this in the past, I came up 
> with two ways to do it.
> 
> 1. Add a device independent version.  Device independent code could be 
> written that would test the version number the same way device dependent 
> code does today.  The drawback is that in order to advertise version X.N 
> functionality, you also have to adverteise version [1.1, 1.N-1] 
> functionality.  Some hardware / drivers may not want to / be able to do 
> that.
> 
> 2. Add an "extension" query ioctl.  Give each piece of functionality 
> (i.e., all the related vblank functions) a unique number.  Drivers would 
> make a query like, "Is extension 5 supported?"  If that ioctl returns 
> true, then the driver could use that functionality.  The disadvantage of 
> this method is that it increases the number of ioctl calls that need to 
> be made.  Since the set of supported extensions can be tracked in the 
> DRM with a bit string, the additional code size should be trivial.
> 
> Thoughts?

We already have a device independent version.  What I put in was that
the X Server can request a DRM device-independent and device-dependent
interface version.  The DRM changes its behavior accordingly (busid
handling was the first change).  Returns EINVAL if unsuccessful, and
returns the actual version numbers of the DRM DI/DD interface, either
way.  Request -1.-1 version to just get the version number of an
interface without changing anything.

This was part of working to allow removal of old DRM code/features,
which I've been completey distracted from.

-- 
Eric Anholt                                [EMAIL PROTECTED]          
http://people.freebsd.org/~anholt/         [EMAIL PROTECTED]




-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to