Native surface creation

[Brian Paul]

Jon Smirl wrote:
> On Fri, 11 Mar 2005 15:48:48 -0700, Brian Paul
> <brian.paul at tungstengraphics.com> wrote:
> 
>>Jon Smirl wrote:
>>
>>>I'm trying to make sure that XGL doesn't have to run as root. This
>>>implies that you can't set an arbitrary mode. That's the purpose of
>>>the list of modes names that you can then copy to 'mode'.
>>>
>>>However, the list of mode name is created from a hotplug event that
>>>runs as root. Right now the user space app builds the list of names
>>>from EDID but it is intented to also merge in custom modes from
>>>/etc/fb.modes. So if you want 1184x888 at 77Hz add it to fb.modes and
>>>reload the fbdev driver. That will cause1184x888 at 77Hz to now appear in
>>>the mode list and a normal user can then select it.
>>
>>So "184x888 at 77Hz" is a concrete example of a mode name?  Will that
>>syntax be extensible?
> 
> 
> 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.


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

-Brian