EGL_MESA_screen_surface version 4

[Benjamin Herrenschmidt]

On Wed, 2005-03-23 at 11:46 -0500, Jon Smirl wrote:

> I am not proposing to remove interlace, refresh, optimal modes from
> EGL (this is different than the early proposal of one mode at each
> resolution).  What I am proposing is to remove the ability for EGL to
> sort on these attributes.
> 
> One basic problem is that CRTs and LCDs sort on the refresh rates in
> different orders. With a CRT faster is best. With an LCD optimal is
> best. If interlace, refresh, optimal are exposed as mode attributes
> then the EGL app needs to know the display technology in order to sort
> the list correctly. We would also need to add a way for EGL to
> determine the display technology.

I should indeed, and this includes a couple of things like the pixel
format on LCDs for subpixel rendering, and even eventually the optimal
gamma table of the display (along with functions for setting it).

Anyway, I plan to read the EGL spec this week-end and come up with a
proposal adding some of these things.

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

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

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

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

> If you run something like video or a game hard wired to a certain
> resolution, the display would switch to the new resolution and use the
> top mode from the list. If this isn't the best mode a desktop hot key
> would cycle through the other modes at the same resolution. The game
> probably doesn't have a UI for picking detailed modes so the cycling
> hot key is the best solution.
> 
-- 
Benjamin Herrenschmidt <benh at kernel.crashing.org>