Mode setting & EGL

[Benjamin Herrenschmidt]

Hi !

I just subscribed to the list and in the middle of reading the archives.
Just a few quick commentes/notes about the mode setting stuff from what
I've read. Maybe just stuffs I've overlooked though, I haven't had time
to read the EGL spec yet.

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

 - Ideally, mode setting should be implemented in a separate library on
top of fbdev ioctl's and drm, and EGL using that library, no ? We want
more than just mode setting, we want things like geometry informations
(where each screen is placed relative to the next), we want extended
attribute lists (TV outputs or such things can have more "switchable"
attributes attached to modes, like wether to use full overscan or
borders, that sort of thing, those could be separate modes though, but
it may be useful to provide additional settings. That also includes
things like LCD backlight control etc...)

My point here is that the end user expect to have all those settings at
the same place. Keithp and I were discussing that a while ago and were
thinking about doing something xml based eventually. Also, part of the
problem is inter-dependency, especially on multi-head cards. Setting a
mode on one head my impose constraints on another one and force a change
of that other head. That sort of thing.

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

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

That's I have in mind at the moment...

Ben