[PATCH 3/9] VT binding: Make VT binding a Kconfig option

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 <redacted>
---

 drivers/char/Kconfig |   17 +++++++++++++++++
 drivers/char/vt.c    |   43 +++++++++++++++++++++++++++----------------
 2 files changed, 44 insertions(+), 16 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 29afe21..336aa31 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig

@@ -62,6 +62,23 @@ config HW_CONSOLE
 	depends on VT && !S390 && !UML
 	default y
 
+config VT_HW_CONSOLE_BINDING
+       bool "Support for binding and unbinding console drivers"
+       depends on HW_CONSOLE
+       default n
+       ---help---
+         The virtual terminal is the device that interacts with the physical
+         terminal through console drivers. On these systems, at least one
+         console driver is loaded. In other configurations, additional console
+         drivers may be enabled, such as the framebuffer console. If more than
+         1 console driver is enabled, setting this to 'y' will allow you to
+         select the console driver that will serve as the backend for the
+         virtual terminals.
+
+	 See <file:Documentation/console/console.txt> for more
+	 information. For framebuffer console users, please refer to
+	 <file:Documentation/fb/fbcon.txt>.
+
 config SERIAL_NONSTANDARD
 	bool "Non-standard serial port support"
 	---help---

diff --git a/drivers/char/vt.c b/drivers/char/vt.c
index d0cc421..1d98151 100644
--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c

@@ -2691,22 +2691,6 @@ #include <linux/device.h>
 
 static struct class *vtconsole_class;
 
-static int con_is_graphics(const struct consw *csw, int first, int last)
-{
-	int i, retval = 0;
-
-	for (i = first; i <= last; i++) {
-		struct vc_data *vc = vc_cons[i].d;
-
-		if (vc && vc->vc_mode == KD_GRAPHICS) {
-			retval = 1;
-			break;
-		}
-	}
-
-	return retval;
-}
-
 static int bind_con_driver(const struct consw *csw, int first, int last,
 			   int deflt)
 {

@@ -2808,6 +2792,23 @@ err:
 	return retval;
 };
 
