Bug 43500 - [patch] rc.syscons "allscreens" improvements
Summary: [patch] rc.syscons "allscreens" improvements
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 4.6-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-09-30 02:20 UTC by Gary W. Swearingen
Modified: 2017-12-31 22:37 UTC (History)
0 users

See Also:


Attachments
file.diff (1.47 KB, patch)
2002-09-30 02:20 UTC, Gary W. Swearingen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gary W. Swearingen 2002-09-30 02:20:01 UTC
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
================
Comment 1 Dima Dorfman 2002-09-30 20:18:03 UTC
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?
Comment 2 Gary W. Swearingen 2002-10-01 18:19:08 UTC
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.)
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:01 UTC
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