EGL_MESA_screen_surface version 4

Matthias Hopf mhopf at suse.de
Wed Apr 6 08:24:11 PDT 2005


Hi Brian,

On Mar 23, 05 08:19:13 -0700, Brian Paul wrote:
> Here's the next version.  My DSL connection was out for a few days so 
> I've been sitting on this since Saturday and it might not incorporate 
> recent discussion.

I've just finished reading thoroghly through the extensions and I really
like it.  However, I have a number of remarks / questions:

>     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?
IMHO it is a convenience function for eglGetModesMESA(), because you
should be able to reimplement it easily in user land. At least that's
what eglChooseConfig() is to eglGetConfigs().

>     EGLBoolean eglQueryDisplayMESA(EGLDisplay dpy, EGLint screen_number,
>                                    EGLint attrib, EGLint *value)

This is the other way round. No need for a screen_number.

>     EGLBoolean eglQueryScreenMESA(EGLDisplay dpy, EGLint screen_number,
>                                   EGLint attrib, EGLint *value);

>         EGL_PHYSICAL_SIZE_MESA    Physical width and height of the screen
>                                   in millimeters

Shall we include for the physical size something like
"If the physical dimensions of the screen are unknown, [0, 0] is
returned."


I suggest something like a

const char *eglQueryScreenStringMESA(EGLDisplay dpy, EGLint screen_number)

in order to have something to identify the screens. On a practical point
of view, asking the user about which screen to use could be easier, if
the connection type or monitor description could be available.

Of course, this could be something for an additional extension as well.
The longer I think about it, the more this actually makes sense to me.


There are some more issues that bother me right now:

- What shall we do with screens, for which a output port exists, but no
  monitor is attached? We cannot simply ignore it, because it could be a
  monitor attached by BNC cables without DDC channel, or an old model
  that does not speak DDC.
  In fact, we don't have any knowledge about connected hardware right
  now, this is something we have to keep in mind for a future extension.
  We don't have something like a default or 'main' screen number right
  now as well.

- 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:

- 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.


Thanks

Matthias

-- 
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 mailing list