Native surface creation

[Jon Smirl]

On Fri, 11 Mar 2005 16:58:43 -0700, Brian Paul
<brian.paul at tungstengraphics.com> wrote:
> > They are just human readable strings. You could name the mode orange.
> > After the mode is set you can query all of the details with an ioctl.
> 
> Can you query a mode's details without actually setting that mode first?
> 
> If we're going to extend the EGL API with an EGLMode type and we
> provide a function to query the available EGLModes, we'll need a way
> to query all the attributes of the mode names from in the EGL library
> (without setting them first).
> 
> Just in case we haven't been totally clear yet, we're trying to extend
> the EGL API so that applications can use the EGL API alone to setup a
> display/screen/framebuffer.
> 
> An EGL application shouldn't have to read /etc/fb.modes or call
> ioctl().  The EGL library and/or drivers would do that stuff.

Should the EGL API try to take things like resolution and depth and
try to find a matching mode, or should it display a list of available
modes in a drop down and let the user do the match in their head?

I was trying to hide the problem where different apps all set
1280x1024 and then set different margins around the image making it
jump from place to place when you change apps. All the modes are
1280x1024 but they are all using different details. By picking the
mode by name you lose the ability to set the details on a per app
basis.


> 
> 
> >>Suppose I want to do active stereo (i.e. alternate display of
> >>left/right color buffers in sync with LCD glasses).  How would I name
> >>a mode that supported stereo?
> >>
> >>At the EGL API level, we'd probably have an opaque EGLMode handle and
> >>a function for querying the mode's attributes (ala
> >>eglGetConfigAttrib), another function for querying the available
> >>modes, etc.
> >>
> >>That's not in conflict with what you're doing, of course.  The
> >>translation would be done in the EGL library.
> >>
> >>
> >>
> >>>As for picking the mode, why bother with the closest match function.
> >>>Why not just give them a list of mode names and let them pick?
> >>
> >>Well, either the user writes a search function or we offer one in the
> >>EGL API.  I think a mode picking function similar to eglChooseConfig()
> >>  would be most consistent
> >
> >
> > There is already a search function in fbdev but it is not exposed in
> > an ioctl. What is a case where executing an app should force a mode
> > change that isn't under user control?
> 
> I'm not sure I understand your question.
> 
> I'm not saying I want to be able to set an arbitrary new mode like
> 942x707 at 55Hz with an EGL call.  I just want to be able to use/set any
> available mode (from a pre-defined list) with an EGL call.
> 
> Let me lay out a concrete usage scenario.  Suppose I want to write a
> flight simulator using the EGL API.  I want to query the available
> display modes to see if stereo is supported.  I also want to provide a
> keyboard option in the simulator to turn stereo on/off on the fly.
> Therefore, I need to be able to change the display between stereo and
> non-stereo modes.
> 
> Or, perhaps I want to be able to try several different display
> resolutions during simulator start-up to find the one which I can
> render at a reliable 60Hz.  I may try 1600x1200 first, then 1280x1024,
> then finally 1024x768.  Those modes would all be in the list
> predefined modes.
> 
> Does any of that conflict with your ideas?

None of the fbdev drivers implement stereo so there is nothing to
compare to. How is stero implemented, is it in hardware or software?

In software you would just pick a normal mode and then on vertical
retrace change between buffers and pulse the glasses. The way I look
at it the monitor doesn't know stereo is happening so it is not part
of the video mode. Turning on stero would be a separate toggle
somewhere.

> 
> -Brian
> 


-- 
Jon Smirl
jonsmirl at gmail.com