| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit c9e587abfdec2c2aaa55fab83bcb4972e2f84f9b, and the
subsequent commits that fixed it up:
- afa9b649 "fbcon: prevent cursor disappearance after switching to 512
character font"
- d850a2fa "vt/fbcon: fix background color on line feed"
- 7fe3915a "vt/fbcon: update scrl_erase_char after 256/512-glyph font
switch"
by request of Alan Cox. Quoth Alan:
"Unfortunately it's wrong and its been causing breakages because
various apps like ncurses expect our previous (and correct)
behaviour."
Alexander sent out a similar patch.
Requested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Tested-by: Jan Engelhardt <jengelh@medozas.de>
Cc: Alexander V. Lukyanov <lav@netis.ru>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This patch makes the following needlessly global code static:
- sticon.c: sticonsole_init()
- sticore.c: struct default_sti
- sticore.c: sti_init_graph()
- sticore.c: sti_inq_conf()
- sticore.c: sti_rom_copy()
- sticore.c: sti_select_fbfont()
- sticore.c: sti_select_font()
- sticore.c: sti_get_wmode_rom()
- sticore.c: sti_read_rom()
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
A command that causes a line feed while a background color is active,
such as
perl -e 'print "x" x 60, "\e[44m", "x" x 40, "\e[0m\n"'
and
perl -e 'print "x" x 40, "\e[44m\n", "x" x 40, "\e[0m\n"'
causes the line that was started as a result of the line feed to be completely
filled with the currently active background color instead of the default
color.
When scrolling, part of the current screen is memcpy'd/memmove'd to the new
region, and the new line(s) that will appear as a result are cleared using
memset. However, the lines are cleared with vc->vc_video_erase_char, causing
them to be colored with the currently active background color. This is
different from X11 terminal emulators which always paint the new lines with
the default background color (e.g. `xterm -bg black`).
The clear operation (\e[1J and \e[2J) also use vc_video_erase_char, so a new
vc->vc_scrl_erase_char is introduced with contains the erase character used
for scrolling, which is built from vc->vc_def_color instead of vc->vc_color.
Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Add color support to the "underline" and "italic" attributes as in
OpenBSD/NetBSD-style (vt220) and xterm.
Signed-off-by: Jan Engelhardt <jengelh@gmx.de>
Acked-by: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
- move some structs and arrays to the read-only (.rodata) section
[akpm@osdl.org: build fix]
Signed-off-by: Helge Deller <deller@gmx.de>
Acked-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
MAX_NR_CONSOLES, fg_console, want_console and last_console are more of a
function of the VT layer than the TTY one. Moving these to vt.h and vt_kern.h
allows all of the framebuffer and VT console drivers to remove their
dependency on tty.h.
[akpm@osdl.org: fix alpha build]
Signed-off-by: Jon Smirl <jonsmir@gmail.com>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Do not mark sticon_startup() as __init
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
