Current status of EGL spec

[Jon Smirl]

On 8/10/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
> Jon Smirl wrote:
> > I pretty have a working EGL implementation on radeon DRI now. The code
> > is checked into the mesa tree. Is it time to push the spec on to
> > khronos?
> 
> I haven't had time to finalize the spec.  There's still a number of
> open issues that should be addressed.
> 
> 
> > Some minor issues I had...
> >
> > 1) Would it make sense to eliminate modes and just add an attribute to
> > configs marking them as displayable? Something like EGL_SCREEN_BIT.
> 
> No.  Modes have the following attributes: width, height, refresh rate,
> interlaced.  It wouldn't be good to tie configs (pixel formats) to
> those attributes.  For example, you'd need separate pixel formats and
> rendering context to draw to two surfaces which only differed in width
> and height.
> 
> 
> > 2) Given eglQueryScreenSurfaceMESA and eglCreateScreenSurfaceMESA, for
> > symmetry should eglShowSurfaceMESA instead be
> > eglShowScreenSurfaceMESA?
> 
> That would be OK with me.
> 
> 
> > 3) Should eglScreenPositionMESA(EGLDisplay dpy, EGLScreenMESA screen,
> > EGLint x, EGLint y) instead use EGLint *x, EGLint *y. That would allow
> > hardwar
> 
> You got chopped off there, but I think I know what you're getting at
> (return the actual position in case 1-pixel positioning isn't supported).
> 
> First, OpenGL conventionally doesn't use in/out parameters like that.
>   Second, how common is it that hardware can't support 1-pixel
> positioning?  If it's not a common problem, I'd defer for a future
> extension which would allow you to query the positioning granularity.

We could add a GetScreenPosition call which would take care of this.
I'm not sure but it looks like the radeon hardware can only be
positioned in 8 bit increments. Can someone more familiar with the
hardware verify this?

-- 
Jon Smirl
jonsmirl at gmail.com