Native surface creation

[Adam Jackson]

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.  Mirrors 
fbconfigs nicely.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dri-egl/attachments/20050311/dd1195b4/attachment.pgp