[...]
> This causes the occasional incorrect display in one frame (it is fixed when
> the video card does the next display refresh since the outb_p()s have then
> been completed). I guess console switching and scrollback could also cause
> the same, but the bug happening is so rare that it has only been noticed in
> scrolling (since systems usually do a lot of scrolling).
I'm afraid that this might be hardware dependent. Maybe some hardware
has a latch for the new start address. I've never seen the effect on
a Paradise VGA, or an ATI VGA Wonder XL. Isn't there also a bit to
disable generation of video signals. I remember reading this in the
IBM specs for their VGA; the text said you could maximize the video
memory bandwidth that way. Maybe we could use that.
>
> The cli() at the start doesn't help, because it doesn't stop the constant
> refreshing of the display done in the display adapter's hardware.
>
> The only way that I can think of to fix this would be to wait until the
> vertical sync pulse is active (and thus the display adapter isn't doing a
> refresh) before those outb_p()s. But this would slow down scrolling quite a
This is very slow from my experience. Maybe horizontal retrace will
also work, but is is much faster (because it's more frequent).
> lot, so to make it effective we'd have to buffer the scrolls and scroll
> several lines in one __set_origin(). And that is quite a lot of work to fix
> such a small bug...
>
> So, I guess it's reasonable to leave this slight glitch in, since it's so
> harmless...
>
> In theory it could be a security hole since a console user might happen to
> view sensitive information happening to still be in the incorrectly
> displayed part of video memory, but it is very improbable that this will
> happen in practice.
>
> --
> -=- Rjs -=- rjs@spider.compart.fi - http://isil.lloke.dna.fi/rjs/
Ulrich