FB model basic issues (WAS: radeon, apertures & memory mapping)

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Be that as it may, it remains a fact that such a change would break
> existing installations...
> 
> I think that mode setting and memory allocation should be separated. X
> will always reserve enough video RAM for the largest resolution it uses
> for the screen contents.

But X has no control on where fbdev will allocate memory. We are
thinking with the "new model" in mind, and so far, a mode setting is
under control of the framebuffer. Content of video memory (framebuffer,
textures, overlay, whatever) simply cannot be considered as preserved
accross mode switches.

We can't also block all evolutions just because we have to support a
broken model. We'll need to find a way to deal with that. An idea would
be for me to do the clearing only when I come from a different bit depth
or from text mode. That is, what i want to avoid, is those artifacts
caused by incorrect bit depth content. A strict mode change isn't an
issue in this case. That would solve my immediate problem.

_BUT_ in the long run, X will have to be smarter. Current UseFBDev or X
"fbdev" can't support dual head properly on top of fbdev anyway, so that
means I have some flexibility. The second head will probably" move on
mode switches since I intend to allocate it at the top of the accessible
aperture as described by Jon.

All of that just keep uncovering more and more issues with our current
fbdev model though. From discussions we had so far, it uncovers the
problem of arbitration. That is, can we simply afford having a process
mmap /dev/fb and blast things to it without any arbitration like we do
today ?

If the answer is yes, then we are in deep trouble for lots of reason:

 - VGA Arbitration might require us to flip/flop MEM/IO enable bits
 - Swapper control as explained earlier unless I can "reserve" a swapper
   for each head, that is manage to have one aperture per head
 - Engine discipline. What if the client on head 0 (like current X) uses
   the engine ? Even if the one on head 1 doesn't, simple framebuffer
   accesses can be enough to lock up the card.
 - etc....

I think that Jon's dream of having totally independant heads that can
run 2 separate applications is a long way away and we have sort-of to
tie /dev/fb's together, though I don't know how to acheive that in
practice, unless we switch to a new API that can enforce it. The current
fbdev API cannot.

DRI can do such things afaik (manage several contexts etc...), at least
provides the infrastructure for it. But until all clients are DRI
clients, we have a problem. That means that any direct fb client has to
take over the entire card. All heads. There is simply no choice, and
that doesn't even help with the VGA arbitration issue which still
require explicit lock/unlock around accesses.

I'm open to suggestions...

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click