EGL_MESA_screen_surface version 4

Matthias Hopf mhopf at
Thu Apr 7 07:05:16 PDT 2005

> >>   EGLBoolean eglChooseModeMESA(EGLDisplay dpy, const EGLint *attrib_list,
> >>                                EGLModeMESA *modes, EGLint modes_size,
> >>                                EGLint *num_modes)
> >
> >
> >Shouldn't that function include a EGLint screen_number?
> Yes, I already fixed that last week.

You didn't have a new version of the document published, or did I just miss
that? :)

> >  We don't have something like a default or 'main' screen number right
> >  now as well.
> I was thinking the 0th screen would be the primary or default screen.

I think this should be made clear in the text. Should be trivial to add.

> >- Especially laptops allow the routing of RAMDACs to different output
> >  transceivers - sometimes even one RAMDAC to several transceivers,
> >  sometimes you can change the output port.
> >  So we need some kind of selection mechanism, the screen_number is not
> >  enough to identify the output port. Except if we identify different
> >  output ports by different screen_numbers, but then we run into
> >  troubles by not knowing on which output port a monitor is connected,
> >  we cannot model the possibility of one RAMDAC connected to several
> >  transeivers, and the next issue gets worse:
> I guess I don't fully understand this issue.  Do you see this as a 
> critical issue that must be addressed now, or can we find a simple 
> solution for now and do something elaborate later?

I think it is critical to think about this right now. As far as I can
see we *can* address this issue with an additional extension, but I
might be wrong, so it would be great we think a little bit about it
before we set everything in stone.

Right now we have a 1:1 mapping of screens (i.e. RAMDACs, or scanned out
framebuffer regions) and output plugs. This doesn't work with Laptops,
neither does it with Graphics hardware with more than 2 outputs, e.g.
one VGA, one DVI, one TV, because typically these cards only have 2

We could defer this to an additional extension, which only allows to
select which output plugs will be active for a screen (there may be
multiple active at the same time, or only one, depending on the
hardware). This could be even incorporated into the more hardware
specific extension for screen/display information.

However, every application setting the video would have to take care of
this extension as well, and - even more important - the list of valid
modes for a screen very much depends on the active output plug. E.g.
with TV out activated for a screen typically reduces the maximum allowed
size to 1024x768, some chips restrict that to 50/60Hz interlaced, other
allow for 50/60Hz progressive scanning and the encoder chip selects the
right rows for output.

I know this is getting to specific for this extensions, but we should
think about having a 1:n relationship for screens to output plugs.

Personally I think we could defer this to another extension, with which
one could specify the output plugs active for a screen_number which in
turn would change the behavior of eglGetModesMESA() afterwards. This is
a valid approach, but something to be discussed.

> >- Can we run into the possibility, that we cannot eglShowSurfaceMESA() 
> >  for some screen_number, because, other screens are already shown? E.g.
> >  a graphics card has three transceivers, but only two RAMDACs, so if
> >  screen 0 and 1 are already shown, we cannot show screen 2.
> >  Currently I don't have a clue how to solve or even specify this.
> We'd probably just have to raise an error in this situation (at least 
> for the short term).

Guess so. EGL_BAD_ACCESS sounds just right for this.



Matthias Hopf <mhopf at>       __        __   __
Maxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat at
Phone +49-911-74053-715            __)  |_|  __)  |__  labs

More information about the dri-egl mailing list