Many years ago when this driver was written, it had a use, but these
days it's nothing but trouble and distributions should not enable it
in any situation.

Pretty much every console device a sparc machine could see has a
bonafide real driver, making the PROM console hack unnecessary.

If any new device shows up, we should write a driver instead of
depending upon this crutch to save us.  We've been able to take care
of this even when no chip documentation exists (sunxvr500, sunxvr2500)
so there are no excuses.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix the following warnings in promcon:
WARNING: o-sparc64/drivers/video/console/built-in.o(.text+0x480): Section mismatch: reference to .init.data:promfont_unitable (between 'promcon_init_unimap' and 'promcon_init')
WARNING: o-sparc64/drivers/video/console/built-in.o(.text+0x488): Section mismatch: reference to .init.data:promfont_unitable (between 'promcon_init_unimap' and 'promcon_init')
WARNING: o-sparc64/drivers/video/console/built-in.o(.text+0x48c): Section mismatch: reference to .init.data:promfont_unicount (between 'promcon_init_unimap' and 'promcon_init')
WARNING: o-sparc64/drivers/video/console/built-in.o(.text+0x490): Section mismatch: reference to .init.data:promfont_unicount (between 'promcon_init_unimap' and 'promcon_init')

The warnings happens because the function: promcon_init_unimap()
references promfont_unitable and promfont_unicount which are marked
__initdata by the conmakehash command in the drivers/video/console/Makefile

Fix the warning by removing the __initdata marker on the two variables.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts 998e6d51 commit.

Add support for 270-degree (counterclockwise) rotation of the console.  To
activate, boot with:

fbcon=rotate:3
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add support for 180-degree (upside down) rotation of the console.  To
activate, boot with:

fbcon=rotate:2
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add support for 90-degree (clockwise) rotation of the console.  To activate,
boot with:

fbcon=rotate:1
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add support to rotate the font bitmap.  To save on processing time, the entire
fontdata will be rotated on a console switch, then stored in a buffer private
to fbcon.  To further save on processing, the fontdata will only be rotated if
the font has changed or if the angle of rotation has changed.  Only a single
copy of the rotated fontdata will be kept.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I converted the "rl" console font from the kbd utility to be a built-in font
for the framebuffer console, and I was wondering if you would be OK with
including it.  I've generated a font_rl.c file and related minor
modifications.  I find it's the most visually appealing of the kbd fonts which
is why I use it and selected it for conversion.  I believe the font is GPL'd.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

According to Jon Smirl, filling in the field fb_cursor with soft_cursor for
drivers that do not support hardware cursors is redundant.  The soft_cursor
function is usable by all drivers because it is just a wrapper around
fb_imageblit.  And because soft_cursor is an fbcon-specific hook, the file is
moved to the console directory.

Thus, drivers that do not support hardware cursors can leave the fb_cursor
field blank.  For drivers that do, they can fill up this field with their own
version.

The end result is a smaller code size.  And if the framebuffer console is not
loaded, module/kernel size is also reduced because the soft_cursor module will
also not be loaded.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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: NThomas Winischhofer <thomas@winischhofer.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

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: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus 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!