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>

Catalin and kmemleak spotted a leak of a VC screen buffer in
vc_allocate() due to the following chain of events:

	vc_allocate()
	  visual_init(init=1)
	    vc->vc_sw->con_init(init=1)
              fbcon_init()
	        vc_resize()
	          vc->screen_buf = kmalloc()
	  vc->screen_buf = kmalloc()

The common way for the VC drivers is to set the screen dimension
parameters manually in the init case and only call vc_resize() for
!init - which allocates a screen buffer according to the new
dimensions.

fbcon instead would do vc_resize() unconditionally and afterwards set
the dimensions manually (again) for !init - i.e. completely upside
down.  The vc_resize() allocated buffer would then get lost by
vc_allocate() allocating a fresh one.

Use vc_resize() only for actual resizing to close the leak.

Set the dimensions manually only in initialization mode to remove the
redundant setting in resize mode.

The kmemleak trace from Catalin:

unreferenced object 0xde158000 (size 12288):
  comm "Xorg", pid 1439, jiffies 4294961016
  hex dump (first 32 bytes):
    20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00   . . . . . . . .
    20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00   . . . . . . . .
  backtrace:
    [<c006f74b>] __save_stack_trace+0x17/0x1c
    [<c006f81d>] create_object+0xcd/0x188
    [<c01f5457>] kmemleak_alloc+0x1b/0x3c
    [<c006e303>] __kmalloc+0xdb/0xe8
    [<c012cc4b>] vc_do_resize+0x73/0x1e0
    [<c012cdf1>] vc_resize+0x15/0x18
    [<c011afc1>] fbcon_init+0x1f9/0x2b8
    [<c0129e87>] visual_init+0x9f/0xdc
    [<c012aff3>] vc_allocate+0x7f/0xfc
    [<c012b087>] con_open+0x17/0x80
    [<c0120e43>] tty_open+0x1f7/0x2e4
    [<c0072fa1>] chrdev_open+0x101/0x118
    [<c006ffad>] __dentry_open+0x105/0x1cc
    [<c00700fd>] nameidata_to_filp+0x2d/0x38
    [<c00788cd>] do_filp_open+0x2c1/0x54c
    [<c006fdff>] do_sys_open+0x3b/0xb4
Reported-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
Tested-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Tested-by: NDave Young <hidave.darkstar@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix the rotate_ud() function not to crash in case of a font which has not
a width of multiple by 8: The inner loop of the font pixel copy should not
access a bit outside the font memory area.  Subtract the shift offset from
the font width will prevent this.
Signed-off-by: NStefani Seibold <stefani@seibold.net>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NHelge Deller <deller@gmx.de>

Slab is initialized before the console subsystem so use the slab allocator in
vgacon_scrollback_startup().
Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>

Uwe Geuder noted that he gets random bitmaps on a text console if he tried
to type extended characters (like the e acute).  For him everything above
unicode 0xa0 was corrupted.

After some digging there seems to be a little culprit in vgacon since the
beginning of ages (well git).  The function vgacon_font_get will store the
number of characters correctly in font->charcount but then calls to
vgacon_do_font_op(..., 0, 0).  Which means only the lower 256 characters
are actually stored to the fontdata.  The rest is left untouched.  So the
next time that saved data is used, the garbled font appears.  This happens
on every switch between text consoles.

Addresses https://bugs.launchpad.net/ubuntu/+source/linux/+bug/355057Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Tested-by: NUwe Geuder <ubuntuLp-ugeuder@sneakemail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

fb_notifier_call_chain() is called with info->lock held, i.e.  in
do_fb_ioctl() => FBIOPUT_VSCREENINFO => fb_set_var() and the some
notifier callbacks, like fbcon_event_notify(), try to re-acquire
info->lock again.

