Re: xserver on OpenGL

Keith Whitwell <keith-CdwZJljFklH+2FeEXyspIVaTQe2KTcn/@public.gmane.org> wrote:

> > My offer still stands to help work on this using the SciTech SNAP driver
> > architecture. We already have a complete OpenGL driver architecture
> > working on Linux console modes independantly of X (software right now,
> > but we are working on bringing up the Radeon hw driver based on the DRI
> > code). It would be real easy to add pbuffer support to our
> > implementation, but it would not really be necessary until you need to
> > use an offscreen buffer as a texture surface for a blending operation.
> 
> We've got a hardware one running right now - the linux-solo
> targets in Mesa, which already bring up 3D based on the radeon (and
> other) DRI drivers. 
> 
> So this task would probably turn out looking pretty similar
> whether we based it off your driver architecture or linux-solo - at
> least it seems that way based on your description.  Sounds like
> maybe you're ahead on mode setting, whereas we're ahead on hardware
> support... 

Yes, ahead on hardware support but you don't yet have all the pieces in 
place to be able to handle managing offscreen buffers in a clean fashion 
and linking them with the OpenGL drivers. Still, I see your point so I 
will get back to you guys again on this once we have the ATI Radeon 
driver going.

As I also mentioned to Jon via private email, although the base level 
2D/init driver for our ATI Radeon support is closed source, the 3D driver 
we are working on is based on DRI and will remain open source. 

> I'm really more concerned about finding the easiest environment to
> tackle the narrow task of emitting GL as to perform the rendering
> tasks of a DDX driver - and to a fairly large extent, the stable
> nature of a nested X server is pretty appealing. 

Makes sense.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~