Currently, the default linux 16-colors are converted to 4-colors by simply
dividing the values by 4. However, this is not necessarily correct since the
first 4 colors are converted to black, rendering them invisible.
So, for black, no conversion; for light colors, convert to gray, for normal
text color, no conversion, and for bright colors, convert to intense white.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently, fbcon assumes that the visual FB_VISUAL_MONO* is always 1 bit.
According to Geert, there are old hardware where it's possible to have
monochrome at 8-bit, but has only 2 colors, black - 0x00 and white - 0xff.
Fix color handlers (fb_get_color_depth, and get_color) for this special case.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add capability to fbdev to listen to the FB_ACTIVATE_ALL flag. If set, it
notifies fbcon that all consoles must be set to the current var.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Some people use 66-cells braille devices for reading the console, and hence
would like to reduce the width of the screen by using:
stty cols 66
However, the vga text console doesn't behave correctly: the 14 first
characters of the second line are put on the right of the first line and so
forth.
Here is a patch to correct that. It corrects the disp_end and offset
registers of the vga board on console resize and console switch.
On usual screens, you then correctly get a right and/or bottom blank
margin. On some laptop panels, the output is resized so that text actually
gets magnified, which can be great for some people (see
http://dept-info.labri.fr/~thibault/ls.jpg ).
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently even when the cursor is disabled (`setterm -cursor off`), it is
still repainted as a black rectangle the size of a single char. This can
be seen, for example, by chvt'ing to a free tty, disabling the cursor and
doing `dd if=3D/dev/urandom of=3D/dev/fb0`.
The patch changes this behaviour by avoiding painting anything when the
cursor is disabled.
Signed-off-by: Michal Januszewski <spock@gentoo.org>
Cc: <linux-fbdev-devel@lists.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The generic fbcon code tries to register and use the vsync IRQ for
ARM platforms with acornfb, but forgets to disable its own cursor
timer. The result is a flickering flashing cursor.
Remove the code from the fbcon core to register this platform
private interrupt.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Shrink the stack when calling the drawing alignment functions.
Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Improve the fonts for use with the framebuffer.
I've added all the characters marked 'FIXME' in the sun12x22 font and
created a 10x18 font (based on the sun12x22 font) and a 7x14 font (based
on the vga8x16 font).
This patch is non-intrusive, no options are enabled by default so most
users won't notice a thing.
I am placing my changes under the GPL, however, I've not seen any copyright
notices on the sun12x22 font and the vga8x16 font which I derived my new
fonts from so I don't know what the copyright status is.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Currently when going from vgacon to fbcon the VT screenbuffer are often
different sizes. In the case when they are different sizes a new VT
screenbuffer is allocated and the contents are copied into the new buffer.
Currently the amount copied from VGA text memory to the new screenbuf is
the size of the framebuffer console. If the framebuffer console new VT
screen buffer is greater than the VGA text memory size then we get some of
the VGA BIOS contents as well.
This patch will only allow you to copy up to the size of VGA text memory
now. The rest is filled with erase characters.
Initial patch by Jordan Crouse <jordan.crouse@amd.com>
Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Since no one is using the inbuf, outbuf of struct fb_pixmap I removed their
use in the framebuffer console. The idea is instead move the pixmap
functionality below the accelerated functions intead of on top as the way
it is now. If there is no objection please apply. This is against Linus
latestr GIT tree. Thank you.
Signed-off-by: James Simmons <jsimmons@www.infradead.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch fixes a check after use found by the Coverity checker.
Signed-off-by: Adrian Bunk <bunk@fs.tum.de>
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When allocating a new VC with vgacon_init(), the font is shared across all
the VGA consoles. However, the font mask was always set to the default
value of zero in visual_init(), even if we were using 512 character fonts
at the time.
Moreover, code in vgacon.c:vga_do_font_op() didn't reset the mask if the
console driver thinks it's already in 512 character mode. This means that
to *fix* it, you'd actually have to take the console out of 512 character
mode and then set it back.
The attached sets vc_hi_font_mask in vgacon_init() for any new consoles
opened if the vgacon driver is already in 512 character mode, solving this.
This bug goes back to 2.4.18 at least, probably earlier.
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!
