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

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:

quoted

quoted

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.

quoted

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.

quoted

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

quoted

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.