EGL_MESA_screen_surface version 4

[Benjamin Herrenschmidt]

On Wed, 2005-03-23 at 20:12 -0500, Jon Smirl wrote:
> 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.

Yes and I don't see the problem with that ...

> 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.

If we have EGL_OPTIMAL, ordering isn't significant, which I prefer.

> 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.

Because it's just plain wrong to ask users to edit a file in /etc, that
as simple as that... not even counting the problem of access permissions
etc...

Honestly, have you ever been faced to a user with a Mac or a Peecee
running Windows ? Can you imagine them editing config files ? I can tell
you though that a lot of them do understand what a refresh rate is...

> 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.

Why are you trying to ABSOLUTELY have the last word on this issue ? It's
not like having the refresh rate as an attribute will increase green
house effect or world hunger .... There is a pretty good consensus that
we could just leave the refresh rate as an attribute, it's fairly common
practice and I see no problem with that. Let's just do it and let that
thread die, it's becoming obnoxious.

> 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.

Whatever would b e that extended API, it will need more than just
retreiving additional attributes, like setting up the desktop layout,
but yes, let's keep all that complication to something separate. In the
meantime, I still vote for keeping the refresh rate in.

Ben.