Native surface creation

[Brian Paul]

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.

When someone tries to actually show a screen surface with 
eglShowSurfaceXXX() we'd do some error checking to be sure that the 
surface is compatible with the current display mode and return an 
error code if there's a problem.  For example, if the dislay were set 
to do 16bpp and the surface were 32-bit RGBA we'd generate an error.


> Mirrors fbconfigs nicely.
> 
> - ajax