Native surface creation

[Alex Deucher]

On Fri, 11 Mar 2005 14:56:22 -0700, Brian Paul
<brian.paul at tungstengraphics.com> wrote:
> Adam Jackson wrote:
> > On Friday 11 March 2005 16:03, Brian Paul wrote:
> >
> >>Adam Jackson wrote:
> >>
> >>>On Friday 11 March 2005 15:06, Jon Smirl wrote:
> >>>
> >>>>If mode is changed this will generate a hal/dbus event but that isn't
> >>>>implemented yet. Same if the list of modes changes via monitor
> >>>>hotplug.
> >>>
> >>>Mode change is something I haven't thought through completely yet.  GL
> >>>doesn't really have a way to send notifications up to the app
> >>>asynchronously, though EGL does give us a "context lost" error condition
> >>>that can trigger at any time that might be good enough...
> >>>
> >>>I really hesitate to be the guy that adds the first callback to GL
> >>>though.
> >>
> >>Do you think that a simple query mechanism would suffice?  That is,
> >>the app would have to ask "has there been a mode change" every once in
> >>a while.  When a mode change occurs, rendering could be undefined
> >>until the application responds to it.
> >>
> >>I think that's basically how the 'context lost' thing works.
> >
> >
> > As I read it, any op on an EGLContext is allowed to fail with
> > EGL_CONTEXT_LOST.  You know when this happens immediately because the Context
> > op returns EGL_FALSE.  This isn't quite the same as polling with a query
> > function.
> >
> > Generating a screen clobber event would presumably work the same way, assuming
> > screens are a type of EGLSurface.  The issue is notifying the driver of this
> > somehow.  Flag in the sarea would work, I suppose.  The other way would be
> > generating a dbus event and having the server know that that means "oh dear,
> > time to reconfigure the world".
> >
> > They're not mutually exclusive approaches.
> >
> >
> >>Width, height, depth and refresh frequency are the obvious parameters.
> >>  What else is there?  I know there's there's other more complicated
> >>dotclock and timing parameters, but how much of that really has to be
> >>exposed through a programming API?
> >
> >
> > I would argue that none of it should be exposed, given a sufficiently capable
> > modeset layer.  One thing I do like about the current Xorg mode setting is
> > the ability to do weirdo resolutions and refreshes like 1184x888 at 77Hz.  Stock
> > VESA modes are boring and often wrong for new devices, we get a lot of bugs
> > from people with 1280x800 laptops for example.
> >
> >
> >>>The problem remains of querying the supported modes in a portable
> >>>fashion.  In theory we can wedge this into the fbconfig, but that's
> >>>adding another three dimensions to the fbconfig space which means your
> >>>fbconfig list grows by about a factor of 8.  Which may be fine, but it
> >>>makes eglinfo output reeeally long.
> >>
> >>I wouldn't burdon the EGLConfig mechanism with display modes.  A
> >>similar, orthogonal mechanism could be made for that.  Do you think
> >>it's appropriate to have a mechanism that can enumerate all possible
> >>display modes?  That might not even be possible.
> >>
> >>Alternately, a really simple interface would be a function which took
> >>a user-requested width/height/depth/frequency/etc and returned the
> >>best possible match supported by the hardware.  That could be a handy
> >>function in any case, I bet.
> >
> >
> > Sure, and then pass that in to the eglCreateScreenSurfaceXXX.
> 
> Actually, no.
> 
> We may want to create one screen surface, but display it in several
> different modes.  Suppose we wanted to support X's Ctrl/Alt/+ and
> Ctrl/Alt/- mechanism to change display resolutions on the fly.  One
> screen surface, but different display modes.  Therefore, passing the
> mode info to eglCreateScreenSurfaceXXX() wouldn't be appropriate.

we may also want to have that same surface scanned out to multiple
outputs (crt and tv, LCD and crt, etc.).  you may also want variations
on that too, like different refresh rates or resoultions on each
output.  so you may have you lcd looking at a surface at 1024x768 at 60hz
and you may want your crt zoomed in on a subsection of that same
surfarce at 640x480 at 85hz.

Alex