VT binding: Make VT binding a Kconfig option
Subsystems (2)
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.
---
drivers/char/Kconfig | 17 +++++++++++++++++ drivers/char/vt.c | 43 +++++++++++++++++++++++++++---------------- 2 files changed, 44 insertions(+), 16 deletions(-)
drivers/char/Kconfig +17 -0
@@ -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---
drivers/char/vt.c +27 -16
61 lines not on this page · raw message
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 3 lines · Jon Smirl
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.
Quoted 2 lines
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.
Quoted 5 lines
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).
Quoted 2 lines
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
Quoted 4 lines
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.
Quoted 4 lines
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
Quoted 8 lines · Antonino A. Daplas
Quoted 3 lines · Jon Smirl
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?
Quoted 10 lines
or would it be better for each driver to set in a
Quoted 4 lines
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?
Signature · 2 lines
Jon Smirl [email protected]
Quoted 13 lines · Jon Smirl
Quoted 8 lines · Antonino A. Daplas
Quoted 3 lines · Jon Smirl
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
Quoted 8 lines
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 7 lines
Quoted 7 lines
or would it be better for each driver to set in a
Quoted 4 lines
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.
Quoted 6 lines
Quoted 4 lines
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.
Quoted 1 line
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
Quoted 6 lines · Antonino A. Daplas
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 11 lines
Quoted 1 line
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 1 line
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.
Signature · 2 lines
Jon Smirl [email protected]
Quoted 9 lines · Jon Smirl
Quoted 3 lines · Antonino A. Daplas
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_usermodehelperexample. 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
Quoted 6 lines · Antonino A. Daplas
Quoted 5 lines · Jon Smirl
Quoted 3 lines · Antonino A. Daplas
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.
Quoted 8 lines
Quoted 4 lines
Might be a good place for a little
call_usermodehelperexample. 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->useranduser->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.
Signature · 2 lines
Jon Smirl [email protected]