+#ifdef CONFIG_VT_HW_CONSOLE_BINDING
+static int con_is_graphics(const struct consw *csw, int first, int last)
+{
+	int i, retval = 0;
+
+	for (i = first; i <= last; i++) {
+		struct vc_data *vc = vc_cons[i].d;
+
+		if (vc && vc->vc_mode == KD_GRAPHICS) {
+			retval = 1;
+			break;
+		}
+	}
+
+	return retval;
+}
+
 static int unbind_con_driver(const struct consw *csw, int first, int last,
 			     int deflt)
 {

@@ -2977,6 +2978,16 @@ static int vt_unbind(struct con_driver *
 err:
 	return 0;
 }
+#else
+static inline int vt_bind(struct con_driver *con)
+{
+	return 0;
+}
+static inline int vt_unbind(struct con_driver *con)
+{
+	return 0;
+}
+#endif /* CONFIG_VT_HW_CONSOLE_BINDING */
 
 static ssize_t store_bind(struct class_device *class_device,
 			  const char *buf, size_t count)

I gave this patch a try and it seems to work. I say seems because I
could not get the nvidiafb driver to set a usable mode after it was
bound/unbound. That's not a problem with the patch, the patch is not
addressing that issue. I tried vbetool but it kept GPFing. This is a
patch to help developers so maybe someone will fix nvidiafb to be more
friendly.

Is there any way to lessen this problem? Would it help if fbcon worked
with text modes, or would it be better for each driver to set in a
default mode that it understands when it gets control? The fbdev
driver should not set a mode when it loads, but that doesn't mean
fbcon can't set one when it is activated. Similarly VGAcon would set
the mode (and load its fonts) when it regains control.

It would also be interesting to make VGAcon a modular driver. You
could build in fbcon and then work on VGAcon.

-- 
Jon Smirl
jonsmirl@gmail.com

Jon Smirl wrote:

I gave this patch a try and it seems to work. I say seems because I
could not get the nvidiafb driver to set a usable mode after it was
bound/unbound.

What do you mean by this?  You mean that you cannot restore vgacon?
If that's the case, then yes, that is perfectly understandable as
nvidiafb does not restore VGA to text mode.

That's not a problem with the patch, the patch is not
addressing that issue. I tried vbetool but it kept GPFing.

I use nvidiafb, and vbetool works for me. It probably depends on the
hardware. Some nvidia cards have faulty BIOS'es and this has been reported
several times, at least when using nvidia cards with vesafb-tng.

This is a
patch to help developers so maybe someone will fix nvidiafb to be more
friendly.

Is there any way to lessen this problem?

The best and simplest way is to make nvidiafb behave like i810fb and rivafb
where they completely restore the VGA hardware to text mode. Hopefully
adding this is not as difficult as it sounds. (I'll see if I can work on
this within this week).

 Would it help if fbcon worked
with text modes,

fbcon does work with text mode. One developer converted viafb to work
this way.  Each driver must be converted separately though.
 
 or would it be better for each driver to set in a

default mode that it understands when it gets control? The fbdev
driver should not set a mode when it loads, but that doesn't mean
fbcon can't set one when it is activated. Similarly VGAcon would set
the mode (and load its fonts) when it regains control.

The problem with vgacon setting its own mode is that it does not know
anything about the hardware. So VGA text mode will need to rely on
a secondary program to set the mode (whether it's vbetool, another
fb driver, or X does not matter).

A standalone vga text driver is next to impossible to do.

It would also be interesting to make VGAcon a modular driver. You
could build in fbcon and then work on VGAcon.

This is very doable.  Add a module_init() for vgacon where it calls
take_over_console(). And make sure the system driver points to
dummycon.

Tony

On 6/19/06, Antonino A. Daplas [off-list ref] wrote:

Jon Smirl wrote:

quoted

I gave this patch a try and it seems to work. I say seems because I
could not get the nvidiafb driver to set a usable mode after it was
bound/unbound.

What do you mean by this?  You mean that you cannot restore vgacon?
If that's the case, then yes, that is perfectly understandable as
nvidiafb does not restore VGA to text mode.

modprobe fbcon
modprobe nvidiafb

Display is messed up.

I used to fix this by switching to X and back but the nvidia X driver
won't build on the mm kernel. I can try again and write a script to
echo a mode into sysfs after the modprobe.

When fbcon first gets a new fbdev driver registered with it, should it
pick one of the modes is supports and set it automatically?

 or would it be better for each driver to set in a

quoted

default mode that it understands when it gets control? The fbdev
driver should not set a mode when it loads, but that doesn't mean
fbcon can't set one when it is activated. Similarly VGAcon would set
the mode (and load its fonts) when it regains control.

The problem with vgacon setting its own mode is that it does not know
anything about the hardware. So VGA text mode will need to rely on
a secondary program to set the mode (whether it's vbetool, another
fb driver, or X does not matter).

How does vbetool save state? Could VGAcon do whatever vbetool is doing?

-- 
Jon Smirl
jonsmirl@gmail.com

Jon Smirl wrote:

On 6/19/06, Antonino A. Daplas [off-list ref] wrote:

quoted

Jon Smirl wrote:

quoted

I gave this patch a try and it seems to work. I say seems because I
could not get the nvidiafb driver to set a usable mode after it was
bound/unbound.

What do you mean by this?  You mean that you cannot restore vgacon?
If that's the case, then yes, that is perfectly understandable as
nvidiafb does not restore VGA to text mode.

modprobe fbcon
modprobe nvidiafb

Display is messed up.

I used to fix this by switching to X and back but the nvidia X driver
won't build on the mm kernel. I can try again and write a script to
echo a mode into sysfs after the modprobe.

When fbcon first gets a new fbdev driver registered with it, should it
pick one of the modes is supports and set it automatically?

All fbdev drivers have a startup mode that should always be valid. All
fbcon does is enable that mode.

You can load nvidiafb like this instead:

modprobe nvidiafb mode_option=1024x768@60

quoted

 or would it be better for each driver to set in a

quoted

default mode that it understands when it gets control? The fbdev
driver should not set a mode when it loads, but that doesn't mean
fbcon can't set one when it is activated. Similarly VGAcon would set
the mode (and load its fonts) when it regains control.

The problem with vgacon setting its own mode is that it does not know
anything about the hardware. So VGA text mode will need to rely on
a secondary program to set the mode (whether it's vbetool, another
fb driver, or X does not matter).

How does vbetool save state?

vbetool basically calls an int10 function that saves the state.  This
function is unique per video BIOS, ie you cannot use the state file in
another machine even if the graphics chipset is the same.

Could VGAcon do whatever vbetool is doing?

 
No it can't.  Once the card is in graphics mode, vgacon cannot go to
text mode on its own.  It has to know how to write to other VGA
registers which are unique per hardware.

Tony

On 6/20/06, Antonino A. Daplas [off-list ref] wrote:

All fbdev drivers have a startup mode that should always be valid. All
fbcon does is enable that mode.

You can load nvidiafb like this instead:

modprobe nvidiafb mode_option=1024x768@60

Good idea, it didn't occur to me to use the module parameters. Doing
it that way I can see what I am doing instead of typing blind.

quoted

How does vbetool save state?

vbetool basically calls an int10 function that saves the state.  This
function is unique per video BIOS, ie you cannot use the state file in
another machine even if the graphics chipset is the same.

quoted

Could VGAcon do whatever vbetool is doing?

No it can't.  Once the card is in graphics mode, vgacon cannot go to
text mode on its own.  It has to know how to write to other VGA
registers which are unique per hardware.

Might be a good place for a little call_usermodehelper example. VGAcon
could try calling vbetool to save it's state and restore it. GregKH
told me that the class firmware loader code was the place to start.

-- 
Jon Smirl
jonsmirl@gmail.com

Jon Smirl wrote:

On 6/20/06, Antonino A. Daplas [off-list ref] wrote:

quoted

No it can't.  Once the card is in graphics mode, vgacon cannot go to
text mode on its own.  It has to know how to write to other VGA
registers which are unique per hardware.

Might be a good place for a little call_usermodehelper example. VGAcon
could try calling vbetool to save it's state and restore it. GregKH
told me that the class firmware loader code was the place to start.

Yes, that's part of the plan. I'm still looking for the best inteface
to do that. It must be a 2-way inteface, ie, kernel->user and user->kernel.
Does the firmware loader code satisfy the above condition?

Tony 

On 6/20/06, Antonino A. Daplas [off-list ref] wrote:

Jon Smirl wrote:

quoted

On 6/20/06, Antonino A. Daplas [off-list ref] wrote:

quoted

No it can't.  Once the card is in graphics mode, vgacon cannot go to
text mode on its own.  It has to know how to write to other VGA
registers which are unique per hardware.

Might be a good place for a little call_usermodehelper example. VGAcon
could try calling vbetool to save it's state and restore it. GregKH
told me that the class firmware loader code was the place to start.

Yes, that's part of the plan. I'm still looking for the best inteface
to do that. It must be a 2-way inteface, ie, kernel->user and user->kernel.
Does the firmware loader code satisfy the above condition?

Currently the firmware loader  uses call_userhelper on a fixed helper
app. The code would need to be generalized so that you can call an
arbitrary app with your own parameters. Two communication while
running can be achieved via sysfs. Request firmware currently does two
way communication.

This thread should help.
http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=111129164916712&w=2

My thoughts are that it would be better to generalize the firmware
loader code that to build another version of it in the graphics code.

There are several later threads on the subject. Add me to the cc if
you start discussing this on hotplug-devel.

If I remember the discussions right request firmware is kind of broken
right now since it loads all of the firmware through a single place in
sysfs. Instead it should load the firmware by creating attributes on
the specific devices instead of having one attribute for everything.
Fixing it to allow parameters on the user space call is needed to tell
the user space script where to look for the device.

Request firmware is a very small amount of code and easy to modify.

-- 
Jon Smirl
jonsmirl@gmail.com