To enable this feature, CONFIG_VT_HW_CONSOLE_BINDING must be set to 'y'. This
feature will default to 'n' to minimize users accidentally corrupting their
virtual terminals.
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 sysfs control to the VT layer. A new sysfs class, 'vtconsole', and class
devices 'vtcon[n]' are added. Each class device file has the following
attributes:
/sys/class/vtconsole/vtcon[n]/name - read-only attribute showing the
name of the current backend
/sys/class/vtconsole/vtcon[n]/bind - read/write attribute
where: 0 - backend is unbound/unbind backend from the VT layer
1 - backend is bound/bind backend to the VT layer
In addition, if any of the consoles are in KD_GRAPHICS mode, binding and
unbinding will not succeed. KD_GRAPHICS mode usually indicates that the
underlying console hardware is used for other purposes other than displaying
text (ie X). This feature should prevent binding/unbinding from interfering
with a graphics application using the VT.
[akpm@osdl.org: warning fixes]
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The framebuffer console is now able to dynamically bind and unbind from the VT
console layer. Due to the way the VT console layer works, the drivers
themselves decide when to bind or unbind. However, it was decided that
binding must be controlled, not by the drivers themselves, but by the VT
console layer. With this, dynamic binding is possible for all VT console
drivers, not just fbcon.
Thus, the VT console layer will impose the following to all VT console
drivers:
- all registered VT console drivers will be entered in a private list
- drivers can register themselves to the VT console layer, but they cannot
decide when to bind or unbind. (Exception: To maintain backwards
compatibility, take_over_console() will automatically bind the driver after
registration.)
- drivers can remove themselves from the list by unregistering from the VT
console layer. A prerequisite for unregistration is that the driver must not
be bound.
The following functions are new in the vt.c:
register_con_driver() - public function, this function adds the VT console
driver to an internal list maintained by the VT console
bind_con_driver() - private function, it binds the driver to the console
take_over_console() is changed to call register_con_driver() followed by a
bind_con_driver(). This is the only time drivers can decide when to bind to
the VT layer. This is to maintain backwards compatibility.
unbind_con_driver() - private function, it unbinds the driver from its
console. The vacated consoles will be taken over by the default boot console
driver.
unregister_con_driver() - public function, removes the driver from the
internal list maintained by the VT console. It will only succeed if the
driver is currently unbound.
con_is_bound() checks if the driver is currently bound or not
give_up_console() is just a wrapper to unregister_con_driver().
There are also 3 additional functions meant to be called only by the tty layer
for sysfs control:
vt_bind() - calls bind_con_driver()
vt_unbind() - calls unbind_con_driver()
vt_show_drivers() - shows the list of registered drivers
Most VT console drivers will continue to work as is, but might have problems
when unbinding or binding which should be fixable with minimal changes.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
To allow for detaching fbcon, it must be able to give up the console.
However, the function give_up_console() is plain broken. It just sets the
entries in the console driver map to NULL, it leaves the vt layer without a
console driver, and does not decrement the module reference count. Calling
give_up_console() is guaranteed to hang the machine..
To fix this problem, ensure that the virtual consoles are not left dangling
without a driver. All systems have a default boot driver (either vgacon or
dummycon) which is never unloaded. For those vt's that lost their driver, the
default boot driver is reassigned back to them.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Delay the update of the visible framebuffer console until all other consoles
have been initialized in order to avoid losing information. This only seems
to be a problem with modules, not with built-in drivers.
Signed-off-by: David Hollister <david.hollister@amd.com>
Signed-off-by: Jordan Crouse <jordan.crouse@amd.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>
From: Andrew Morton <akpm@osdl.org>
Revert commit ff4da2e262.
It broke APM suspend, probably because APM doesn't switch back to a VT
when suspending.
Tracked down by Matt Mackall <mpm@selenic.com>
Rafael sayeth:
"It only fixed the theoretical issue that a quick-handed user could
switch to X after processes have been frozen and before the devices
are suspended.
With the current userland suspend tools it shouldn't be necessary."
Cc: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add TIOCL_GETKMSGREDIRECT needed by the userland suspend tool to get the
current value of kmsg_redirect from the kernel so that it can save it and
restore it after resume.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@suse.cz>
Cc: Michael Kerrisk <mtk-manpages@gmx.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Semaphore to mutex conversion.
The conversion was generated via scripts, and the result was validated
automatically via a script as well.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
It is unsafe to suspend devices if the hardware is controlled by X. Add an
extra check to prevent this from happening.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When moving the cursor by writing to /dev/vcs*, the old cursor image is not
erased. Fix by hiding the cursor first before moving the cursor to the new
position.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Current console blanking code is broken. It will first do a normal blank,
then start the VESA blank timer if vesa_off_interval != 0, and then proceed
to do the VESA blanking directly. After the timer expires it will do the
VESA blanking a second time. Also the vesa_powerdown() function doesn't
allow all VESA modes to be used.
With this patch the behaviour is:
1. Blank: vesa_off_interval != 0 -> Do normal blank
vesa_off_interval == 0 -> Do VESA blank
2. Start the VESA blank timer if vesa_off_interval != 0 and
vesa_power_mode != 0.
It also gets rid of the limiting vesa_powerdown() function.
Signed-off-by: Ville Syrjala <syrjala@sci.fi>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
In the unlikely case of the new screen width much wider then the old,
use (old_row_size * new_rows) instead of new_screen_size to prevent a
buffer overrun during the copy.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
On a vc resize, the contents of the old screen buffer are transferred to the
new screenbuffer. If the new screenbuffer is smaller than the old one, only
the contents from the bottom are copied to new. If the contents of the old
buffer are located at the top, then the contents will not be copied to the new
buffer resulting in a blank screen.
This bug will happen only if the vc in question is not in the foreground.
Doing an fbset -a or con2fbmap will trigger this bug.
To fix this problem, base the start of the copy from the location of the
current cursor. If the cursor is near the top of the buffer, copy the
contents at the top, and if the cursor is near the bottom of the buffer, then
copy the contents at the bottom. In the unlikely case where the new row size
is greater than 2x smaller than the old one, and the cursor is in the middle,
copy 1/2 screenful from the top and bottom of the cursor position.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Based on a patch from Andr Pereira de Almeida <andre@cachola.com.br>
It might be possible for the saved pointer (*p) to become invalid in
between vc_resizes, so saving the screen offset instead of the screen
pointer is saner.
This bug is very hard to trigger though, but Andre probably did, if he's
submitting this patch. Anyway, with Andre's patch, it's still possible for
the offsets to be still illegal, if the new screen size is smaller than the
old one. So I've also added checks if the offsets are still within the
screenbuffer size.
Signed-off-by: Antonino Daplas <adaplas@pol.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I've had WARN_CONSOLE_UNLOCKED warnings when calling TIOCLINUX
TIOCL_BLANKSCREEN and TIOCL_UNBLANKSCREEN.
(I'm blind and I use a braille display. I use those functions to blank my
laptop's screen so people don't read it, and hopefully to conserve power.)
The warnings are from these places:
do_blank_screen at drivers/char/vt.c:2754 (Not tainted)
save_screen at drivers/char/vt.c:575 (Not tainted)
do_unblank_screen at drivers/char/vt.c:2822 (Not tainted)
set_palette at drivers/char/vt.c:2908 (Not tainted)
At a glance I would think the following patch ought to fix that. Tested on
one machine. Could you please tell me if this is correct and/or forward
the patch where appropriate...
Signed-off-by: Stephane Doyon <s.doyon@videotron.ca>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[ Same race and same patch also by Steven Rostedt <rostedt@goodmis.org> ]
I have a laptop (G3 powerbook) which will pretty reliably hit a race
between con_open and con_close late in the boot process and oops in
vt_ioctl due to tty->driver_data being NULL.
What happens is this: process A opens /dev/tty6; it comes into
con_open() (drivers/char/vt.c) and assign a non-NULL value to
tty->driver_data. Then process A closes that and concurrently process
B opens /dev/tty6. Process A gets through con_close() and clears
tty->driver_data, since tty->count == 1. However, before process A
can decrement tty->count, we switch to process B (e.g. at the
down(&tty_sem) call at drivers/char/tty_io.c line 1626).
So process B gets to run and comes into con_open with tty->count == 2,
as tty->count is incremented (in init_dev) before con_open is called.
Because tty->count != 1, we don't set tty->driver_data. Then when the
process tries to do anything with that fd, it oopses.
The simple and effective fix for this is to test tty->driver_data
rather than tty->count in con_open. The testing and setting of
tty->driver_data is serialized with respect to the clearing of
tty->driver_data in con_close by the console_sem. We can't get a
situation where con_open sees tty->driver_data != NULL and then
con_close on a different fd clears tty->driver_data, because
tty->count is incremented before con_open is called. Thus this patch
eliminates the race, and in fact with this patch my laptop doesn't
oops.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[ Same patch
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When significant delays happen during boot (e.g. with a kernel debugger,
but the problem has also seen in other cases) the timeout for blanking the
console may trigger, but the work scheduler may not have been initialized,
yet. schedule_work() will oops over the null keventd_wq.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
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!
