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

[Benjamin Herrenschmidt]

On Mon, 2005-03-14 at 23:59 -0500, Michel Dänzer wrote:
> On Tue, 2005-03-15 at 09:37 +1100, Benjamin Herrenschmidt wrote:
> > > 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. 
> 
> My understanding is that so far, the fbdev API has pretty much implied
> that any mode scans out the beginning of the memory accessed via the
> framebuffer device, unless the panning ioctl is used. IIRC at least
> DirectFB makes basically the same assumptions as X there.

But that will not be true with dual head unless I put the second
framebuffer into some fixed location in memory, thus making life more
difficult for the allocator.

> I'm not suggesting that, but I do think that tying together mode
> switching and memory allocation would be a big mistake.
> 
> The EGL API for this is currently being discussed on the dri-egl list
> (http://lists.freedesktop.org/mailman/listinfo/dri-egl), you may want to
> join in there.

I'll try, I'm near by bandwidth limit already though.

> > 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.
> 
> Sounds good.
> 
> > _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, 
> 
> Agreed for UseFBDev, but what's the problem with fbdev?

Read the rest of the email.
> 
> > But until all clients are DRI clients, we have a problem.
> 
> Keep in mind that basically the only driver-independent API exposed by
> the DRI is OpenGL, so I'm afraid it's unlikely that all fbdev
> applications will take that route.

I meant DRM. That is some arbitration & locking. There is simply _NO_
way we can have something that works with both independant multiple
heads and direct banging of the framebuffer without arbitration. There
is no magic here. It _can_ be made to work in _some_ cases using the
separate swappers, but that won't help if one of the heads try to do
accel....

Ben.