EGL_MESA_screen_surface version 4

[Jon Smirl]

On Thu, 24 Mar 2005 10:54:45 +1100, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> 
> > 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.
> 
> Will not work in practice. /etc/blah won't have nowledge of all lying
> monitors on the planet any time soon. Again, let's follow the common
> usage here, which is to expose the refresh rate.

Exposing the refresh rate means we now have to mark modes with
EGL_OPTIMAL since selecting the highest refresh rate is not the
optimal choice for an LCD. It also means EGL should not sort on
refresh since that will order the lists incorrectly for LCDs. I would
like to make sure that the first mode in the list is always what the
lower layer thinks is the optimal mode.

I also don't see that if the user has the knowledge to adjust for a
lying monitor at the EGL layer why they wouldn't have the knowledge to
adjust the mode file in /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?
> 
> Why ? nothing prevent them from putting it in the mode list, and some
> do. But some don't ... Also, there is at least one good reason to know
> the refresh rate. I suspect some smart applications can very well
> balance they processing time / screen update frequency based on the
> refresh rate.

How about if the modes just report refresh/optimal but EGL does not
sort on them? That way the underlying layer can have a chance at
providing a properly ordered list.

My preference would be for the modes to have no attibutes except
name/width/height. Then provide an extension API for retrieving all of
the detailed information about the mode. Full mode info has a lot more
attributes than just refresh/optimal.

-- 
Jon Smirl
jonsmirl at gmail.com