From: James S. <jsi...@ac...> - 2000-04-16 13:25:38
|
---------- Forwarded message ---------- Date: Sun, 16 Apr 2000 19:26:33 +1000 From: Herbert Xu <he...@go...> To: lin...@vg... Cc: 877...@bu... Subject: [PATCH] console scrolling 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~} <he...@go...> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt |