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.
Maybe I am missing something - what do you mean by swappable ? All this exists in video RAM, not system RAM. Textures (and other temporary offscreen surfaces) are usually simply discarded as reads from video memory can be rather slow (Something PCI Express will hopefully fix).
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.
Somehow I got the impression that you misunderstood me... Likely not, but I'll reiterate just in case.
The mode is set using a surface struct like this:
typedef struct {
long format; /* format being used - only a few are relevant */
long first_pixel; /* offset in video ram, first pixel to display */
long width;
long height;
long step; /* increment between pixels, does all hardware
support this ? */
long stride; /* increment between lines */
} SURFACE;It is completely low-level and has nothing to do with management of video RAM.
It is up to the user-space program then to decide how to partition existing video RAM.
A not unlikely situation would be when the user has several separate virtual screens (i.e. framebuffers), likely in different formats (say two in RGB32 and another one in YUV) with several heads displaying different surfaces (for example: first and second DVI-out are displaying different portions of first virtual screen and TV-out is displaying YUV surface and the second virtual screen just hangs there..).
Note, btw, that both cursor and video overlay can be considered as a "head".
If the user wants to see their stencil buffer (or the backbuffer ;) ) so be it.
Sure, any framebuffer can be put into any slot.
There are no "slots" to setup (except whatever abstraction userspace manager uses) - the driver would not prevent setting a YUV surface over area that is actually used for RGB32 framebuffer. The hardware does not care about such things so the driver should ignore it too..
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.
This could actually be handled separately, via SAK (secure attention key)
operation. What this should do is yank the graphics device from all its users, set default video mode and return it to console. So on boot the system would simply self-initiate a SAK..
This has the advantage that init code can actually be a regular init code like in any other driver - i.e. it executes before the system knows about the new device and if it fails the module can refuse to load.
best
Vladimir Dergachev
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
------------------------------------------------------- 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
