EGL_MESA_screen_surface version 4

[Jon Smirl]

On Thu, 24 Mar 2005 09:49:25 +1100, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> > My alternative solution is to remove EGL_INTERLACE, EGL_REFRESH,
> > EGL_OPTIMAL. The lower layers which know the display technology would
> > instead be responsible for returning a mode list that is sorted
> > correctly for the display.
> 
> Didn't we argue again and again that the lower layers are sometimes
> wrong because monitors lie ?

Lying monitors would be dealt with at the lower layers. That's the
point of a fbdev mode list change event being kicked out to user
space. That gives the user space app a chance to read a /etc/file and
adjust the mode list to add/delete modes and fix wrong ones. My
assumption is that mode info presented to EGL is assumed to be true.
This also means that editing the available mode list only happens in a
single place (fbdev) for all video users.

> I would take a different approach here: I took 3 major 3D games running
> in MacOS X and look at what setting they provide: mode and refresh rate.
> 
> I think people are used to adjust the refresh rate, and I think we
> should keep it separate because of that. There may be other reasons too:
> cards with limited bandwith, people may want to lower the rate for
> increasing the bandwidth available to the accel engine, etc...

You can still change the refresh rate, either by cycling through the
modes with a hot key or by picking a mode by name. What is the API the
games are using to get a list of valid refresh rates? Is this an
artifact of the API the games have to work with?

> > When finished I would expect things to work like this: when the
> > desktop boots it pick the highest resolution and the first mode from
> > the list. The user can then interact with the list of mode names and
> > choose a lower resolution and different refesh, etc if desired. The
> > desktop would remember this and set the mode by name next time.
> 
> This API is _not_ suitable for use by a desktop system by XGl. It lacks
> far too many things for that. It's suitable for use by things like
> games, imho. A desktop system needs a much more richer API that gives
> access  to arbitrary attributes exposed by the HW, to desktop geometry
> configuration, etc... etc...

I agree that there needs to be more readonly attributes like pixel
aspect ratio, LCD pixel order, etc. I wasn't addressing that problem.

> Also, as we discussed a while ago on a different place, I think that a
> proper full featured desktop API should be transactional.

I agree, a compatible surface should also be required as part of the
mode setting process. I wasn't addressing this either.

-- 
Jon Smirl
jonsmirl at gmail.com