Xgl page - http://www.freedesktop.org/Software/Xgl

[Adam Jackson]

On Tuesday 01 March 2005 01:32, Benjamin Herrenschmidt wrote:
> On Mon, 2005-02-28 at 00:52 -0500, Adam Jackson wrote:
> > On Monday 28 February 2005 00:49, Rogelio Serrano wrote:
> > > On Mon, 28 Feb 2005 00:41:30 -0500, Adam Jackson <ajax at nwnk.net> wrote:
> > > > Quite a bit of work stands between where we are now and being able to
> > > > run Xgl standalone.  The goal is to do this work in a vendor-neutral
> > > > manner so that people will be able to run Xgl standalone no matter
> > > > what their driver or video card.  In particular DRI is not going to
> > > > be a requirement here; it would be extremely foolish to require DRI,
> > > > since at least two vendors have non-DRI GL stacks.
> > >
> > > How do we do that? I think i have to start looking at nvidia binary
> > > drivers and find out.
> >
> > We define a sensible API with the cooperation of nVidia and the other
> > closed driver suppliers.  They do read this list, you know.
>
> That would be yet-another new "sensible" API ? We are trying to define
> something around a common base that involves DRI and proper kernel
> interfaces. Yet another API just for Xgl doesn't seem like a good
> idea...

It's not "yet another" because the functionality we want (mode setting in 
particular) does not _have_ a common API.  And once again please don't 
suggest that Xgl is a DRI-only server.

I'm thinking that we expose this functionality through a (not yet written) EGL 
extension.  Horribly incomplete example:

typedef EGLBoolean (*eglSetModeExtProc)(EGLint x, EGLint y, EGLint vhz);
eglSetModeExtProc setmode = eglGetProcAddress("eglSetModeEXT");
setmode(1024, 768, 72);

Mesa would implement this through some common modeset library that throws 
requests at the kernel for sane OSes or handles them in userspace for 
braindead ones.  nVidia would handle them however they want inside their 
magic binary blob.

The point is that this is useful functionality for more than just X on GL, and 
that defining it as an extension to an accepted standard (EGL) _greatly_ 
increases the chances that closed driver vendors will support it.  It is not 
"yet another" API because that would imply that this functionality already 
exists in some well-supported configuration and that we're just ignoring it.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20050301/162bab26/attachment.pgp>