Remove the lock/unlock_fb_info() in all the framebuffer notifier
callbacks' and be sure to always call fb_notifier_call_chain() with
info->lock held.
Reported-by: NPavel Roskin <proski@gnu.org>
Reported-by: NEric Miao <eric.y.miao@gmail.com>
Signed-off-by: NAndrea Righi <righi.andrea@gmail.com>
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix a circular locking dependency in the frame buffer console driver
pushing down the mutex fb_info->lock.

Circular locking dependecies occur calling the blocking
fb_notifier_call_chain() with fb_info->lock held.  Notifier callbacks can
try to acquire mm->mmap_sem, while fb_mmap() acquires the locks in the
reverse order mm->mmap_sem => fb_info->lock.
Tested-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Signed-off-by: NAndrea Righi <righi.andrea@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Kill the last remaining vblank cursor blinking user
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

- (better, more, bigger ...) then -> (...) than
Signed-off-by: NFrederik Schwarzer <schwarzerf@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add mode setting support to the DRM layer.

This is a fairly big chunk of work that allows DRM drivers to provide
full output control and configuration capabilities to userspace.  It was
motivated by several factors:
  - the fb layer's APIs aren't suited for anything but simple
    configurations
  - coordination between the fb layer, DRM layer, and various userspace
    drivers is poor to non-existent (radeonfb excepted)
  - user level mode setting drivers makes displaying panic & oops
    messages more difficult
  - suspend/resume of graphics state is possible in many more
    configurations with kernel level support

This commit just adds the core DRM part of the mode setting APIs.
Driver specific commits using these new structure and APIs will follow.

Co-authors: Jesse Barnes <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com>
Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add missing check for Atari in free_irq() call, which could cause problems on
multi-platform m68k kernels.
Reported-by: NBrad Boyer <flar@allandria.com>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Remove the Mac VBL interrupt code as it doesn't work properly and
doesn't bring any benefit when fixed. Also remove unused
DEFAULT_CURSOR_BLINK_RATE macro and irqres variable.
Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Add a call to cancel_work_sync() in fbcon_exit() to cancel any pending
work in the fbcon workqueue.

The current implementation of fbcon_exit() sets the fbcon workqueue
function info->queue.func to NULL, but does not assure that there is no
work pending when it does so.  On occasion, depending on system timing,
there will still be pending work in the queue when fbcon_exit() is
called.  This results in a null pointer deference when run_workqueue()
tries to call the queue's work function.

Fixes errors on shutdown similar to these:

  Console: switching to colour dummy device 80x25
  Unable to handle kernel paging request for data at address 0x00000000
Signed-off-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The commit aef7db4b fixed the problem with
recursive locking in fb blanking code if blank is caused by user setting
the /sys/class/graphics/fb*/blank.  However this broke the fbcon timeout
blanking.

If you use a driver that defines ->fb_blank operation and at the same time
that driver relies on other driver (e.g.  backlight or lcd class) to blank
the screen, when the fbcon times out and tries to blank the fb, it will
call only fb driver blanker and won't notify the other driver.  Thus FB
output is disabled, but the screen isn't blanked.

Restore fbcon blanking and at the same time apply the proper fix for the
above problem: if fbcon_blank is called with FBINFO_FLAG_USEREVENT, we are
already called through notification from fb_blank, thus we don't have to
blank the fb again.
Signed-off-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Updatescrollmode is marked inline, but it's big and is called only from
non-critical codepaths (fbcon_resize, fbcon_switch, fbcon_modechanged).
Dropping it saves almost 800 bytes of text size.

   text    data     bss     dec     hex filename
  23859     287    8448   32594    7f52 drivers/video/console/fbcon.o.before
  23065     287    8448   31800    7c38 drivers/video/console/fbcon.o.after
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

