On Mon, 14 Mar 2005 23:59:37 -0500, Michel Dänzer <[EMAIL PROTECTED]> 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.
We are working on adding secondary head support on radeonfb. Where does the second buffer go when fbdev is running standalone? > > > 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. > > I'm not suggesting that, but I do think that tying together mode > switching and memory allocation would be a big mistake. If fbdev is running standalone and two heads are active, there has to be some very primitive buffer management going on. This may be as simple as fb0 starts at 0, and fb1 is at the end of CONFIG_APER_SIZE. When DRM loads it can install hooks to a more sophisticated memory manager. > > 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. help me out with the relevant attribute/value pairs for modes > > > 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? > > > > 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. There is a 300K OpenGL-ES to framebuffer implementation on sourceforge that someone might get working in this model. There is also a big difference between sharing the system with XGL and an app writen to use fbdev versus supporting an embedded system where only the fbdev app is running. > > -- > Earthling Michel Dänzer | Debian (powerpc), X and DRI developer > Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer > _______________________________________________ > xorg mailing list > [EMAIL PROTECTED] > http://lists.freedesktop.org/mailman/listinfo/xorg > -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- 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
