Knut Petersen wrote:

quoted

This has been discussed before.  Not all hardware can do a set_par()
instantaneously, some may require seconds.  And that will become a 
usability
problem. Just imagine switching from one console to another and it takes
5 seconds.

That would be unacceptable, agreed. But it´s also not really acceptable 
to risk to execute a few
dozend imageblits in redraw_screen() while the hardware might be in an 
unusable state.

It doesn't. but it depends what you mean by unusable state. In the
console/fbcon/fbdev subsystem an unusable state can be any of the ff:

	- KD_GRAPHICS mode
	- between coming from KD_GRAPHICS to KD_TEXT and before set_par()
	- graphics device in a suspended state 

If any the above are true, no drawing functions gets called.

Checking
for that situation every imageblit would have a big performance penalty.

Maybe. I've measured this before, you lose something like 3-5%.  Hardly
noticeable in real-world usage. So I would gladly sacrifice a little
performance for stability. Doing a set_par() for each switch, in turn,
will be noticeable and is a great blow to usability.  It really boils down
to a balance between usability, stability and performance.  Throw in code
readability and maintainability also.

(Note: In the case of a bug in an app that runs as root, I think everyone will
agree that the bug must be fixed in the app, not the kernel.)

(Note 2: Even with those checks in place, the 2.6 framebuffer system is still
faster than 2.4)

Tony


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf