EGL_MESA_screen_surface proposal

Benjamin Herrenschmidt benh at kernel.crashing.org
Wed Mar 16 17:29:16 PST 2005


> Is it?  I remember video cards that could support 1024x768 with 24-bit 
> color but 1600x1200 only with 8-bit color.  Was that because of 
> limited DAC bandwidth or the limited amount of VRAM?

I think mode list and mode validation are two different things. Wether a
given setup is applicabls is "mode validation".

About the depth bit, one thing that Apple got right here actually was to
separate modes and depth in their initial API imho. You have modes, and
for modes, you have available depth. So you can easily validate what can
be done. In some case, it may even depend on what the other head is set
to.

In fact, in cases where setting a mode on one head may require affecting
an other, what would you do ? I don't suppose you expose that via EGL
API, but what I suggested for a mode setting API a while ago when
discussing with Keith on IRC was a transactional mecanism. You basically
requires a snapshot of the global configuration (sort-of XML thing that
contains the setup of all cards, heads, monitors & geometry infos,
available modes, etc...). You change this copy with various functions,
and then "submit" it. What will actually happen in HW is a "best try".
That is the driver may set something slightly different due to various
constraints or may just refuse the commit. You are then expected to
re-read the configuration and see what happened.

I wouldn't do something as complex I suppose for EGL, but I would at
least put clearly in the spec that doing a mode setting may not result
in that actual mode beeing reallly set. That is the user is expected to
re-query for the mode after setting it. The driver may have had to do
something else at the last minute due to whatever internal problem,
error, out of resource, etc...

Ben.




More information about the dri-egl mailing list