Vladimir Dergachev wrote:
I don't think what I was proposing coupled or brought together the two. As I see it, the mode programming code (both DAC and CRTC are rather outmoded terms; think LCD with digital link) is totally separate from the framebuffer management code. The only reason there's even any calling between them is that a side effect of setting a mode is allocating a fresh framebuffer, and wiping out the old one. That, as far as I can see, is the only way they are coupled.Yes, I think the mode/dac programing code should be seperat from the frambuffer allocation/mngmnt code. Wather it should live in the DRM is another story, thought It should live kernel side as it workes closely with the hardware.
Ideally, it would be possible to give part of the framebuffer (a "surface")
and to set a mode displaying that. So setting a mode should not wipe framebuffer contents.
This is useful for virtual screens, for rotating display and for displaying the same virtual screen on more than one monitor.
OK, so then what you're proposing is a -pure- interface to set modes, given a "surface" identifier (which I assume could encompass several framebuffers). Maybe this notion of a "surface" is also a way to rationalize clone and mergedfb mode?
I actually like this idea. I was still thinking of this idea of allocating framebuffers as a static thing -- but you're absolutely right, it's totally dynamic.
This would of course add a few more failure conditions -- if the framebuffer's virtual is less than the mode you're trying to set, it'll fail -- and so on. But overall, I like it :)
David Bronaugh
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
