There is a far better solution. The console protocols have been designed
for serial lines with "inband-signalling" of events other than characters.
This is what we know as "escape-sequences". Even if there is a workaround
for the particular problem shown here, it is still slow compared to what
most other systems do.
The problem shows up for me particularly for color-apps. These add another
layer of inefficiency by sending lots of "change-color" commands via
The solution is simple. Give ncurses access to display memory. ncurses can
detect the display-type TERM=linux and try to use this feature when on
You will now probably tell me "NO ! NO ! The binaries would have to be suid
root to map the mem !" and you are right for now.
But there is something lurking out there to overcome this problem.
It is called GGI.
It is supposed to provide Linux with a "general graphics interface" that will
allow graphics software (and text as a side-effect) to run independent of
the hardware and architecture below. We currently achieve over 40MB/sec
transfer-rate using an old 486/66 with a PCI SPEA Mercury S3-964 based
> I have written a patch for this which implements put_char() and
> flush_chars() for the console. It seems to work quite well. A
> test program that writes 4000 byte blocks at a time, 1000 times,
> takes about 9.5 seconds in my patched kernel and 55.8 in the
> old kernel.
With GGI this takes about 0.1sec (assuming access to textmode is not
slower than graphics mode, but even then it will probably not exceed
> The only problem now is that I just grabbed 2.0.17 to
> make my patches against that and now my X server won't start (and
> of course I have it going straight to xdm from inittab so I get
Sad ... since GGI I never got stuck again (except due to programming-
errors in ggi that were my own fault ... kernel-hacking is risky ;-).
GGI provides a 100% working SAK (secure attention key) to me.
I can even kill off X cleanly and GGI will return me to a textmode
login-prompt. Only a really hard kernel crash can force me to use
the reset button now.
I apologize, if this seems quite a bit offensive, but we (the GGI
people) have received not much positive responses from some of the
kernel-gurus, and I wanted to show that GGI isn't just another
SVGAlib, but has potentials that go far beyond a simple "graphics-
For those that got interested now : visit my homepage to see some outdated
concepts of GGIs predecessor scrdrv or even better have a look at the GGI
project homepage at http://synergy.caltech.edu/~ggi/.
We are currently working on a "public preview release", that requires only
a very slight kernel-patch and shows many (but not all, due to the
limited patch) features that final GGI will have.
The release will be in about a month, when we have eliminated some problems
with generic VGA support, so that most people out there can try it out.
TNX 4 your time,
-- ============================================================================== Andreas Beck | Email : <firstname.lastname@example.org> === World-Wide-Web URL : http://sunserver1.rz.uni-duesseldorf.de/~becka === ==============================================================================