EGL_MESA_screen_surface version 4
mhopf at suse.de
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
> > 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 suse.de> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat at mshopf.de
Phone +49-911-74053-715 __) |_| __) |__ labs www.mshopf.de
More information about the dri-egl