Re: fbcon slowness [was NTP on 2.4.2?]

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

James Simmons wrote:
> 
> >Are you using fbcon? If so, and if it goes away after starting X, then it
> >is the "fbcon kills interrupt latency" problem.
> 
> Ug!!! This is getting bad. Give me some time. I plan on releasing a new
> vesafb using MMX to help speed up the drawing routines. It will help alot
> with the latency issues. I also know using ARM assembly we can greatly
> reduce the latency issues.

On console speedups: back in the old days, scrolling a subregion of the
text console to be _really_ slow on some machines.  I am talking about
text mode now, not framebuffer mode.  On some cards, text mode is
actually very very slow and the framebuffer is faster.  It took *2
seconds* to scroll a 50 lines of text 50 times on my 200MHz PPro system
4 years ago.  So less "back one screen" took 2 seconds.  And Emacs uses
"scroll region by N lines" a lot.  In those days, "N lines" scrolls
actually did N x 1 line scrolls, so text mode was really a burden on
that machine.  I took to using X, with a single screen size xterm to
present the illusion of console mode.

Well, nowadays on my laptop we have the joy of the framebuffer console.
Nice penguin aside, it means I get a console on the full screen area.

But it is nearly as slow at scrolling as my old 200MHz PPro.

Probably the lack of hardware area copies has something to do with
this.  However, who isn't familiar with xterm "jump scroll" mode?
That's nice and fast.

Could such a thing be implemented in the console driver?

cheers,
-- Jamie