- 27 6月, 2006 3 次提交
-
-
由 Antonino A. Daplas 提交于
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: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Antonino A. Daplas 提交于
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: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 David Hollister 提交于
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: NDavid Hollister <david.hollister@amd.com> Signed-off-by: NJordan Crouse <jordan.crouse@amd.com> Signed-off-by: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 01 6月, 2006 1 次提交
-
-
由 Andrew Morton 提交于
From: Andrew Morton <akpm@osdl.org> Revert commit ff4da2e2. 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: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 01 4月, 2006 1 次提交
-
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: NPavel Machek <pavel@suse.cz> Cc: Michael Kerrisk <mtk-manpages@gmx.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 23 3月, 2006 2 次提交
-
-
由 Ingo Molnar 提交于
Semaphore to mutex conversion. The conversion was generated via scripts, and the result was validated automatically via a script as well. Signed-off-by: NIngo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Rafael J. Wysocki 提交于
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: NRafael J. Wysocki <rjw@sisk.pl> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 02 2月, 2006 1 次提交
-
-
由 Antonino A. Daplas 提交于
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: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 11 1月, 2006 1 次提交
-
-
由 Ville Syrjala 提交于
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: NVille Syrjala <syrjala@sci.fi> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 15 9月, 2005 1 次提交
-
-
由 Antonino A. Daplas 提交于
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: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 10 9月, 2005 1 次提交
-
-
由 Antonino A. Daplas 提交于
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: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 08 9月, 2005 2 次提交
-
-
由 Antonino A. Daplas 提交于
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: NAntonino Daplas <adaplas@pol.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Stephane Doyon 提交于
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: NStephane Doyon <s.doyon@videotron.ca> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 28 8月, 2005 1 次提交
-
-
由 Paul Mackerras 提交于
[ 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: NPaul Mackerras <paulus@samba.org> [ Same patch Signed-off-by: NSteven Rostedt <rostedt@goodmis.org> in http://marc.theaimsgroup.com/?l=linux-kernel&m=112450820432121&w=2 ] Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 16 7月, 2005 1 次提交
-
-
由 Nishanth Aravamudan 提交于
Signed-off-by: NNishanth Aravamudan <nacc@us.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 19 6月, 2005 1 次提交
-
-
由 Jan Beulich 提交于
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: NJan Beulich <jbeulich@novell.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-