On Friday 26 May 2006 04:57, Alexander E. Patrakov wrote:
> Jon Smirl wrote:
> > Most video hardware (99%) has enough memory to support double
> > buffering. You save it to the other buffer, display the error, and
> > copy it back on enter.
>
> This is possible only if the video memory management is in the kernel.
> Reason: userspace may also want to use double buffering, and we definitely
> want to allocate the "other (maybe third) buffer" somewhere in the free
> video memory. And allocating a lot of system RAM on oops seems to be a very
> bad idea (cascade of oopses may follow).
>
> Also, did anyone measure the video RAM usage during a typical Xgl session
> (i.e.: is there really enough free video RAM, not occupied by various
> caches)?
>
> Although, a Microsoft-ish "lost context, please redraw" solution has been
> already proposed.
In the case of an oops or a panic the system might not be stable enough to
continue operation. In fact, I have never had a system experience either and
still be able to run - even at the console.
In such a case, I think it'd be preferable to overwrite any graphics mode
currently in use to display the data. However, there must be some control on
this, to prevent people from arbitrarily killing the video mode to display
data. In any event, seeing the huge ideological split and the inability of
the people involved with this discussion to agree on a single, clear path for
the graphics system to take...
Let me put it this way: I may write code for free, but I don't write code
unless theres a design to it. I joined this conversation to toss a few ideas
off the top of my head out there and see if any were useful. This has become
something of a very genial flame war...
Over the next couple of days I'll work on a few design ideas for a replacement
to the current, somewhat poorly done graphics core in Linux and post them for
comments. These will hopefully cover all sides of the currently seen
ideological split as well as one or two that hopefully span the split.
All of them will be open for comment and revision, and if one of them is
ultimately agreed on, I'll start work on it. If not, then I'll go back to
just watching the traffic and hoping someone will finally start fixing the
problems in the graphics systems.
DRH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
