EGL_MESA_screen_surface version 5

Jim Gettys Jim.Gettys at hp.com
Fri Apr 22 16:59:28 PDT 2005


The new generation of PCI interfaces are hotpluggable, as are Cardbus
and PCMCIA, and there have been displays on such cards for years (and
I've used them on the iPAQ handheld running Linux).

And when we have remote displays that might want to become part of an X
server, they can come and go as well.

*Everything* should now be designed to be dynamic.  This is not to say
we have to have a dynamic implementation on day 1; just that the design
should not get in the way of implementation...
			- Jim

On Fri, 2005-04-22 at 17:34 -0400, Adam Jackson wrote:
> On Friday 22 April 2005 16:48, Jon Smirl wrote:
> > Screens on Linux are hotplug today.
> 
> I'm not sure that's strictly true.  Displays are hotplug, in that I can pop in 
> a usb gadget at any time.  Screens aren't, there's a fixed number of CRTCs 
> attached to each GPU.
> 
> > While right now we may not want to 
> > build the egl mechanism for tracking add/remove we should at least
> > make the screen handle opaque and have an iterator function. People
> > should not be writing code that says how many screens do I have now
> > let's allocate a static array to hold them. And they shouldn't be
> > writing loops assuming incrementing integer screen numbers.
> 
> You can't have a static array, because you can't query EGL_SCREEN_COUNT_MESA 
> at compile time.  You have to do it at runtime.  And you probably have 
> additional context you want to bind to each screen, so you want a structure 
> anyway, so you can design ahead and make it a linked list instead of a 
> dynamically sized array.  And if you do so then your loop walks your linked 
> list rather than counting up by screen numbers.
> 
> That we have discussed the possibility of hotplug screens here (and will 
> probably note it in the spec) means anyone who doesn't plan for it is making 
> a conscious decision to make their life harder in the future.
> 
> > We 
> > definitely need error returns from all functions saying that the
> > screen has gone missing.
> 
> EGL_BAD_SCREEN_MESA exists.  All we need to do _now_ is say that it can be 
> thrown at any time.  However see below...
> 
> > Doing it this way will let us transparently add code later that
> > actually add/removes screen. I don't think changes along these lines
> > will impact low end devices. And if we don't do them we're going to
> > get code written that will break when a screen disappears.
> 
> The authors of that code have decided to make their lives hard.  Even if you 
> have an iterator, nothing stops you from iterating over every screen up 
> front, allocating your screen array, and not ever touching it again.  We can 
> not prevent people from writing broken code.  I don't think we can even make 
> it hard.
> 
> > Another area is monitor hotplug. I have code that supports this ready
> > to go into fbdev as soon as we can get some interrupt handling issues
> > sorted out. Apps need to deal with an error saying something like mode
> > context lost, choose a new one.
> 
> Hrm.  EGL_BAD_MODE_MESA would be appropriate, but you can only generate EGL 
> errors from EGL calls.  Perhaps we need to say that the app needs to call 
> eglQuerySomethingMESA every so often to catch this.
> 
> - ajax
> _______________________________________________
> dri-egl mailing list
> dri-egl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-egl



More information about the dri-egl mailing list