Native surface creation

[Brian Paul]

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.


>>Right now bit_per_pixel is independent of modes. I will probably
>>eliminate the bpp variable and combine it into the mode name. Doing
>>that allow the case of cards that don't have the DAC bandwidth to
>>display high color depths at their highest resolution. If the combined
>>bandwidth is too high for the monitor the mode will disappear.
> 
> 
> Yes, depth needs to be part of the resolution specification.

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?


>>Buffer management will still need coordination. Right now fbdev will
>>put one at each end of memory for dual heads.
> 
> 
> This is yet another area that the unified DRM memory manager should address.  
> Mode set should only reserve the front buffer space, and everything else 
> should be allocated on the fly based on the needs of each context.

I think buffer memory allocation should be separate from mode setting. 
  See my other posting.


>>Do this look like what EGL needs? Hopefully I can get this finished in
>>a few weeks and get back to working on DRM/mesa.
> 
> 
> Yes, this looks like it gives us all the information and control we need.
> 
> 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.

-Brian