EGL_MESA_screen_surface version 2

[Benjamin Herrenschmidt]

On Thu, 2005-03-17 at 07:48 -0700, Brian Paul wrote:

> That's outside the scope of the EGL API.  An X server would have that 
> info in its config file.  Other applications could read the info from 
> another config file.  Some applications might even allow configurating 
> that on-screen with a GUI.

That mean we'll probably end up with no consistent mecanism though...
Thing is, I'm afraid in practice, people won't want to deal with 2 APIs,
so if they start using EGL API for mode setting, they'll only use that,
and everything not covered by it will not be handled at all, or in
inconsistent ways ...

> > That's a way to workaround the lack of 'Native' attribute, but I would
> > still prefer having one. If not, we could go that way, but then, it
> > would be nice to have an eglCompareModes() to compare 2 modes and check
> > wether they are identical.
> > 
> > The client could compare all attributes, but that would break if a
> > future extension to the spec adds more attributes.
> 
> Well, that's been a potential risk with GLX configurations, but I 
> don't recall that being much of a problem over the past 12 years or so.

Maybe ... 
> 
> > I think we should
> > really design the API so that the attributes set cna be extended as it's
> > the most debated thing at the moment and the most likely to need changes
> > in the future imho.
> 
> The API already supportes such extensions.

> I suggest you outline another EGL extension layered upon 
> EGL_screen_surface which supports those attributes.  It's much better 
> to have something concrete to read and comment on than to just toss 
> out ideas.

Another extension ? Why not make this one rich enough ? Hrm, I have no
experience with GL/EGL/GLX so I'm not too familiar with the "rules" for
defining extensions, but I'm familiar with video drivers and issues
around "mode setting". I'm trying to help here providing feedback on
what users of this API will likely want...

> > So that is the one doing the HW mode setting right ? I would suggest an
> > additional one eglValidateSurfaceMESA() then, that would do everything
> > but actually applying it to the HW. It is not guaranteed that a success
> > from validate means a success from a further eglShowSurfaceMESA (and
> > unexpected error may occur, or some other card resource may have been
> > stolen in the meantime), but again, that would help providing the user
> > with a more consistent choice by letting the client check which, for
> > example, bit depth (part of the surface no ?) can be used with a given
> > mode.
> 
> But if the result of eglValidateSurfaceMESA() says nothing about the 
> possible outcome of future eglShowSurfaceMESA() calls, is it really of 
> any use?

It guarantees that if it fails, eglShowSurfaceMESA will too. It allows
quick validation of configs (which is useful for the GUI, you can "gray
out" wrong choices for example etc...). eglShowSurfaceMESA might still
fail due to various error conditions or races, but it's unlikely

> >>        Name                      Description
> >>        ------------------------  ------------------------------------------
> >>        EGL_SCREEN_X_ORIGIN_MESA  X origin of surface with respect to screen
> >>        EGL_SCREEN_Y_ORIGIN_MESA  Y origin of surface with respect to screen
> >>
> >>    Any other token will generate the error EGL_BAD_ATTRIBUTE.
> >>
> >>    The origin parameters are significant when the screen's width/height
> >>    is less than the surface's width/height.
> >>
> >>    Valid values for X are in [0, surfaceWidth - screenWidth - 1]
> >>    Valid values for Y are in [0, surfaceHeight - screenHeight - 1]
> > 
> > 
> > I would add the DPMS states (power management/blanking) here.
> 
> I have no idea what that all entails.  How about writing a spec proposal?

I wonder if we need the full VESA states exposed or just something like
0: unblank, 1: normal blank (sync's on), 2: poweroff.
The VESA states allow to separately turn off hsync and vsync but I have
never found any use of that in practice.

        EGL_SCREEN_BLANK_STATE  Blanking state of the screen, value can
                                be :
                                 0 : Unblank
                                 1 : Normal blanking (no display, syncs
                                     on)
                                 2 : Power down (sync's off)

> 
> 
> >>    EGLBoolean eglQueryDisplayMESA(EGLDisplay dpy, EGLint screen_number,
> >>                                   EGLint attrib, EGLint *value)
> >>
> >>    Used to query display parameters.  <attrib> may be one of the following:
> >>
> >>        Name                Return value description
> >>        ------------------  ---------------------------------------------
> >>        EGL_NUM_SCREENS     Number of screens associated with the display
> > 
> > 
> > Ok, here, I have a problem (but it's not your fault) :) I'm not sur what
> > exactly an EGLDisplay is. Does it represent the global system
> > environment ? A specific video card ?
> 
> It's roughly like an X Display.  It basically corresponds to a single 
> card.  The key thing is that all EGLSurfaces and EGLContexts created 
> with respect to a particular EGLDisplay can potentially be used with 
> any screen associated with the EGLDisplay.  Conversely, EGLSurfaces 
> and EGLContexts can't be shared by different EGLDisplays.  I believe 
> the EGL specification covers this.

I just "jumped in" this discussion after others told me about it since I
was working on the mode settings issues, I have no experience of GL at
all and don't know EGL, but I'll have a look at the spec.
 
> I think a lot of people have been commenting on this extension without 
> having read the EGL 1.1 specification first.  Please read the EGL spec 
> first so we don't have to re-explain all that stuff here.

True.

> In particular, the new EGLMode stuff is very similar to the EGLConfig 
> mechanism.  One of the goals of this specification is consistency with 
> the rest of EGL.
> 
> 
> >>    EGLBoolean eglQueryScreenMESA(EGLDisplay dpy, EGLint screen_number,
> >>                                  EGLint attrib, EGLint *value);
> >>
> >>    Used to query screen attributes.  <attrib> may be one of the following:
> >>
> >>        Name                      Return value description
> >>        ------------------------  ---------------------------------------------
> >>        EGL_SCREEN_X_ORIGIN_MESA  X origin of surface with respect to screen
> >>        EGL_SCREEN_Y_ORIGIN_MESA  Y origin of surface with respect to screen
> >>        EGL_PHYSICAL_WIDTH_MESA   Physical width of the screen in millimeters
> >>        EGL_PHYSICAL_HEIGHT_MESA  Physical height of the screen in millimeters
> >>
> >>    Any other token will generate the error EGL_BAD_ATTRIBUTE.
> > 
> > 
> > What about native pixel width / height, technology (LCD, CRT, ...) may
> > affect choosing gama tables) and screen manufacturer/name, pixel
> > ordering on LCD (for proper subpixel rendering of text), plus a few
> > others I'm forgetting now. Are you open to extending the above list ?
> 
> Feel free to write additional specification language to cover those 
> things.  I never said I'd be able to do all this myself.

Okay, I'll first read the EGL spec though ;)

Ben.