EGL_MESA_screen_surface proposal

[Brian Paul]

Jon Smirl wrote:
> On Wed, 16 Mar 2005 14:56:46 -0500, Alex Deucher <alexdeucher at gmail.com> wrote:
> 
>>>Then you'll know enough to go edit external config files to suppress
>>>the reporting of the progressive modes and make the interlaced one
>>>visible. Framebuffer has a mechanism to add/delete modes as reported
>>>by DDC. Just delete the progressive one that is obscuring the
>>>interlaced one and restart XGL.
>>
>>It'd be preferable to switch between the two with requiring a restart.
> 
> 
> I'm looking at this as we either expose all of the attributes or none
> of them. I don't think we should just pick a subset.
> 
> There are a lot of attributes on a mode:
> width, height, top, bottom, left, right, hslen, vslen, hsync+/-,
> vsync+/-, csync, extsync, interlace, detailed, etc
> 
> Because there are so many I'd prefer to expose none of them.

But those attributes vary _greatly_ in their importance to the EGL 
programmer.  I would care very much about the width, height, interlace 
and refresh parameters but don't care at all about the hslen, vlsen, etc.

I'd expect the the system to be configured with appropriate sync 
values such that I never have to care about them.  However, I'd want 
to be able to choose from various resolutions and refresh rates from 
within my application (I could re-use the flight-sim example here).

If in the future, someone comes along and says they need access to the 
various sync parameters from in an EGL application, we could easily 
write a new EGL extension (perhaps EGL_MESA_screen_details) that would 
expose those parameters.

Again, this would fall into the 5% category that I'd rather avoid for now.

-Brian