Mode setting & EGL

[Michel Danzer]

On Wed, 2005-03-16 at 14:32 +1100, Benjamin Herrenschmidt wrote:
> 
>  - Mode setting has an impact on data cached in fb memory. It can be
> (and will be) destructive. See the (long) thread going on on x.org &
> fbdev lists for details.

And I still completely disagree. :) If your design requires this, then
I'm afraid it's back to the drawing board. Look at Brian's
EGL_MESA_screen_surface draft for an IMHO saner design for the
interaction between mode setting and memory management.


> Also, it would be a non-sense to design that in a GL-only way. There
> will still be 2D-only setups for a while where things like XGl aren't an
> option, so we want a mode setting library/mecanism that is independant
> enough (though could be part of EGL). Maybe simply having an extension
> to allow a legacy 2D accelerated rendered to work inside a static EGL
> surface would fit that need ? Or maybe i just completely missed
> something and it's all already dealt with :)

I'm not sure, but this is about EGL. Nothing prevents EGL from using a
lower level library that exposes a similar interface to non-EGL clients
I guess.


>  - Mode setting requires arbitration with whoever uses the card, since
> that can be considered as a total reset of the engine. (in addition to
> possible loss of part or all of framebuffer memory content). That is,
> beore a mode change, the fbdev probably need to take the DRM lock,
> cancel pending commands, etc... make sure it's all quiescent, change the
> mode, make the DRM return appropriate errors to all userland clients
> (that is put a "context invalid" or whatever flag on each client so that
> their next ioctl fails). Especially if done by a separate library, EGL
> will "discover" that the mode changes because of that, and can translate
> that into a context loss.

Sounds good.


-- 
Michel Danzer, Linux Software Engineering       \   Tel: +1 905-882-2600
ATI Technologies Inc., Markham, Ontario, Canada  \       Extension: 3550