EGL_MESA_screen_surface version 4

[Brian Paul]

Matthias Hopf wrote:
> 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?

Yes, I already fixed that last week.


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

Correct.


>>    EGLBoolean eglQueryDisplayMESA(EGLDisplay dpy, EGLint screen_number,
>>                                   EGLint attrib, EGLint *value)
> 
> This is the other way round. No need for a screen_number.

Already fixed too.



>>    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'll add that to the issues list.


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

I think there'll eventually be a layered extension to expose more 
hardware details like that.



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

I was thinking the 0th screen would be the primary or default screen.


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


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

I'll post an updated spec in a bit...

-Brian