Fix some whitespace issues
Reorganise parisc_device probe routine to be a little less convoluted
Use ->hpa.start instead of ->hpa
Signed-off-by: Matthew Wilcox <willy@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
add || STI_CONSOLE to some of the basic FONTs. May need to get at
least one of them to default to "Y" for parisc.
Signed-off-by: Grant Grundler <grundler@parisc-linux.org>
Signed-off-by: Kyle McMartin <kyle@parisc-linux.org>
Fix bug 5441.
I didn't know about messy programs like svgatextmode... Couldn't this be
integrated in some linux/drivers/video/console/svgacon.c ?... So because
of the existence of the svgatextmode program, the kernel is not supposed to
touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?
Disabling the check in vgacon_resize() might help indeed, but I'm really
not sure whether it will work for any chipset: in my patch, CRT registers
are set at each console switch, since stty rows/cols apply to consoles
separately...
The attached solution is to keep the test, but if it fails, we assume that
the caller knows what it does (i.e. it is svgatextmode) and then disable
any further call to vgacon_doresize. Svgatextmode is usually used to
_expand_ the display, not to shrink it. And it is harmless in the case of
a too big stty rows/cols: the display will just be cropped. I tested it on
my laptop, and it works fine with svgatextmode.
A better solution would be that svgatextmode explicitely tells the kernel
not to care about video timing, but for this an interface needs be defined
and svgatextmode be patched.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Reported by: walt <wa1ter@myrealbox.com>
"I routinely switch the console font during bootup to
8x8 so I can get 50 lines per screen. Until 09 Sept,
just changing to the small font automatically gave me
all 50 lines -- but now I'm only getting 25 lines even
with the small font. The bottom half of the screen
displays the text that already scrolled off the top."
This bug is due to an erroneous check in the recently added hook,
vgacon_resize(). It checks the new height against the original number of
rows of the console. Because the original number of rows depends on both
the scanline and the font height, check it instead against the
scanline/fontheight.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
const-ify the font control structures and data, to make somewhat better
guarantees that these are not modified anywhere in the kernel.
Specifically for a kernel debugger to share this information from the
normal kernel code, such a guarantee seems rather desirable.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
An adjustment to the SM_DOWN case of fbcon_scroll to match the behavior of
SM_UP.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: "Antonino A. Daplas" <adaplas@hotpop.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
here is a new and extended version of the sisusbvga (previously: sisusb)
driver. The patch is against 2.6.13 and updates the driver to version 0.0.8.
Additions include complete VGA/EGA text console support and a build-in
display mode infrastructure for userland applications that don't know
about the graphics internals.
Fixes include some BE/LE issues and a get/put_dev bug in the previous
version.
Other changes include a change of the module name from "sisusb" to
"sisusbvga". The previous one was too generic IMHO.
Please note that the patch also affects the Makefile in
drivers/video/console as the driver requires the VGA 8x16 font in case
the text console part is selected.
Heavily tested, as usual. Please apply.
One thing though: I already prepared for removal of the "mode" field and
the changed "name" field in the usb_class_driver structure. This will
perhaps need some refinement depending on whether you/Linus merge the
respective core changes before or after 2.6.14.
Signed-off-by: Thomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The function bit_putcs() in drivers/video/console/bitblit.c is becoming large.
Break it up into its component functions (bit_putcs_unaligned and
bit_putcs_aligned).
Incorporated fb_pad_aligned_buffer() optimization by Roman Zippel.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
If console is blanked or in KD_GRAPHICS mode, delete cursor timer. No sense
flashing the cursor when there's nothing to be seen.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This trivial patch gives a performance boost to the framebuffer console
Constructing the bitmaps that are given to the bitblit functions of the
framebuffer drivers is time consuming. Here we avoide a call to the slow
fb_pad_aligned_buffer(). The patch replaces that call with a simple but
much more efficient bytewise copy.
The kernel spends a significant time at this place if you use 8x* fonts.
Every pixel displayed on your screen is prepared here.
Some benchmark results:
Displaying a file of 2000 lines with 160 characters each takes 889 ms
system time using cyblafb on my system (I´m using a 1280x1024 video mode,
resulting in a 160x64 character console)
Displaying the same file with the enclosed patch applied to 2.6.13 only
takes 760 ms system time, saving 129 ms or 14.5%.
Font widths other than 8 are not affected.
The advantage and correctness of this patch should be obvious.
Signed-off-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
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!
