Re: DRI integration

Keith Packard wrote:
> Around 13 o'clock on Nov 12, Jon Smirl wrote:
> 
> 
>>What do you think about modifying xserver to use Mesa/OpenGL for it's drawing
>>API? 
> 
> 
> I'm not sure that's entirely feasible; GL is missing some functionality
> required for both the core protocol and Render extension. 

In general this isn't a problem.  Exporting bits of hardware functionality not 
covered by GL is typically a doddle.  It'd be interesting to know what you're 
referring to.  It may even just be a case of digging out some little used 
aspect of GL & properly optimizing the implementation.

> However, I would
> really like to explore building a common kernel command set that the X
> server can use for acceleration that is based on GL as all of the
> interesting acceleration is compatible with the GL model (as Render was
> designed that way).
> 
> If this were possible, then the binary nVidia driver could expose just 
> this kernel API and the X server would run at reasonable speed, without 
> any user-mode proprietary information at all.
> 
> Building a standard kernel API would let us eliminate all card-specific 
> information in the X server.  Doesn't SciTech do something like this 
> already?  Perhaps we can steal their API...

I'm not sure about all of this.  It's probably best to view GL as it was 
intended - as a hardware abstraction.  If you want a hardware abstraction, 
that's what GL is for.  If there are bits of hardware functionality missing, 
it's easy to add them.

> 
>>I'm working on standalone mesa. This brings up the OpenGL API with having
>>Xfree86 around. I'm currently bogged down trying to break 10,000 lines of
>>mode setting/EDID code out of Xfree86 and making it work standalone. I have
>>it compiling now but it doesn't work yet.
> 
> 
> That's cool; having it available in user-mode might be nice for 
> environments that can't fix the kernel for some reason.
> 
> 
>>BenH has been going the other route and building the mode setting/EDID code
>>into the framebuffer driver. He started before I did so he is further
>>along. His driver handles most LCDs but laptop support is not finished.
> 
> 
> If fbdev and DRI could get along nicely, this might be a better solution 
> in the long run.  There are things about ACPI which make kernel support 
> for device configuration more than just a good idea.
> 

I wouldn't be suprised to see this happening - there's been a little 
discussion about it already.

Keith