Native surface creation

[Brian Paul]

Jon Smirl wrote:
> 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?

There could be all kinds of EGL applications (from X servers to games) 
so it's hard to say what kind of system would be used to select the 
display mode.  It's not important to what we're trying to do now.


> 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.

If more than one EGL app is competing to set the display mode, perhaps 
the first app that's run will "win" and the rest are out of luck.

I'm not too concerned about this stuff right now.  We're just trying 
to come up with an API extension that's sufficiently expressive and 
flexible.


>>>>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.

I don't know exactly how stereo would be implemented (i.e. what 
combination of hw vs. sw would be needed).

In any case, the point of all this isn't really stereo, but 
consideration of other mode attributes that we might have to be 
concerned with.  Other examples might be interlacing or syncing to 
external signals and the fact that the application may need to control 
those things to some degree.

-Brian