EGL_MESA_screen_surface proposal

[Benjamin Herrenschmidt]

On Wed, 2005-03-16 at 20:58 -0500, Jon Smirl wrote:

> Picking either end of the spectrum is fine with me, it's picking
> something in the middle that I'm having trouble with. How do you
> determine what are the important attributes, and who are they
> important to? Once you pick the set how does EGL know how to rank
> them?

With common sense ? What are people mostly used to deal with ? What
other OSes provide ? Heh...

Width, Height, Refresh, and Depth is the basic set, I think everybody
but you agree on that.

I would personally add a few but they can be debated:

 - Native: Which is the native mode of the display. This is useful for
apps to pick the right one by default among others. (This is only
informational, can't be changed, maybe can be separated from other
"attributes" ?)

 - Scaling type: Wether the mode conserves the aspect ratio or is fully
scaled to the display surface (means it's effective H and V resolutions
are of different DPIs). For example, on my 1920x1200 panel, I can
display 1024x768 either has a square with correct aspect ratio (same H
and V scaling, it will fill the screen vertically and will have black
margins on left and right) or I can do full scaling, that is stretch it
to both left and right edges, but in this case, pixels will be "flat",
that is wider than tall.

 - TV standard (PAL, SECAM, NTSC, ...)

 - DPI (Same note as for "Native", read only attribute for use by
software do render better).

Note that there may be more HW dependent _and_ important ones. That's
what annoys me a bit. I suppose those could be put in a richer library
that is separate or layered below EGL, but that means EGL need to be
able to adapt to mode changes triggered from the outside (that is beeing
notified by it's own backend that the mode changed).

For example, I may have 2 TV outputs (composite and S) exclusive on my
card. How do I choose which one to use ? That could be encoded in the
mode (in which case, the "mode string" would allow the driver to propose
both to the user via the API, without EGL havign to "know" about the
actual details) or we could define a generic mecanism for the driver to
add attributes and provide their names. Finally, we could just say, EGL
don't deal with it, but whatever local system API it's based on can, but
we come to my above point of needed to be able to notify EGL that the
mode is changing (steal the engine, stopit, change mode, reset it,
etc...)

Ben.