On Mon, Mar 14, 2005 at 11:59:37PM -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.
DirectFB assumes all memory outside var.yres_virtual * fix.line_length is preserved. A totally valid assumption in my opinion. It allocates all offscreen memory starting from the top of the memory so overlaps with fbdev are as rare as possible. Currently it doesn't handle multi head except for Matrox G400/G450/G550 TV-out but that is handled without fbdev so no API limitations get in the way. I think that making the assumption that all memory is preserved when the memory layout (virtual resolution and depth) doesn't change is perfectly valid too. That would allow X to do it's Ctrl-Alt-+ and - things without repainting the whole screen. If radeonfb will allocate the buffer for the second head from the top of the memory users would basically have to guess it's location. matroxfb simply cuts the memory in two pieces and allocates the buffers from the start of each piece. I don't really like that approach. Adding a simple byte_offset field to fb_var_screeninfo would solve the problem quite nicely but I don't know if such API changes are acceptable at this stage. > > 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. Indeed. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- 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
