EGL_MESA_screen_surface version 4

[Jon Smirl]

There is a difference between sending interlaced data to the card and
displaying a progressive buffer with an interlaced mode.  TV-OUT is an
example of the later. From the EGL perspective it doesn't care if the
buffer is being scanned out progressively or interlaced. On the other
hand, sending interlaced data to the card for display is a different
and much more complex problem. I don't think we should support sending
interlaced data to the card, but there is no reason to eliminate
interlaced scanout modes (TV-OUT) from a progressive buffer.

CRT displays typically care about refresh. Flat panels care the most
about optimal display.  I don't think features specific to a display
technology should be exposed in the EGL API so I would argue that none
of EGL_INTERLACE, EGL_REFRESH, EGL_OPTIMAL be included. However, I do
believe that the list of modes available at a given resolution should
contain all of the interlaced, refresh rates, optimal choices.

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.

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.

Doing this does not make any modes inaccessible, all I am doing is
removing the ability for EGL apps to sort the list. If an app really
does need to sort these modes it should use an extension that provides
detailed mode information.

How are these modes lists used? Only displays have modes and only
humans use displays. Humans like names not strings of numbers. An
alternative UI is the one X uses where keyboard commands cycle through
the available modes. It just doesn't make sense for an app to be coded
to look for a 67Hz refresh mode and set it -- my monitor doesn't have
a 67Hz refresh mode.

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.

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.

-- 
Jon Smirl
jonsmirl at gmail.com