EGL_MESA_screen_surface version 4

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Mar 24 13:31:20 PST 2005


On Thu, 2005-03-24 at 11:25 -0500, Michel Danzer wrote:
> On Thu, 2005-03-24 at 09:42 +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-03-23 at 12:08 -0500, Michel Danzer wrote:
> > 
> > > I agree, but I think it should be made clear that the mode names are
> > > implementation specific, subject to change and don't have any meaning
> > > beyond being unique for each mode. Applications should never try to
> > > identify modes by name.
> > 
> > I agree. However, there is one important distinction here: Do we allow
> > the API to return 2 modes that are overall identical except that they
> > have different names ?
> 
> I think we should not because modes should only be selected via
> attributes.

Well, if we do not, then we _have_ to keep the refresh rate attribute,
and Jon point is moot :)

> > If we do, that opens the door for HW that has some important "features"
> > that aren't exposed here to expose them via this API. An example is TV
> > Out, the HW driver could expose modes with "PAL" or "NTSC" in the mode
> > name (ok, well, I admit, in this case, they are likely to have different
> > resolution, but my point still stands in the generic case). Another 
> > example is the type of scaling for a non-native LCD mode (preserve 
> > aspect ratio or fully stretched).
> 
> Anything that can be used by applications to identify and/or select
> modes should be an attribute in this or another extension IMHO.

The above isn't supposed to be used by an application. In my example,
those would be in the mode string presented to the user. But I agree
this is dodgy.

I just wanted to make the point clear.

Ben.




More information about the dri-egl mailing list