On Tuesday 2008-10-14 13:03, Linus Torvalds wrote:
>
>Alexander, is your patch the same as mine, or something else?
Something else, you reverted more.
>@@ -400,7 +400,7 @@ static u8 build_attr(struct vc_data *vc, u8 _color, u8 _intensity, u8 _blink,
> * Bit 7 : blink
> */
> {
>- u8 a = _color;
>+ u8 a = vc->vc_color;
> if (!vc->vc_can_do_color)
> return _intensity |
> (_italic ? 2 : 0) |
This hunk for example was not reverted in Alexander's patch. I think it
should remain at reading "a = _color", because the caller(s) can just be
updated to use pass in vc->vc_color for _color. Actually, the callers
already do just this.
>Jan, if different, can you test this?
>@@ -1890,9 +1883,9 @@ static int fbcon_scroll(struct vc_data *vc, int t, int b, int dir,
> scr_memsetw((unsigned short *) (vc->vc_origin +
> vc->vc_size_row *
> (b - count)),
>- vc->vc_scrl_erase_char,
>+ vc->vc_video_erase_char,
> vc->vc_size_row * count);
>- ret = 1;
>+ return 1;
> break;
>
> case SCROLL_WRAP_MOVE:
His patch remained at "ret = 1". It should not cause any difference
besides potential compiler optimizations --- control would just trickle
through all the break;s and then return shortly with 'ret' anyway):
>- vc->vc_video_erase_char = saved_ec;
>- return ret;
>+ return 0;
> }
As such, your patch is producing the same net effect
for me as Alexander's.
As for you being unable to reproduce it, it is imperial to test the
linux vt-on-a-VGA. You cannot cheat using UML-in-a-xterm (that was a bit
of a surprise even to me, so I let you know), serial console or anything
like that.
The expected output is http://tinyurl.com/3zs3dk
(color erased only on scroll; linewraps causing no scroll don't
colorflood); behavior matches xterm.