Re: fbcon: remove soft scrollback code (missing Doc. patch)

[Phillip Susi <phill@thesusis.net>]

Geert Uytterhoeven writes:

Judging from some of the comments in the code, it looks like you were
one of the original authors of fbcon?  I haven't been able to find any
of these sczbot crash reports, and am not sure how fuzzing syscalls
would really affect this code ( it's not really handling a buch of
ioctls or otherwise taking arguments from user space ) , but I am a bit
confused as to why the softback was implemented the way that it was.

vgacon simply copies the main buffer to vram in ->set_origin() and then
changes the pointers to operate out of the much larger vram while that
virtual terminal is active.  If I understand it correctly, it looks like
fbcon instead opts to operate out of the main buffer but rescue lines as
they are scrolled off and relocate them to the softback buffer.  This
seems to be rather more convoluted.

I'm thinking of re-implementing scrollback more like the way vgacon does
it: allocate a big "vram" buffer and operate out of that.  Obviously
->scroll() and ->scrolldelta() have to actually repaint the screen rather
than simply change the pointer register, but that should be about the
only difference.

I have also noticed that there was some code to use hardware panning of
the video buffer rather than having to do a block bitblt to scroll the
contents of the screen, but that it was disabled because virtually no
video drivers actually implemented it?  That seems like a shame, but if
it is so, then there's no sense carrying the dead code so I think I'll
clean that up now.

Now that I look at it again, everything is simply always redrawn now
instead of even doing a simple bitblt.  Daniel, you mentioned that
almost nobody supports hardware acceleration, but even without any
specific hardware support, surely even if bitblt() is implemented just
as a memcpy(), it has to be faster than redrawing all of the characters
doesn't it?  Getting rid of the panning if it isn't generally supported
I can see, but I don't understand killing bitblt even if most devices
don't accelerate it.

In addition, I noticed that ->screen_pos() was changed to just return
vc_origin+offset.  fbcon is the only console driver to implement
->screenpos() and if not implemented, vt defaults to using
vc_visible_origin+offset, so it looks like this function isn't needed at
all anymore and ->screen_pos() can be removed from struct consw.

Does this make sense or am I talking crazy?