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. ------------------------------------------------------- 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_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
