EGL_MESA_screen_surface proposal

[Benjamin Herrenschmidt]

On Wed, 2005-03-16 at 17:32 -0500, Alex Deucher wrote:
> On Wed, 16 Mar 2005 17:28:03 -0500, Jon Smirl <jonsmirl at gmail.com> wrote:
> > On Wed, 16 Mar 2005 17:02:20 -0500, Adam Jackson <ajax at nwnk.net> wrote:
> > > On CRTs, the vsync pulse bleeds out of the monitor.  If you have a 72Hz
> > > monitor next to a 75Hz monitor you'll see a visible beat frequency.  If
> > > they're both 72Hz they'll act like a PLL and match frequency and the beat
> > > disappears.
> > 
> > That might be a case, but apps outside of EGL would have the same
> > problem. Wouldn't be better to edit /etc/fb.modes and just delete the
> > 75Hz mode?
> 
> what if you take away one of the monitors and want to run at 75Hz on
> the remaining one without restarting?  Why not allow the option?

Jon, I don't understand. On one side, you talk about beeing able to
propose nice GUIs to the user, and on the other, you takl about having
to edit /etc/fb.modes ... People are quite used to deal with the refresh
rate (ok, maybe not all the secretaries, but it's still a common thing,
even Windows and MacOS give you access to that in their front end, I
think that should be part of the API).

I think that the mode setting API should be able to handle everything
that has a user impact. That does not include tweakign the low level
timing details, but that definitely includes things like what mode is
native to the panel, the v refresh rate, eventually the scaling used on
flat panels, the TV standard, etc... 

There is a difference between having access to all attributes and beeing
forced to deal with all attributes too. I like Brian's API where you
just provide a criteria with only some attributes enforced for a search,
and it will return a list that match them. The rest is just a matter for
you to decide wether you want to deal with them.

I think though that mode names should be available for the sake of GUIs.

Ben.