Re: xserver on OpenGL

Otto Solares <[email protected]> wrote:

> > > Does your API handles mode settings? via EDID/fixed info? outside X.
> > 
> > Yes on all counts. You can even create custom display modes that show up
> > in the mode list if you wish, and the CRTC timings are automatically
> > created based on the VESA GTF formula. It is also possible to use fixed
> > CRTC timings for fixed frequency monitors, but you need to do a bit of
> > hacking to make that work (some of our users wrote their own tools to
> > modify our CRTC database to make this work ;-).
> 
> Currently linux-solo in Mesa-newtree is a good way to have
> accelerated 3D outside X but it uses fbdev as it managing API (mode
> settings, palette, etc.) and in reality is a pain.  If you could
> donate a new managing API for linux-solo in an OSL that would be a
> good start.  That could be a good foundation for an OpenGL backend
> for xserver and for others projects like mine. Just my opinion. 

Well we have effectively done that, and we just finished the first beta 
of the GPL DDK today (ie: allowing others to build SNAP drivers if they 
want). The OpenGL support at present is completely software only, but it 
is fully integrated with SNAP which is a huge plus. Ie: you could use 
this to start working on seeing how X and map to OpenGL without having to 
deal with mode setting etc, today. Sure it would only be software at 
present, but it would *work*. Plus it will enable full hardware 2D 
functionality to be implemented in the X server, so the server could use 
all the existing 2D services for hardware fills and scrolls, making the 
server just as fast a native XFree86 server is today. Getting it all 
working would really only take a few days.

As for hardware support, now that the DDK is finally done I can go back 
to working on porting the Radeon R200 DRI driver to SNAP. I am confident 
we can have this working on DOS/OS2 and Linux within a few weeks. Also 
that code will be Open Source and included in the DDK since it was Open 
Source to begin with.

There are caveats of course. Most of the driver binaries are closed 
source, due to NDA restrictions with vendors and of course because we 
sell them. Our primary goal is to sell these drivers to enterprise and 
embedded customers, hardware vendors and not end users. For that reason 
we have a project in the works such that in a few months end users will 
be able to log into our web site and custom configure a SNAP driver for 
their hardware and download it free for personal use.

If the goal of the project is to enable a full featured X server that 
uses OpenGL for the back end 3D with the intention that hardware vendors 
can eventually write drivers for this, then SNAP would help get to that 
goal more quickly. If the goal is to do this completely free and you want 
everything to be Open Source, then I guess we will just end up doing this 
on our own.

Also we are considering the options of making the SciTech SNAP driver 
architecture an industry standard. Perhaps a new VESA standard (after all 
it was based on my original work with VESA/AF 2.0 that never got ratified 
by VESA), or some other industry standard.

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! ~