First an explanation of the problem:
Consider this sequence of chars being written to /dev/tty1:
printf "\033[47m%81s\n\033[0m"
(assuming the console's width is 80 chars, otherwise replace 81 with width+1).
This should produce one line of spaces with a white background, and then
exactly one space with a white background at the beginning of the second
line.
It works as expected if no scrolling occurs. However, when the second line
requires scrolling, the result is two lines comprised of spaces with a
white background. The reason being the current console driver fills new
lines produced by scrolling with the video_erase_char *at* the time of
scrolling. Thus if video_erase_char changes later while the cursor is on
the new line, it will not affect the characters at the end of that line.
There is only one application that I know of which is affected by this, and
that is colour ls when you use a background colour other than the default.
The same problem exists with xterm/rxvt and all X terminal emulators based
on those two.
It does not affect kvt/putty, both of which don't fill new lines with the
same video_erase_char even when attributes change.
Attached is a patch against 2.2.14 that tries to address this problem by
noting when video_erase_char changes, and fills in the spaces to the end
of the line when a subquent cr/nl/ri happens.
I'd like to know if there are applications out there which is broken by
this change.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:08 EST