newcons fb driver

[Bruce Evans]

On Mon, 3 Mar 2014, Poul-Henning Kamp wrote:

> In message <CAHSQbTBTq6EKD_crn=rvbeUcAEBn7E+=U8wRHeqchazF1LhjwQ at mail.gmail.com>
> , Justin Hibbits writes:
>> On Mon, Mar 3, 2014 at 8:49 AM, Kurt Lidl <lidl at pix.net> wrote:
>
>> All great knowledge, but really only answers half of what I'm looking
>> for (always good to know potential pitfalls).  Assuming a
>> tunable/sysctl is added, what's the best way to optimize from my
>> original post?  Use a backing buffer (potentially with a tunable to
>> not)?  Or assume we don't support background images, and write the
>> background color in the masked pixels?
>
> You should probably drop sos@ aka Søren Schmidt an email, he did
> syscons and has 10+ years experience in this stuff.
>
> One advantage of a backing buffer is that you can implement things
> like the 1000 line scroll buffer syscons did etc, I personally use
> that a lot to see dmesg output etc.

Is newcons so much worse than syscons that it doesn't even have a
backing buffer?  Backing buffers are a fundamental part of virtual
consoles.  Only one virtual console at a time uses the frame buffer,
and the output to the others is virtual.  Output to the one using the
frame buffer is not much different to output for others when they are
switched to active.  The output should be delayed as long as possible
to give a refresh rate faster than anyone's eyes can notice.  100-200
Hz is adequate, but I try to make it thousands of times faster than
that so that 100% of 1 CPU isn't needed for screen output.  syscons
in an old version of FreeBSD now gives me i/o speeds of 26MB/S to an
active console and 29MB/S to an inactive console.  In text mode of
course.  That is quite slow even for 10+ year old hardware that it was
re-tested on (old tests gave approximately the frame buffer speed and
I mostly stopped running them when frame buffers got fast enough for
text).  Except with 20+ year old hardware, the frame buffer speed makes
little difference in this test.  Graphics mode is harder to make
acceptably fast.

Why would newcons need to start supporting bytewise i/o now?  Hardware
was rarely broken enough to need it even in FreeBSD-1, and syscons has
always been sloppy about it.  i386 (but not amd64) has a bogus function
bcopyb() for doing such i/o.  This was used mainly by the 4+ (3+ too
many) console drivers in 386BSD, FreeBSD-1 and/or FreeBSD-2.0.  syscons
never used it.  In FreeBSD-4, it was used by pcvt.  pcvt used it only
for the character set initialization where speed is unimportant.  Now
bcopyb() still exists, but is never used.

Another reason that bcopyb() is bogus is that i/o should be done using
bus space.  dev/fb still has many hacks to avoid using bus-space.  Only
ia64 is clean there.  Other arches use massive ifdef tangles to do
things wrong.  Old versions of x86 used mostly bcopy() on frame buffers,
but now use a home made 16-bit copying function.  arm and mips still
use bcopy() but misspell it memcpy().

Bruce