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.
best
Vladimir Dergachev
------------------------------------------------------- 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