echo 3 >> /sys/class/graphics/fbcon/rotate_all, then switch to another
console. Result:

	BUG: unable to handle kernel paging request at ffffc20005d00000
	IP: [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
	PGD 7e228067 PUD 7e229067 PMD 7bc1f067 PTE 0
	Oops: 0002 [1] SMP
	CPU 1
	Modules linked in: [...a lot...]
	Pid: 10, comm: events/1 Not tainted 2.6.26.5-45.fc9.x86_64 #1
	RIP: 0010:[bitfill_aligned+149/265]  [bitfill_aligned+149/265] bitfill_aligned+0x95/0x109
	RSP: 0018:ffff81007d811bc8  EFLAGS: 00010216
	RAX: ffffc20005d00000 RBX: 0000000000000000 RCX: 0000000000000400
	RDX: 0000000000000000 RSI: ffffc20005d00000 RDI: ffffffffffffffff
	RBP: ffff81007d811be0 R08: 0000000000000400 R09: 0000000000000040
	R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000010000
	R13: ffffffff811632f0 R14: 0000000000000006 R15: ffff81007cb85400
	FS:  0000000000000000(0000) GS:ffff81007e004780(0000) knlGS:0000000000000000
	CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
	CR2: ffffc20005d00000 CR3: 0000000000201000 CR4: 00000000000006e0
	DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
	DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
	Process events/1 (pid: 10, threadinfo ffff81007d810000, task ffff81007d808000)
	Stack:  ffff81007c9d75a0 0000000000000000 0000000000000000 ffff81007d811c80
	 ffffffff81163a61 ffff810000000000 ffffffff8115f9c8 0000001000000000
	 0000000100aaaaaa 000000007cd0d4a0 fffffd8a00000800 0001000000000000
	Call Trace:
	 [cfb_fillrect+523/798] cfb_fillrect+0x20b/0x31e
	 [soft_cursor+416/436] ? soft_cursor+0x1a0/0x1b4
	 [ccw_clear_margins+205/263] ccw_clear_margins+0xcd/0x107
	 [fbcon_clear_margins+59/61] fbcon_clear_margins+0x3b/0x3d
	 [fbcon_switch+1291/1466] fbcon_switch+0x50b/0x5ba
	 [redraw_screen+261/481] redraw_screen+0x105/0x1e1
	 [ccw_cursor+0/1869] ? ccw_cursor+0x0/0x74d
	 [complete_change_console+48/190] complete_change_console+0x30/0xbe
	 [change_console+115/120] change_console+0x73/0x78
	 [console_callback+0/292] ? console_callback+0x0/0x124
	 [console_callback+97/292] console_callback+0x61/0x124
	 [schedule_delayed_work+25/30] ? schedule_delayed_work+0x19/0x1e
	 [run_workqueue+139/282] run_workqueue+0x8b/0x11a
	 [worker_thread+221/238] worker_thread+0xdd/0xee
	 [autoremove_wake_function+0/56] ? autoremove_wake_function+0x0/0x38
	 [worker_thread+0/238] ? worker_thread+0x0/0xee
	 [kthread+73/118] kthread+0x49/0x76
	 [child_rip+10/18] child_rip+0xa/0x12
	 [kthread+0/118] ? kthread+0x0/0x76
	 [child_rip+0/18] ? child_rip+0x0/0x12

Because fbcon_set_all_vcs()->FBCON_SWAP() uses display->rotate == 0 instead
of fbcon_ops->rotate, and vc_resize() has no effect because it is called with
new_cols/rows == ->vc_cols/rows.

Tested on 2.6.26.5-45.fc9.x86_64, but
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git seems to
have the same problem.
Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: <stable@kernel.org>	[2.6.27.x, 2.6.26.x, maybe 2.6.25.x]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

There's no point in checking diff == c->vc_rows, because it can be true
only when count == 0, but we already checked that.  Additionally move
variables used only in one block to this block.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: Antonino Daplas <adaplas@gmail.com>
Acked-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Join multiple scr_memcpyw into 1-3 calls (usually 2).  (benchmarked
average speedup: 1%)
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Now that device_create() has been audited, rename things back to the
original call to be sane.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This reverts commit c9e587ab, 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: NAlan Cox <alan@lxorguk.ukuu.org.uk>
Tested-by: NJan Engelhardt <jengelh@medozas.de>
Cc: Alexander V. Lukyanov <lav@netis.ru>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix infinite recursive notifier in the fbdev layer.  This causes recursive
locking.  Dmitry Baryshkov found the problem and confirmed that the patch
fixes the bug.

After doing
# echo 1 > /sys/class/graphics/fb0/blank
I got the following in my kernel log:

=============================================
[ INFO: possible recursive locking detected ]
2.6.27-rc6-00086-gda63874-dirty #97
---------------------------------------------
echo/1564 is trying to acquire lock:
 ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c

but task is already holding lock:
 ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c

other info that might help us debug this:
2 locks held by echo/1564:
 #0:  (&buffer->mutex){--..}, at: [<c00ddde0>] sysfs_write_file+0x30/0x80
 #1:  ((fb_notifier_list).rwsem){..--}, at: [<c005a384>] __blocking_notifier_call_chain+0x38/0x6c

stack backtrace:
[<c0029fe4>] (dump_stack+0x0/0x14) from [<c0060ce0>] (print_deadlock_bug+0xa4/0xd0)
[<c0060c3c>] (print_deadlock_bug+0x0/0xd0) from [<c0060e54>] (check_deadlock+0x148/0x17c)
 r6:c397a1e0 r5:c397a530 r4:c04fcf98
[<c0060d0c>] (check_deadlock+0x0/0x17c) from [<c00637e8>] (validate_chain+0x3c4/0x4f0)
[<c0063424>] (validate_chain+0x0/0x4f0) from [<c0063efc>] (__lock_acquire+0x5e8/0x6b4)
[<c0063914>] (__lock_acquire+0x0/0x6b4) from [<c006402c>] (lock_acquire+0x64/0x78)
[<c0063fc8>] (lock_acquire+0x0/0x78) from [<c0316ca8>] (down_read+0x4c/0x60)
 r7:00000009 r6:ffffffff r5:c0427a40 r4:c005a384
[<c0316c5c>] (down_read+0x0/0x60) from [<c005a384>] (__blocking_notifier_call_chain+0x38/0x6c)
 r5:c0427a40 r4:c0427a74
[<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28)
 r8:00000009 r7:c086d640 r6:c3967940 r5:00000000 r4:c38984b8
[<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24)
[<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70)
[<c014c128>] (fb_blank+0x0/0x70) from [<c0155978>] (fbcon_blank+0x114/0x1bc)
 r5:00000001 r4:c38984b8
[<c0155864>] (fbcon_blank+0x0/0x1bc) from [<c0170ea8>] (do_blank_screen+0x1e0/0x2a0)
[<c0170cc8>] (do_blank_screen+0x0/0x2a0) from [<c0154024>] (fbcon_fb_blanked+0x74/0x94)
 r5:c3967940 r4:00000001
[<c0153fb0>] (fbcon_fb_blanked+0x0/0x94) from [<c0154228>] (fbcon_event_notify+0x100/0x12c)
 r5:fffffffe r4:c39bc194
[<c0154128>] (fbcon_event_notify+0x0/0x12c) from [<c005a0d4>] (notifier_call_chain+0x38/0x7c)
[<c005a09c>] (notifier_call_chain+0x0/0x7c) from [<c005a3a0>] (__blocking_notifier_call_chain+0x54/0x6c)
 r8:c3b51ea0 r7:00000009 r6:ffffffff r5:c0427a40 r4:c0427a74
[<c005a34c>] (__blocking_notifier_call_chain+0x0/0x6c) from [<c005a3d8>] (blocking_notifier_call_chain+0x20/0x28)
 r8:00000001 r7:c3a7e000 r6:00000000 r5:00000000 r4:c38984b8
[<c005a3b8>] (blocking_notifier_call_chain+0x0/0x28) from [<c014baa0>] (fb_notifier_call_chain+0x1c/0x24)
[<c014ba84>] (fb_notifier_call_chain+0x0/0x24) from [<c014c18c>] (fb_blank+0x64/0x70)
[<c014c128>] (fb_blank+0x0/0x70) from [<c014e450>] (store_blank+0x54/0x7c)
 r5:c38984b8 r4:c3b51ec4
[<c014e3fc>] (store_blank+0x0/0x7c) from [<c017981c>] (dev_attr_store+0x28/0x2c)
 r8:00000001 r7:c042bf80 r6:c39eba10 r5:c3967c30 r4:c38e0140
[<c01797f4>] (dev_attr_store+0x0/0x2c) from [<c00ddaac>] (flush_write_buffer+0x54/0x68)
[<c00dda58>] (flush_write_buffer+0x0/0x68) from [<c00dde08>] (sysfs_write_file+0x58/0x80)
 r8:c3b51f78 r7:c3bcb070 r6:c39eba10 r5:00000001 r4:00000001
[<c00dddb0>] (sysfs_write_file+0x0/0x80) from [<c009de04>] (vfs_write+0xb8/0x148)
[<c009dd4c>] (vfs_write+0x0/0x148) from [<c009e384>] (sys_write+0x44/0x70)
 r7:00000004 r6:c3bcb070 r5:00000000 r4:00000000
[<c009e340>] (sys_write+0x0/0x70) from [<c0025d00>] (ret_fast_syscall+0x0/0x2c)
 r6:4001b000 r5:00000001 r4:401dc658
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Reported-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Testted-by: NDmitry Baryshkov <dbaryshkov@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 22af89aa ("fbcon: replace mono_col
macro with static inline") changed the order of operations for computing
monochrome color values.  This generates 0xffff000f instead of 0x0000000f
for a 4 bit monochrome color, leading to image corruption if it is passed
to cfb_imageblit or other similar functions.  Fix it up.

Cc: Harvey Harrison <harvey.harrison@gmail.com>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: <stable@kernel.org>		[2.6.26.x]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Impact: cleanup

Video mode selection became always possible in 2.6.23-rc1 after i386 setup
code rewrite in C.

Regardless, VIDEO_SELECT is stupid config option because it affects only
kernel setup code, not code which always stays in memory.

vga= always possible now which is good.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

Adjust and honor the vc_scrl_erase_char for 256 and 512 character fonts.

It fixes the issue with disappearing cursor during scrolling
(http://bugzilla.kernel.org/show_bug.cgi?id=11258).  The issue was
reported and tracked by Peter Hanzel.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Reported-by: NPeter Hanzel <hanzelpeter@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 2d04a4a7, which made
it impossible to make the softcursor use the highlight colors.

Yes, the fourth bit should be "blinking", but since we cannot reasonably
blink in fbcon, highlighting it with a bright background is preferable.
Reported-by: NPavel Machek <pavel@suse.cz>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Antonino A. Daplas <adaplas@pol.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If the 'clear' command is used on the frame buffer with a logo the upper
area is filled by few lines but not scrolled anymore.

Fix this by removing the protected area for the logo if any part of the
logo is cleared.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add drivers/video/console/promcon_tbl.c to the list of ignored files.
This file is generated by conmakehash against drivers/video/console/prom.uni.
Signed-off-by: NFlorian Fainelli <florian.fainelli@telecomint.eu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On HPPA there exists some older GSC graphics cards, which need special
graphic-card-BIOS patching to become supported.  Since we don't have yet
implemented the patching, it's better to detect such cards in advance,
inform to the user that there are known problems and to not activate the
card.

Problematic GSC cards and BIOS versions are:
* Hyperdrive/Hyperbowl (A4071A) graphics card series:
   * ID = 0x2BCB015A (Version 8.04/8)
   * ID = 0x2BCB015A (Version 8.04/11)
* Thunder 1 VISUALIZE 48 card:
   * ID = 0x2F23E5FC (Version 8.05/9)
* Thunder 2 VISUALIZE 48 XP card:
   * ID = 0x2F8D570E (Version 8.05/12)
* Some Hyperion and ThunderHawk GSC cards

Further details are described here:
http://parisc-linux.org/faq/graphics-howto.htmlSigned-off-by: NHelge Deller <deller@gmx.de>
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Grant Grundler <grundler@parisc-linux.org>
Cc: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus 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: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The fourth bit of the background color is the blink property bit, not the
intensity bit, as for the foreground color.  Therefore it shouldn't be
included in the background color.
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Make logo_height variable local in the only function it is used.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

mdacon incorrectly detects MDA hardware on systems without such graphics card.

One may load this module by chance, for example when doing some systematical
module-testing, and if there is no Monochrome Display Adapter attached ,
module init renders vc1-16 completely unusable.

I and others have run into this more than once.  see [Bug 224522 - modprobe
mdacon freezes machine -> https://bugzilla.novell.com/show_bug.cgi?id=224522 ]
for example

Apparently  proper MDA detection seems to be broken for a long time - seems to
be related to those #ifdef TEST_MDA_B statements added by Edward Betts.

this commit back in 2002 made things even worse :
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=c72757b49c88914433244757fb4967fc63546685

It changed default vc allocation from 13-16 to 1-16 for no apparent reason
(!?) , and with that (and without X), mdacon grabs the vc you`re currently
sitting on and locks you out.

this is from Kconfig :
>config MDA_CONSOLE
>        depends on !M68K && !PARISC && ISA
>        tristate "MDA text console (dual-headed) (EXPERIMENTAL)"
>        ---help---
>          Say Y here if you have an old MDA or monochrome Hercules graphics
>          adapter in your system acting as a second head ( = video card). You
>          will then be able to use two monitors with your Linux system. Do not
>          say Y here if your MDA card is the primary card in your system; the
>          normal VGA driver will handle it.

As we can see mdacon is just meant as an additional driver for dual-head
setup, and since kernel 2.4.36 still defaults to vc13-16 , setting the default
back to that value again shouldn`t do any harm.

Hereby i'm reverting that change, setting default back to to vc13-16 again.

Besides the fact that mdacon may be rarely or never be used these days and
could perhaps put to trash anyway (pre-dinosaur hardware!), indeed this is not
a real solution, but at least it removes the unfortunate side-effect of
messing up the vc you`re working on.
Signed-off-by: NRoland Kletzing <devzero@web.de>
Cc: James Simmons <jsimmons@infradead.org>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Tim Schmielau <tim@physik3.uni-rostock.de>
Cc: Jan Engelhardt <jengelh@gmx.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

device_create() is race-prone, so use the race-free
device_create_drvdata() instead as device_create() is going away.

Cc: Antonino Daplas <adaplas@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

The interlaced and double line mode bits should not be copied to new
console when the console is switched.  Otherwise, the new console may be
set to incorrect refresh rate.

Also, the x and y offsets does not need to be copied.
Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Another addendum to commit c9e587ab
("vt: fix background color on line feed").

fbcon still was not doing the right thing (read: continued to do old
behavior).  fbcon_clear() seems to clear the new line (e.g.  where your new
prompt appears after doing echo -en "\e[42mfoo\n"), while scr_memsetw clears
the previous one only (where "foo" appears).  So just temporarily set the
video_erase_char to the scrl_erase_char so that fbcon_clear does the right
thing.
Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Addendum to commit c9e587ab ("vt: fix
background color on line feed").

vc->vc_scrl_erase_char was not updated when fbcon switches between
256- and 512-glyph fonts.
Signed-off-by: NJan Engelhardt <jengelh@medozas.de>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus 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: NJan 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: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: NHarvey Harrison <harvey.harrison@gmail.com>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Antonino A. Daplas <adaplas@gmail.com>
Cc: Antonino Daplas <adaplas@pol.net>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Adrian Bunk <bunk@stusta.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>