Vladimir Dergachev wrote:
On Sun, 16 May 2004, David Bronaugh wrote:
Vladimir Dergachev wrote:
Yes, I think the mode/dac programing code should be seperat from theI 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.
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 :)
The thing is most of these failure modes are software-based, not hardware.
The only real limitation is that the entire surface should be located within *hardware* video RAM (which is limited to a single card, usually).
This brings out an interesting memory management point: swappable versus non-swappable graphics objects.
A framebuffer is obviously non-swappable, while textures are swappable.
The fact that one can specify a surface that erroneously overlaps, say,
Z buffer and cursor will not lockup hardware. Nor will it cause any memory corruption - it will only look bad. Which must be dealt with by userspace software - it is in the same class of issues as windows manager
erroneously placing modal dialogs underneath other windows (happens to me
occasionally with KDE 3.2).
I think I reply to this (if a reply is needed) after the next paragraph.
So the kernel driver (or whatever code is setting the mode) should only check that the passed surface fits physically in the available video RAM.
(And, for some card, that it is aligned properly - usually not an issue).
So you have a bunch of framebuffers, and you can set them to be primary and secondary, Z buffer, stencil buffer, and so on and so forth. And of course you can upload a replacement for them.
If the user wants to see their stencil buffer (or the backbuffer ;) ) so be it.
Sure, any framebuffer can be put into any slot.
Thus we have three separate components (at least) - initialization code
that, besides booting up the card, find out the location and dimensions of physical RAM, mode setting code and memory management code.
Extending the description of init code: bootstrapping an initial graphics mode may be necessary.
I agree entirely, though.
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
