Bug 43500
| Summary: | [patch] rc.syscons "allscreens" improvements | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Gary W. Swearingen <swear> | ||||
| Component: | conf | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||
| Status: | Closed Overcome By Events | ||||||
| Severity: | Affects Only Me | CC: | imp | ||||
| Priority: | Normal | Keywords: | patch | ||||
| Version: | 4.6-STABLE | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
Gary W. Swearingen <swear@attbi.com> wrote: > 2) If "allscreens_flags" is used to try to change the video mode to > one of the VESA* or 132* modes, the script will fail to do so unless > the "vesa" module has been built into the kernel; the module won't > even auto-load. It's better to make the script more robust (by > trying to load the module, if needed) than to force users to rebuild > their kernel or otherwise fix the problem. If the module fails to > load because it wasn't built, it will give an additional clue for the > error message which will follow when the mode change is attempted. This seems like the wrong place to do that. Perhaps it's possible (I haven't looked) for vidcontrol to load the module when it realizes that it needs it, or does it not have that information? Dima Dorfman <dima@trit.org> writes: > This seems like the wrong place to do that. Perhaps it's possible (I > haven't looked) for vidcontrol to load the module when it realizes > that it needs it, or does it not have that information? Good idea, so it handles the problem for any use of the program. Instead of hacking vidcontrol source, I'd probably move vidcontrol to /usr/libexec and replace it with a script to do the module thing, because it's easy to do and easy to undo (and more likely to be undone) if the "vesa" module is ever made auto-loadable (the best fix), but I suppose that sort of thing isn't done. Unless there's an eager C hacker ready to jump on this, I think it'd be best to just put the small tested kludge in rc.syscons and move on to more important things. (FYI, there are other video modes which require non-modular kernel support or video card support, either of which might be missing.) For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped Keyword:
patch
or patch-ready
– in lieu of summary line prefix:
[patch]
* bulk change for the keyword
* summary lines may be edited manually (not in bulk).
Keyword descriptions and search interface:
<https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
Unfortunately, /etc/rc.syscons has been retired since: commit 4b065e2ce139ddf9505a09c68395a0b807d68513 Author: Doug Barton <dougb@FreeBSD.org> Date: Fri May 2 05:27:35 2003 +0000 which isn't long after this patch. The new file is etc/rc.d/syscons and retains much of the original file. However, Problem #1 went away with defvs, so is no longer relevant. Problem #2 is OBE IMHO. Most people use drm to get bigger consoles and VESA is compiled in by default. |
This patch fixes several problems related to the use of the envars "allscreens_flags" and "allscreens_kbdflags" in the /etc/rc.syscons file: 1) If either envar is used error message noise will appear in the boot messages if the kernel is not configured to have a virtual terminal for each of the /dev/ttyv* files. The standard /dev/MAKEFILE makes 12, while some users will have built a kernel MAXCONS reduced from the default 16 to something less than 12. It's better to make the script more robust than to force such users to mess with /dev/ttyv* and MAKEDEV files (eg, during upgrades), especially since it's an easy change. 2) If "allscreens_flags" is used to try to change the video mode to one of the VESA* or 132* modes, the script will fail to do so unless the "vesa" module has been built into the kernel; the module won't even auto-load. It's better to make the script more robust (by trying to load the module, if needed) than to force users to rebuild their kernel or otherwise fix the problem. If the module fails to load because it wasn't built, it will give an additional clue for the error message which will follow when the mode change is attempted. 3) The "allscreens" use of vidcontrol and kbdcontrol were attempting (only partially successfully) to redirect stdout and stderr to the VT being configured instead of to the current terminal (the console) where it would be more likely to be noticed. ================ Fix: 1) Script determines which device files have VTs configured. 2) Script loads "vesa" module if needed and not already loaded. (It can be already loaded after shutting down to single-user mode and then exiting back to multi-user mode.) 3) Script allows vidcontrol and kbdcontrol to output to the console. How-To-Repeat: n/a ================