1994-08-17 09:00:13 +00:00
|
|
|
/*-
|
2017-11-27 15:37:16 +00:00
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
*
|
2011-12-30 00:59:08 +00:00
|
|
|
* Copyright (c) 1994-1996 Søren Schmidt
|
1994-08-17 09:00:13 +00:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
* Portions of this software are based in part on the work of
|
|
|
|
* Sascha Wildner <saw@online.de> contributed to The DragonFly Project
|
|
|
|
*
|
1994-08-17 09:00:13 +00:00
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
1995-01-28 22:18:05 +00:00
|
|
|
* notice, this list of conditions and the following disclaimer,
|
|
|
|
* in this position and unchanged.
|
1994-08-17 09:00:13 +00:00
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
* 3. The name of the author may not be used to endorse or promote products
|
2002-06-02 20:05:59 +00:00
|
|
|
* derived from this software without specific prior written permission
|
1994-08-17 09:00:13 +00:00
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
*
|
|
|
|
* $DragonFly: src/usr.sbin/vidcontrol/vidcontrol.c,v 1.10 2005/03/02 06:08:29 joerg Exp $
|
1994-08-17 09:00:13 +00:00
|
|
|
*/
|
|
|
|
|
1997-10-27 07:52:10 +00:00
|
|
|
#ifndef lint
|
|
|
|
static const char rcsid[] =
|
1999-08-28 01:35:59 +00:00
|
|
|
"$FreeBSD$";
|
1997-10-27 07:52:10 +00:00
|
|
|
#endif /* not lint */
|
|
|
|
|
1994-08-17 09:00:13 +00:00
|
|
|
#include <ctype.h>
|
1997-10-27 07:52:10 +00:00
|
|
|
#include <err.h>
|
2000-01-12 12:30:33 +00:00
|
|
|
#include <limits.h>
|
1994-08-17 09:00:13 +00:00
|
|
|
#include <stdio.h>
|
1997-03-07 01:34:47 +00:00
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
1997-10-27 07:52:10 +00:00
|
|
|
#include <unistd.h>
|
2000-10-08 21:34:00 +00:00
|
|
|
#include <sys/fbio.h>
|
|
|
|
#include <sys/consio.h>
|
2014-05-29 13:09:48 +00:00
|
|
|
#include <sys/endian.h>
|
1994-08-17 09:00:13 +00:00
|
|
|
#include <sys/errno.h>
|
2014-05-29 13:09:48 +00:00
|
|
|
#include <sys/param.h>
|
2001-04-09 17:24:29 +00:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <sys/stat.h>
|
2014-05-29 13:09:48 +00:00
|
|
|
#include <sys/sysctl.h>
|
1994-08-17 09:00:13 +00:00
|
|
|
#include "path.h"
|
1997-03-07 01:34:47 +00:00
|
|
|
#include "decode.h"
|
1994-08-17 09:00:13 +00:00
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
#define DATASIZE(x) ((x).w * (x).h * 256 / 8)
|
2001-01-25 16:53:22 +00:00
|
|
|
|
2002-08-19 16:33:23 +00:00
|
|
|
/* Screen dump modes */
|
|
|
|
#define DUMP_FMT_RAW 1
|
|
|
|
#define DUMP_FMT_TXT 2
|
|
|
|
/* Screen dump options */
|
|
|
|
#define DUMP_FBF 0
|
|
|
|
#define DUMP_ALL 1
|
|
|
|
/* Screen dump file format revision */
|
2001-05-19 06:47:36 +00:00
|
|
|
#define DUMP_FMT_REV 1
|
|
|
|
|
2011-12-11 21:02:33 +00:00
|
|
|
static const char *legal_colors[16] = {
|
1994-08-17 09:00:13 +00:00
|
|
|
"black", "blue", "green", "cyan",
|
|
|
|
"red", "magenta", "brown", "white",
|
|
|
|
"grey", "lightblue", "lightgreen", "lightcyan",
|
|
|
|
"lightred", "lightmagenta", "yellow", "lightwhite"
|
1995-02-22 13:48:07 +00:00
|
|
|
};
|
1994-08-17 09:00:13 +00:00
|
|
|
|
2012-10-19 14:49:42 +00:00
|
|
|
static struct {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
int active_vty;
|
|
|
|
vid_info_t console_info;
|
|
|
|
unsigned char screen_map[256];
|
|
|
|
int video_mode_number;
|
|
|
|
struct video_info video_mode_info;
|
|
|
|
} cur_info;
|
|
|
|
|
2011-12-11 21:02:33 +00:00
|
|
|
static int hex = 0;
|
|
|
|
static int vesa_cols;
|
|
|
|
static int vesa_rows;
|
|
|
|
static int font_height;
|
2014-05-29 13:09:48 +00:00
|
|
|
static int vt4_mode = 0;
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
static int video_mode_changed;
|
2011-12-11 21:02:33 +00:00
|
|
|
static struct video_info new_mode_info;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize revert data.
|
|
|
|
*
|
|
|
|
* NOTE: the following parameters are not yet saved/restored:
|
|
|
|
*
|
|
|
|
* screen saver timeout
|
|
|
|
* cursor type
|
|
|
|
* mouse character and mouse show/hide state
|
|
|
|
* vty switching on/off state
|
|
|
|
* history buffer size
|
|
|
|
* history contents
|
|
|
|
* font maps
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void
|
|
|
|
init(void)
|
|
|
|
{
|
|
|
|
if (ioctl(0, VT_GETACTIVE, &cur_info.active_vty) == -1)
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "getting active vty");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
cur_info.console_info.size = sizeof(cur_info.console_info);
|
|
|
|
if (ioctl(0, CONS_GETINFO, &cur_info.console_info) == -1)
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "getting console information");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2014-05-29 13:09:48 +00:00
|
|
|
/* vt(4) use unicode, so no screen mapping required. */
|
|
|
|
if (vt4_mode == 0 &&
|
|
|
|
ioctl(0, GIO_SCRNMAP, &cur_info.screen_map) == -1)
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "getting screen map");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (ioctl(0, CONS_GET, &cur_info.video_mode_number) == -1)
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "getting video mode number");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
cur_info.video_mode_info.vi_mode = cur_info.video_mode_number;
|
|
|
|
|
|
|
|
if (ioctl(0, CONS_MODEINFO, &cur_info.video_mode_info) == -1)
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "getting video mode parameters");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If something goes wrong along the way we call revert() to go back to the
|
|
|
|
* console state we came from (which is assumed to be working).
|
|
|
|
*
|
|
|
|
* NOTE: please also read the comments of init().
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void
|
|
|
|
revert(void)
|
|
|
|
{
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
int save_errno, size[3];
|
|
|
|
|
|
|
|
save_errno = errno;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2006-09-26 21:46:12 +00:00
|
|
|
ioctl(0, VT_ACTIVATE, cur_info.active_vty);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2017-08-16 15:14:46 +00:00
|
|
|
ioctl(0, KDSBORDER, cur_info.console_info.mv_ovscan);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
fprintf(stderr, "\033[=%dH", cur_info.console_info.mv_rev.fore);
|
|
|
|
fprintf(stderr, "\033[=%dI", cur_info.console_info.mv_rev.back);
|
|
|
|
|
2014-05-29 13:09:48 +00:00
|
|
|
if (vt4_mode == 0)
|
|
|
|
ioctl(0, PIO_SCRNMAP, &cur_info.screen_map);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
if (video_mode_changed) {
|
|
|
|
if (cur_info.video_mode_number >= M_VESA_BASE)
|
|
|
|
ioctl(0,
|
|
|
|
_IO('V', cur_info.video_mode_number - M_VESA_BASE),
|
|
|
|
NULL);
|
|
|
|
else
|
|
|
|
ioctl(0, _IO('S', cur_info.video_mode_number), NULL);
|
|
|
|
if (cur_info.video_mode_info.vi_flags & V_INFO_GRAPHICS) {
|
2019-04-08 04:07:37 +00:00
|
|
|
size[0] = cur_info.console_info.mv_csz;
|
|
|
|
size[1] = cur_info.console_info.mv_rsz;
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
size[2] = cur_info.console_info.font_size;
|
|
|
|
ioctl(0, KDRASTER, size);
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
2017-04-03 06:52:02 +00:00
|
|
|
|
|
|
|
/* Restore some colors last since mode setting forgets some. */
|
|
|
|
fprintf(stderr, "\033[=%dF", cur_info.console_info.mv_norm.fore);
|
|
|
|
fprintf(stderr, "\033[=%dG", cur_info.console_info.mv_norm.back);
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
|
|
|
|
errno = save_errno;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Print a short usage string describing all options, then exit.
|
|
|
|
*/
|
1994-08-17 09:00:13 +00:00
|
|
|
|
1997-10-27 07:52:10 +00:00
|
|
|
static void
|
2005-01-13 03:59:44 +00:00
|
|
|
usage(void)
|
1995-02-22 13:48:07 +00:00
|
|
|
{
|
2014-05-29 13:09:48 +00:00
|
|
|
if (vt4_mode)
|
2017-08-17 20:25:50 +00:00
|
|
|
fprintf(stderr, "%s\n%s\n%s\n%s\n%s\n%s\n",
|
2014-10-23 12:38:05 +00:00
|
|
|
"usage: vidcontrol [-CHPpx] [-b color] [-c appearance] [-f [[size] file]]",
|
2016-01-19 13:09:20 +00:00
|
|
|
" [-g geometry] [-h size] [-i active | adapter | mode]",
|
2017-08-17 20:25:50 +00:00
|
|
|
" [-M char] [-m on | off]",
|
|
|
|
" [-r foreground background] [-S on | off] [-s number]",
|
|
|
|
" [-T xterm | cons25] [-t N | off] [mode]",
|
|
|
|
" [foreground [background]] [show]");
|
2014-05-29 13:09:48 +00:00
|
|
|
else
|
2017-08-17 20:25:50 +00:00
|
|
|
fprintf(stderr, "%s\n%s\n%s\n%s\n%s\n%s\n",
|
2019-02-22 06:41:47 +00:00
|
|
|
"usage: vidcontrol [-CdHLPpx] [-b color] [-c appearance] [-E emulator]",
|
|
|
|
" [-f [[size] file]] [-g geometry] [-h size]",
|
|
|
|
" [-i active | adapter | mode] [-l screen_map] [-M char]",
|
|
|
|
" [-m on | off] [-r foreground background] [-S on | off]",
|
|
|
|
" [-s number] [-T xterm | cons25] [-t N | off] [mode]",
|
2017-08-17 18:08:45 +00:00
|
|
|
" [foreground [background]] [show]");
|
1997-10-27 07:52:10 +00:00
|
|
|
exit(1);
|
1995-02-22 13:48:07 +00:00
|
|
|
}
|
|
|
|
|
2014-05-29 13:09:48 +00:00
|
|
|
/* Detect presence of vt(4). */
|
|
|
|
static int
|
|
|
|
is_vt4(void)
|
|
|
|
{
|
2014-07-02 20:40:59 +00:00
|
|
|
char vty_name[4] = "";
|
|
|
|
size_t len = sizeof(vty_name);
|
2014-05-29 13:09:48 +00:00
|
|
|
|
2014-07-02 20:40:59 +00:00
|
|
|
if (sysctlbyname("kern.vty", vty_name, &len, NULL, 0) != 0)
|
|
|
|
return (0);
|
|
|
|
return (strcmp(vty_name, "vt") == 0);
|
2014-05-29 13:09:48 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Retrieve the next argument from the command line (for options that require
|
|
|
|
* more than one argument).
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static char *
|
2001-04-09 17:24:29 +00:00
|
|
|
nextarg(int ac, char **av, int *indp, int oc, int strict)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
|
|
|
if (*indp < ac)
|
|
|
|
return(av[(*indp)++]);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (strict != 0) {
|
|
|
|
revert();
|
2001-04-09 17:24:29 +00:00
|
|
|
errx(1, "option requires two arguments -- %c", oc);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
|
2001-04-09 17:24:29 +00:00
|
|
|
return(NULL);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Guess which file to open. Try to open each combination of a specified set
|
|
|
|
* of file name components.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static FILE *
|
|
|
|
openguess(const char *a[], const char *b[], const char *c[], const char *d[], char **name)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
2002-03-16 23:35:51 +00:00
|
|
|
FILE *f;
|
|
|
|
int i, j, k, l;
|
|
|
|
|
|
|
|
for (i = 0; a[i] != NULL; i++) {
|
|
|
|
for (j = 0; b[j] != NULL; j++) {
|
|
|
|
for (k = 0; c[k] != NULL; k++) {
|
|
|
|
for (l = 0; d[l] != NULL; l++) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
asprintf(name, "%s%s%s%s",
|
|
|
|
a[i], b[j], c[k], d[l]);
|
|
|
|
|
2002-03-16 23:35:51 +00:00
|
|
|
f = fopen(*name, "r");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2002-03-16 23:35:51 +00:00
|
|
|
if (f != NULL)
|
|
|
|
return (f);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2002-03-16 23:35:51 +00:00
|
|
|
free(*name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
2002-03-16 23:35:51 +00:00
|
|
|
return (NULL);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Load a screenmap from a file and set it.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
|
|
|
load_scrnmap(const char *filename)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
2002-03-16 23:35:51 +00:00
|
|
|
FILE *fd;
|
|
|
|
int size;
|
1994-08-17 09:00:13 +00:00
|
|
|
char *name;
|
|
|
|
scrmap_t scrnmap;
|
2005-01-13 03:59:44 +00:00
|
|
|
const char *a[] = {"", SCRNMAP_PATH, NULL};
|
|
|
|
const char *b[] = {filename, NULL};
|
|
|
|
const char *c[] = {"", ".scm", NULL};
|
|
|
|
const char *d[] = {"", NULL};
|
2002-03-16 23:35:51 +00:00
|
|
|
|
|
|
|
fd = openguess(a, b, c, d, &name);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1994-08-17 09:00:13 +00:00
|
|
|
if (fd == NULL) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "screenmap file not found");
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1994-08-17 09:00:13 +00:00
|
|
|
size = sizeof(scrnmap);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-04-09 17:24:29 +00:00
|
|
|
if (decode(fd, (char *)&scrnmap, size) != size) {
|
1994-08-17 09:00:13 +00:00
|
|
|
rewind(fd);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (fread(&scrnmap, 1, size, fd) != (size_t)size) {
|
1997-03-07 01:34:47 +00:00
|
|
|
fclose(fd);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "bad screenmap file");
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (ioctl(0, PIO_SCRNMAP, &scrnmap) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "loading screenmap");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
|
1997-03-07 01:34:47 +00:00
|
|
|
fclose(fd);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the default screenmap.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
|
|
|
load_default_scrnmap(void)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
|
|
|
scrmap_t scrnmap;
|
1995-02-22 13:48:07 +00:00
|
|
|
int i;
|
1994-08-17 09:00:13 +00:00
|
|
|
|
|
|
|
for (i=0; i<256; i++)
|
|
|
|
*((char*)&scrnmap + i) = i;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (ioctl(0, PIO_SCRNMAP, &scrnmap) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "loading default screenmap");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Print the current screenmap to stdout.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
|
|
|
print_scrnmap(void)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
|
|
|
unsigned char map[256];
|
2005-01-13 03:59:44 +00:00
|
|
|
size_t i;
|
1994-08-17 09:00:13 +00:00
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if (ioctl(0, GIO_SCRNMAP, &map) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "getting screenmap");
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
for (i=0; i<sizeof(map); i++) {
|
2005-01-13 03:59:44 +00:00
|
|
|
if (i != 0 && i % 16 == 0)
|
1994-08-17 09:00:13 +00:00
|
|
|
fprintf(stdout, "\n");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (hex != 0)
|
1995-05-30 03:57:47 +00:00
|
|
|
fprintf(stdout, " %02x", map[i]);
|
1994-08-17 09:00:13 +00:00
|
|
|
else
|
|
|
|
fprintf(stdout, " %03d", map[i]);
|
|
|
|
}
|
|
|
|
fprintf(stdout, "\n");
|
|
|
|
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Determine a file's size.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static int
|
2001-04-09 17:24:29 +00:00
|
|
|
fsize(FILE *file)
|
|
|
|
{
|
|
|
|
struct stat sb;
|
|
|
|
|
|
|
|
if (fstat(fileno(file), &sb) == 0)
|
|
|
|
return sb.st_size;
|
|
|
|
else
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2014-05-29 13:09:48 +00:00
|
|
|
static vfnt_map_t *
|
|
|
|
load_vt4mappingtable(unsigned int nmappings, FILE *f)
|
|
|
|
{
|
|
|
|
vfnt_map_t *t;
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
if (nmappings == 0)
|
|
|
|
return (NULL);
|
|
|
|
|
2016-11-05 11:19:55 +00:00
|
|
|
if ((t = calloc(nmappings, sizeof(*t))) == NULL) {
|
|
|
|
warn("calloc");
|
2016-11-04 20:32:49 +00:00
|
|
|
return (NULL);
|
|
|
|
}
|
2014-05-29 13:09:48 +00:00
|
|
|
|
|
|
|
if (fread(t, sizeof *t * nmappings, 1, f) != 1) {
|
2016-11-04 20:32:49 +00:00
|
|
|
warn("read mappings");
|
|
|
|
free(t);
|
|
|
|
return (NULL);
|
2014-05-29 13:09:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < nmappings; i++) {
|
2020-06-14 06:58:58 +00:00
|
|
|
t[i].vfm_src = be32toh(t[i].vfm_src);
|
|
|
|
t[i].vfm_dst = be16toh(t[i].vfm_dst);
|
|
|
|
t[i].vfm_len = be16toh(t[i].vfm_len);
|
2014-05-29 13:09:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return (t);
|
|
|
|
}
|
|
|
|
|
2014-10-23 12:38:05 +00:00
|
|
|
/*
|
|
|
|
* Set the default vt font.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void
|
|
|
|
load_default_vt4font(void)
|
|
|
|
{
|
|
|
|
if (ioctl(0, PIO_VFONT_DEFAULT) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "loading default vt font");
|
2014-10-23 12:38:05 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-04 20:32:49 +00:00
|
|
|
static void
|
2014-05-29 13:09:48 +00:00
|
|
|
load_vt4font(FILE *f)
|
|
|
|
{
|
2020-06-14 06:58:58 +00:00
|
|
|
struct font_header fh;
|
2014-05-29 13:09:48 +00:00
|
|
|
static vfnt_t vfnt;
|
|
|
|
size_t glyphsize;
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
if (fread(&fh, sizeof fh, 1, f) != 1) {
|
2016-11-04 20:32:49 +00:00
|
|
|
warn("read file_header");
|
|
|
|
return;
|
2014-05-29 13:09:48 +00:00
|
|
|
}
|
|
|
|
|
2020-06-14 06:58:58 +00:00
|
|
|
if (memcmp(fh.fh_magic, "VFNT0002", 8) != 0) {
|
2016-11-04 20:32:49 +00:00
|
|
|
warnx("bad magic in font file\n");
|
|
|
|
return;
|
2014-05-29 13:09:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < VFNT_MAPS; i++)
|
2020-06-14 06:58:58 +00:00
|
|
|
vfnt.map_count[i] = be32toh(fh.fh_map_count[i]);
|
|
|
|
vfnt.glyph_count = be32toh(fh.fh_glyph_count);
|
|
|
|
vfnt.width = fh.fh_width;
|
|
|
|
vfnt.height = fh.fh_height;
|
2014-05-29 13:09:48 +00:00
|
|
|
|
|
|
|
glyphsize = howmany(vfnt.width, 8) * vfnt.height * vfnt.glyph_count;
|
2016-11-04 20:32:49 +00:00
|
|
|
if ((vfnt.glyphs = malloc(glyphsize)) == NULL) {
|
|
|
|
warn("malloc");
|
|
|
|
return;
|
|
|
|
}
|
2014-05-29 13:09:48 +00:00
|
|
|
|
|
|
|
if (fread(vfnt.glyphs, glyphsize, 1, f) != 1) {
|
2016-11-04 20:32:49 +00:00
|
|
|
warn("read glyphs");
|
|
|
|
free(vfnt.glyphs);
|
|
|
|
return;
|
2014-05-29 13:09:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < VFNT_MAPS; i++)
|
|
|
|
vfnt.map[i] = load_vt4mappingtable(vfnt.map_count[i], f);
|
|
|
|
|
2016-11-04 20:32:49 +00:00
|
|
|
if (ioctl(STDIN_FILENO, PIO_VFONT, &vfnt) == -1)
|
|
|
|
warn("PIO_VFONT");
|
|
|
|
|
|
|
|
for (i = 0; i < VFNT_MAPS; i++)
|
|
|
|
free(vfnt.map[i]);
|
|
|
|
free(vfnt.glyphs);
|
2014-05-29 13:09:48 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Load a font from file and set it.
|
|
|
|
*/
|
2001-04-09 17:24:29 +00:00
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
|
|
|
load_font(const char *type, const char *filename)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
2002-03-16 23:35:51 +00:00
|
|
|
FILE *fd;
|
2001-04-09 17:24:29 +00:00
|
|
|
int h, i, size, w;
|
|
|
|
unsigned long io = 0; /* silence stupid gcc(1) in the Wall mode */
|
2002-03-16 23:35:51 +00:00
|
|
|
char *name, *fontmap, size_sufx[6];
|
2005-01-13 03:59:44 +00:00
|
|
|
const char *a[] = {"", FONT_PATH, NULL};
|
2014-05-29 13:09:48 +00:00
|
|
|
const char *vt4a[] = {"", VT_FONT_PATH, NULL};
|
2005-01-13 03:59:44 +00:00
|
|
|
const char *b[] = {filename, NULL};
|
|
|
|
const char *c[] = {"", size_sufx, NULL};
|
|
|
|
const char *d[] = {"", ".fnt", NULL};
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
vid_info_t info;
|
1994-08-17 09:00:13 +00:00
|
|
|
|
2001-04-09 17:24:29 +00:00
|
|
|
struct sizeinfo {
|
|
|
|
int w;
|
|
|
|
int h;
|
|
|
|
unsigned long io;
|
|
|
|
} sizes[] = {{8, 16, PIO_FONT8x16},
|
|
|
|
{8, 14, PIO_FONT8x14},
|
|
|
|
{8, 8, PIO_FONT8x8},
|
|
|
|
{0, 0, 0}};
|
|
|
|
|
2014-05-29 13:09:48 +00:00
|
|
|
if (vt4_mode) {
|
|
|
|
size_sufx[0] = '\0';
|
|
|
|
} else {
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.size = sizeof(info);
|
|
|
|
if (ioctl(0, CONS_GETINFO, &info) == -1) {
|
2014-05-29 13:09:48 +00:00
|
|
|
revert();
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
err(1, "getting console information");
|
2014-05-29 13:09:48 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
snprintf(size_sufx, sizeof(size_sufx), "-8x%d", info.font_size);
|
2014-05-29 13:09:48 +00:00
|
|
|
}
|
|
|
|
fd = openguess((vt4_mode == 0) ? a : vt4a, b, c, d, &name);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1994-08-17 09:00:13 +00:00
|
|
|
if (fd == NULL) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "%s: can't load font file", filename);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2014-05-29 13:09:48 +00:00
|
|
|
if (vt4_mode) {
|
2016-11-04 20:32:49 +00:00
|
|
|
load_vt4font(fd);
|
2014-05-29 13:09:48 +00:00
|
|
|
fclose(fd);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2001-04-09 17:24:29 +00:00
|
|
|
if (type != NULL) {
|
|
|
|
size = 0;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if (sscanf(type, "%dx%d", &w, &h) == 2) {
|
|
|
|
for (i = 0; sizes[i].w != 0; i++) {
|
2001-04-09 17:24:29 +00:00
|
|
|
if (sizes[i].w == w && sizes[i].h == h) {
|
|
|
|
size = DATASIZE(sizes[i]);
|
|
|
|
io = sizes[i].io;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
font_height = sizes[i].h;
|
2001-04-09 17:24:29 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
}
|
2001-04-09 17:24:29 +00:00
|
|
|
if (size == 0) {
|
|
|
|
fclose(fd);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "%s: bad font size specification", type);
|
2001-04-09 17:24:29 +00:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
/* Apply heuristics */
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-04-09 17:24:29 +00:00
|
|
|
int j;
|
|
|
|
int dsize[2];
|
|
|
|
|
|
|
|
size = DATASIZE(sizes[0]);
|
|
|
|
fontmap = (char*) malloc(size);
|
|
|
|
dsize[0] = decode(fd, fontmap, size);
|
|
|
|
dsize[1] = fsize(fd);
|
|
|
|
free(fontmap);
|
|
|
|
|
|
|
|
size = 0;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
for (j = 0; j < 2; j++) {
|
|
|
|
for (i = 0; sizes[i].w != 0; i++) {
|
2001-04-09 17:24:29 +00:00
|
|
|
if (DATASIZE(sizes[i]) == dsize[j]) {
|
|
|
|
size = dsize[j];
|
|
|
|
io = sizes[i].io;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
font_height = sizes[i].h;
|
2001-04-09 17:24:29 +00:00
|
|
|
j = 2; /* XXX */
|
|
|
|
break;
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
}
|
2001-04-09 17:24:29 +00:00
|
|
|
|
|
|
|
if (size == 0) {
|
|
|
|
fclose(fd);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "%s: can't guess font size", filename);
|
2001-04-09 17:24:29 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-04-09 17:24:29 +00:00
|
|
|
rewind(fd);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
2001-04-09 17:24:29 +00:00
|
|
|
|
1994-08-17 09:00:13 +00:00
|
|
|
fontmap = (char*) malloc(size);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-04-09 17:24:29 +00:00
|
|
|
if (decode(fd, fontmap, size) != size) {
|
1994-08-17 09:00:13 +00:00
|
|
|
rewind(fd);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if (fsize(fd) != size ||
|
|
|
|
fread(fontmap, 1, size, fd) != (size_t)size) {
|
1997-03-07 01:34:47 +00:00
|
|
|
fclose(fd);
|
1994-08-17 09:00:13 +00:00
|
|
|
free(fontmap);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "%s: bad font file", filename);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (ioctl(0, io, fontmap) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "loading font");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
|
1997-03-07 01:34:47 +00:00
|
|
|
fclose(fd);
|
1994-08-17 09:00:13 +00:00
|
|
|
free(fontmap);
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the timeout for the screensaver.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
1994-08-17 09:00:13 +00:00
|
|
|
set_screensaver_timeout(char *arg)
|
|
|
|
{
|
|
|
|
int nsec;
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if (!strcmp(arg, "off")) {
|
1994-08-17 09:00:13 +00:00
|
|
|
nsec = 0;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
} else {
|
1994-08-17 09:00:13 +00:00
|
|
|
nsec = atoi(arg);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1994-08-17 09:00:13 +00:00
|
|
|
if ((*arg == '\0') || (nsec < 1)) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "argument must be a positive number");
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (ioctl(0, CONS_BLANKTIME, &nsec) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "setting screensaver period");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
|
2017-08-17 18:08:45 +00:00
|
|
|
static void
|
|
|
|
parse_cursor_params(char *param, struct cshape *shape)
|
|
|
|
{
|
|
|
|
char *dupparam, *word;
|
|
|
|
int type;
|
|
|
|
|
|
|
|
param = dupparam = strdup(param);
|
|
|
|
type = shape->shape[0];
|
|
|
|
while ((word = strsep(¶m, ",")) != NULL) {
|
2017-08-19 12:14:46 +00:00
|
|
|
if (strcmp(word, "normal") == 0)
|
2017-08-17 18:08:45 +00:00
|
|
|
type = 0;
|
|
|
|
else if (strcmp(word, "destructive") == 0)
|
|
|
|
type = CONS_BLINK_CURSOR | CONS_CHAR_CURSOR;
|
2017-08-19 12:14:46 +00:00
|
|
|
else if (strcmp(word, "blink") == 0)
|
|
|
|
type |= CONS_BLINK_CURSOR;
|
|
|
|
else if (strcmp(word, "noblink") == 0)
|
2017-08-17 18:08:45 +00:00
|
|
|
type &= ~CONS_BLINK_CURSOR;
|
2017-08-19 12:14:46 +00:00
|
|
|
else if (strcmp(word, "block") == 0)
|
2017-08-17 18:08:45 +00:00
|
|
|
type &= ~CONS_CHAR_CURSOR;
|
2017-08-19 12:14:46 +00:00
|
|
|
else if (strcmp(word, "noblock") == 0)
|
|
|
|
type |= CONS_CHAR_CURSOR;
|
2017-08-17 18:08:45 +00:00
|
|
|
else if (strcmp(word, "hidden") == 0)
|
|
|
|
type |= CONS_HIDDEN_CURSOR;
|
|
|
|
else if (strcmp(word, "nohidden") == 0)
|
|
|
|
type &= ~CONS_HIDDEN_CURSOR;
|
2017-08-19 12:14:46 +00:00
|
|
|
else if (strncmp(word, "base=", 5) == 0)
|
|
|
|
shape->shape[1] = strtol(word + 5, NULL, 0);
|
|
|
|
else if (strncmp(word, "height=", 7) == 0)
|
|
|
|
shape->shape[2] = strtol(word + 7, NULL, 0);
|
Support setting the colors of cursors for the VGA renderer.
Advertise this by changing the defaults to mostly red. If you don't like
this, change them (almost) back using:
vidcontrol -c charcolors,base=7,height=0
vidcontrol -c mousecolors,base=0[,height=15]
The (graphics mode only) mouse cursor colors were hard-coded to a black
border and lightwhite interior. Black for the border is the worst
possible default, since it is the same as the default black background
and not good for any dark background. Reversing this gives the better
default of X Windows. Coloring everything works better still. Now
the coloring defaults to a lightwhite border and red interior.
Coloring for the character cursor is more complicated and mode
dependent. The new coloring doesn't apply for hardware cursors. For
non-block cursors, it only applies in graphics mode. In text mode,
the cursor color was usually a hard-coded (dull)white for the background
only, unless the foreground was white when it was a hard-coded black
for the background only, unless the foreground was white and the
background was black it was reverse video. In graphics mode, it was
always reverse video for the block cursor. Reverse video is worse,
especially over cutmarking regions, since cutmarking still uses simple
reverse video (nothing better is possible in text mode) and double
reverse video for the cursor gives normal video. Now, graphics mode
uses the same algorithm as the best case for text mode in all cases
for graphics mode. The hard-coded sequence { white, black, } for the
background is now { red, white, blue, } where the first 2 colors can
be configured. The blue color at the end is a sentinel which prevents
reverse video being used in most cases but breaks the compatibility
setting for white on black and black on white characters. This will
be fixed later. The compatibility setting is most needed for mono modes.
The previous commit to syscons.c changed sc_cnterm() to be more careful.
It followed null pointers in some cases. But sc_cnterm() has been
unreachable for 15+ years since changes for multiple consoles turned
off calls to the the cnterm destructor for all console drivers. Before
them, it was only called at boot time. So no driver with an attached
console has ever been unloadable and not even the non-console destructors
have been tested much.
2017-08-25 07:04:41 +00:00
|
|
|
else if (strcmp(word, "charcolors") == 0)
|
|
|
|
type |= CONS_CHARCURSOR_COLORS;
|
|
|
|
else if (strcmp(word, "mousecolors") == 0)
|
|
|
|
type |= CONS_MOUSECURSOR_COLORS;
|
|
|
|
else if (strcmp(word, "default") == 0)
|
|
|
|
type |= CONS_DEFAULT_CURSOR;
|
|
|
|
else if (strcmp(word, "shapeonly") == 0)
|
|
|
|
type |= CONS_SHAPEONLY_CURSOR;
|
2017-08-17 18:08:45 +00:00
|
|
|
else if (strcmp(word, "local") == 0)
|
|
|
|
type |= CONS_LOCAL_CURSOR;
|
|
|
|
else if (strcmp(word, "reset") == 0)
|
|
|
|
type |= CONS_RESET_CURSOR;
|
Support setting the colors of cursors for the VGA renderer.
Advertise this by changing the defaults to mostly red. If you don't like
this, change them (almost) back using:
vidcontrol -c charcolors,base=7,height=0
vidcontrol -c mousecolors,base=0[,height=15]
The (graphics mode only) mouse cursor colors were hard-coded to a black
border and lightwhite interior. Black for the border is the worst
possible default, since it is the same as the default black background
and not good for any dark background. Reversing this gives the better
default of X Windows. Coloring everything works better still. Now
the coloring defaults to a lightwhite border and red interior.
Coloring for the character cursor is more complicated and mode
dependent. The new coloring doesn't apply for hardware cursors. For
non-block cursors, it only applies in graphics mode. In text mode,
the cursor color was usually a hard-coded (dull)white for the background
only, unless the foreground was white when it was a hard-coded black
for the background only, unless the foreground was white and the
background was black it was reverse video. In graphics mode, it was
always reverse video for the block cursor. Reverse video is worse,
especially over cutmarking regions, since cutmarking still uses simple
reverse video (nothing better is possible in text mode) and double
reverse video for the cursor gives normal video. Now, graphics mode
uses the same algorithm as the best case for text mode in all cases
for graphics mode. The hard-coded sequence { white, black, } for the
background is now { red, white, blue, } where the first 2 colors can
be configured. The blue color at the end is a sentinel which prevents
reverse video being used in most cases but breaks the compatibility
setting for white on black and black on white characters. This will
be fixed later. The compatibility setting is most needed for mono modes.
The previous commit to syscons.c changed sc_cnterm() to be more careful.
It followed null pointers in some cases. But sc_cnterm() has been
unreachable for 15+ years since changes for multiple consoles turned
off calls to the the cnterm destructor for all console drivers. Before
them, it was only called at boot time. So no driver with an attached
console has ever been unloadable and not even the non-console destructors
have been tested much.
2017-08-25 07:04:41 +00:00
|
|
|
else if (strcmp(word, "show") == 0)
|
|
|
|
printf("flags %#x, base %d, height %d\n",
|
|
|
|
type, shape->shape[1], shape->shape[2]);
|
2017-08-17 18:08:45 +00:00
|
|
|
else {
|
|
|
|
revert();
|
|
|
|
errx(1,
|
|
|
|
"invalid parameters for -c starting at '%s%s%s'",
|
|
|
|
word, param != NULL ? "," : "",
|
|
|
|
param != NULL ? param : "");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
free(dupparam);
|
|
|
|
shape->shape[0] = type;
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the cursor's shape/type.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
2017-08-17 18:08:45 +00:00
|
|
|
set_cursor_type(char *param)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
2017-08-17 18:08:45 +00:00
|
|
|
struct cshape shape;
|
|
|
|
|
Support setting the colors of cursors for the VGA renderer.
Advertise this by changing the defaults to mostly red. If you don't like
this, change them (almost) back using:
vidcontrol -c charcolors,base=7,height=0
vidcontrol -c mousecolors,base=0[,height=15]
The (graphics mode only) mouse cursor colors were hard-coded to a black
border and lightwhite interior. Black for the border is the worst
possible default, since it is the same as the default black background
and not good for any dark background. Reversing this gives the better
default of X Windows. Coloring everything works better still. Now
the coloring defaults to a lightwhite border and red interior.
Coloring for the character cursor is more complicated and mode
dependent. The new coloring doesn't apply for hardware cursors. For
non-block cursors, it only applies in graphics mode. In text mode,
the cursor color was usually a hard-coded (dull)white for the background
only, unless the foreground was white when it was a hard-coded black
for the background only, unless the foreground was white and the
background was black it was reverse video. In graphics mode, it was
always reverse video for the block cursor. Reverse video is worse,
especially over cutmarking regions, since cutmarking still uses simple
reverse video (nothing better is possible in text mode) and double
reverse video for the cursor gives normal video. Now, graphics mode
uses the same algorithm as the best case for text mode in all cases
for graphics mode. The hard-coded sequence { white, black, } for the
background is now { red, white, blue, } where the first 2 colors can
be configured. The blue color at the end is a sentinel which prevents
reverse video being used in most cases but breaks the compatibility
setting for white on black and black on white characters. This will
be fixed later. The compatibility setting is most needed for mono modes.
The previous commit to syscons.c changed sc_cnterm() to be more careful.
It followed null pointers in some cases. But sc_cnterm() has been
unreachable for 15+ years since changes for multiple consoles turned
off calls to the the cnterm destructor for all console drivers. Before
them, it was only called at boot time. So no driver with an attached
console has ever been unloadable and not even the non-console destructors
have been tested much.
2017-08-25 07:04:41 +00:00
|
|
|
/* Dry run to determine color, default and local flags. */
|
2017-08-17 18:08:45 +00:00
|
|
|
shape.shape[0] = 0;
|
Support setting the colors of cursors for the VGA renderer.
Advertise this by changing the defaults to mostly red. If you don't like
this, change them (almost) back using:
vidcontrol -c charcolors,base=7,height=0
vidcontrol -c mousecolors,base=0[,height=15]
The (graphics mode only) mouse cursor colors were hard-coded to a black
border and lightwhite interior. Black for the border is the worst
possible default, since it is the same as the default black background
and not good for any dark background. Reversing this gives the better
default of X Windows. Coloring everything works better still. Now
the coloring defaults to a lightwhite border and red interior.
Coloring for the character cursor is more complicated and mode
dependent. The new coloring doesn't apply for hardware cursors. For
non-block cursors, it only applies in graphics mode. In text mode,
the cursor color was usually a hard-coded (dull)white for the background
only, unless the foreground was white when it was a hard-coded black
for the background only, unless the foreground was white and the
background was black it was reverse video. In graphics mode, it was
always reverse video for the block cursor. Reverse video is worse,
especially over cutmarking regions, since cutmarking still uses simple
reverse video (nothing better is possible in text mode) and double
reverse video for the cursor gives normal video. Now, graphics mode
uses the same algorithm as the best case for text mode in all cases
for graphics mode. The hard-coded sequence { white, black, } for the
background is now { red, white, blue, } where the first 2 colors can
be configured. The blue color at the end is a sentinel which prevents
reverse video being used in most cases but breaks the compatibility
setting for white on black and black on white characters. This will
be fixed later. The compatibility setting is most needed for mono modes.
The previous commit to syscons.c changed sc_cnterm() to be more careful.
It followed null pointers in some cases. But sc_cnterm() has been
unreachable for 15+ years since changes for multiple consoles turned
off calls to the the cnterm destructor for all console drivers. Before
them, it was only called at boot time. So no driver with an attached
console has ever been unloadable and not even the non-console destructors
have been tested much.
2017-08-25 07:04:41 +00:00
|
|
|
shape.shape[1] = -1;
|
|
|
|
shape.shape[2] = -1;
|
2017-08-17 18:08:45 +00:00
|
|
|
parse_cursor_params(param, &shape);
|
1995-01-12 11:47:05 +00:00
|
|
|
|
Support setting the colors of cursors for the VGA renderer.
Advertise this by changing the defaults to mostly red. If you don't like
this, change them (almost) back using:
vidcontrol -c charcolors,base=7,height=0
vidcontrol -c mousecolors,base=0[,height=15]
The (graphics mode only) mouse cursor colors were hard-coded to a black
border and lightwhite interior. Black for the border is the worst
possible default, since it is the same as the default black background
and not good for any dark background. Reversing this gives the better
default of X Windows. Coloring everything works better still. Now
the coloring defaults to a lightwhite border and red interior.
Coloring for the character cursor is more complicated and mode
dependent. The new coloring doesn't apply for hardware cursors. For
non-block cursors, it only applies in graphics mode. In text mode,
the cursor color was usually a hard-coded (dull)white for the background
only, unless the foreground was white when it was a hard-coded black
for the background only, unless the foreground was white and the
background was black it was reverse video. In graphics mode, it was
always reverse video for the block cursor. Reverse video is worse,
especially over cutmarking regions, since cutmarking still uses simple
reverse video (nothing better is possible in text mode) and double
reverse video for the cursor gives normal video. Now, graphics mode
uses the same algorithm as the best case for text mode in all cases
for graphics mode. The hard-coded sequence { white, black, } for the
background is now { red, white, blue, } where the first 2 colors can
be configured. The blue color at the end is a sentinel which prevents
reverse video being used in most cases but breaks the compatibility
setting for white on black and black on white characters. This will
be fixed later. The compatibility setting is most needed for mono modes.
The previous commit to syscons.c changed sc_cnterm() to be more careful.
It followed null pointers in some cases. But sc_cnterm() has been
unreachable for 15+ years since changes for multiple consoles turned
off calls to the the cnterm destructor for all console drivers. Before
them, it was only called at boot time. So no driver with an attached
console has ever been unloadable and not even the non-console destructors
have been tested much.
2017-08-25 07:04:41 +00:00
|
|
|
/* Get the relevant old setting. */
|
2017-08-17 18:08:45 +00:00
|
|
|
if (ioctl(0, CONS_GETCURSORSHAPE, &shape) != 0) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
2017-08-17 18:08:45 +00:00
|
|
|
err(1, "ioctl(CONS_GETCURSORSHAPE)");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
|
2017-08-17 18:08:45 +00:00
|
|
|
parse_cursor_params(param, &shape);
|
|
|
|
if (ioctl(0, CONS_SETCURSORSHAPE, &shape) != 0) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
2017-08-17 18:08:45 +00:00
|
|
|
err(1, "ioctl(CONS_SETCURSORSHAPE)");
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the video mode.
|
|
|
|
*/
|
|
|
|
|
2017-04-03 06:52:02 +00:00
|
|
|
static void
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
video_mode(int argc, char **argv, int *mode_index)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
1998-09-23 10:00:15 +00:00
|
|
|
static struct {
|
2005-01-13 03:59:44 +00:00
|
|
|
const char *name;
|
1998-09-23 10:00:15 +00:00
|
|
|
unsigned long mode;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
unsigned long mode_num;
|
1998-09-23 10:00:15 +00:00
|
|
|
} modes[] = {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
{ "80x25", SW_TEXT_80x25, M_TEXT_80x25 },
|
|
|
|
{ "80x30", SW_TEXT_80x30, M_TEXT_80x30 },
|
|
|
|
{ "80x43", SW_TEXT_80x43, M_TEXT_80x43 },
|
|
|
|
{ "80x50", SW_TEXT_80x50, M_TEXT_80x50 },
|
|
|
|
{ "80x60", SW_TEXT_80x60, M_TEXT_80x60 },
|
|
|
|
{ "132x25", SW_TEXT_132x25, M_TEXT_132x25 },
|
|
|
|
{ "132x30", SW_TEXT_132x30, M_TEXT_132x30 },
|
|
|
|
{ "132x43", SW_TEXT_132x43, M_TEXT_132x43 },
|
|
|
|
{ "132x50", SW_TEXT_132x50, M_TEXT_132x50 },
|
|
|
|
{ "132x60", SW_TEXT_132x60, M_TEXT_132x60 },
|
|
|
|
{ "VGA_40x25", SW_VGA_C40x25, M_VGA_C40x25 },
|
|
|
|
{ "VGA_80x25", SW_VGA_C80x25, M_VGA_C80x25 },
|
|
|
|
{ "VGA_80x30", SW_VGA_C80x30, M_VGA_C80x30 },
|
|
|
|
{ "VGA_80x50", SW_VGA_C80x50, M_VGA_C80x50 },
|
|
|
|
{ "VGA_80x60", SW_VGA_C80x60, M_VGA_C80x60 },
|
1999-06-22 14:15:46 +00:00
|
|
|
#ifdef SW_VGA_C90x25
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
{ "VGA_90x25", SW_VGA_C90x25, M_VGA_C90x25 },
|
|
|
|
{ "VGA_90x30", SW_VGA_C90x30, M_VGA_C90x30 },
|
|
|
|
{ "VGA_90x43", SW_VGA_C90x43, M_VGA_C90x43 },
|
|
|
|
{ "VGA_90x50", SW_VGA_C90x50, M_VGA_C90x50 },
|
|
|
|
{ "VGA_90x60", SW_VGA_C90x60, M_VGA_C90x60 },
|
1999-06-22 14:15:46 +00:00
|
|
|
#endif
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
{ "VGA_320x200", SW_VGA_CG320, M_CG320 },
|
|
|
|
{ "EGA_80x25", SW_ENH_C80x25, M_ENH_C80x25 },
|
|
|
|
{ "EGA_80x43", SW_ENH_C80x43, M_ENH_C80x43 },
|
|
|
|
{ "VESA_132x25", SW_VESA_C132x25,M_VESA_C132x25 },
|
|
|
|
{ "VESA_132x43", SW_VESA_C132x43,M_VESA_C132x43 },
|
|
|
|
{ "VESA_132x50", SW_VESA_C132x50,M_VESA_C132x50 },
|
|
|
|
{ "VESA_132x60", SW_VESA_C132x60,M_VESA_C132x60 },
|
|
|
|
{ "VESA_800x600", SW_VESA_800x600,M_VESA_800x600 },
|
|
|
|
{ NULL, 0, 0 },
|
1998-09-23 10:00:15 +00:00
|
|
|
};
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
int new_mode_num = 0;
|
1999-01-12 23:05:45 +00:00
|
|
|
unsigned long mode = 0;
|
1999-06-22 14:15:46 +00:00
|
|
|
int cur_mode;
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
int save_errno;
|
1998-09-15 18:16:39 +00:00
|
|
|
int size[3];
|
1998-09-23 10:00:15 +00:00
|
|
|
int i;
|
1994-08-17 09:00:13 +00:00
|
|
|
|
1999-06-22 14:15:46 +00:00
|
|
|
if (ioctl(0, CONS_GET, &cur_mode) < 0)
|
|
|
|
err(1, "cannot get the current video mode");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Parse the video mode argument...
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (*mode_index < argc) {
|
|
|
|
if (!strncmp(argv[*mode_index], "MODE_", 5)) {
|
|
|
|
if (!isdigit(argv[*mode_index][5]))
|
|
|
|
errx(1, "invalid video mode number");
|
|
|
|
|
|
|
|
new_mode_num = atoi(&argv[*mode_index][5]);
|
|
|
|
} else {
|
|
|
|
for (i = 0; modes[i].name != NULL; ++i) {
|
|
|
|
if (!strcmp(argv[*mode_index], modes[i].name)) {
|
|
|
|
mode = modes[i].mode;
|
|
|
|
new_mode_num = modes[i].mode_num;
|
|
|
|
break;
|
|
|
|
}
|
1998-09-23 10:00:15 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (modes[i].name == NULL)
|
2017-04-03 06:52:02 +00:00
|
|
|
return;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if (ioctl(0, mode, NULL) < 0) {
|
2017-04-03 06:52:02 +00:00
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "cannot set videomode");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
video_mode_changed = 1;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Collect enough information about the new video mode...
|
|
|
|
*/
|
|
|
|
|
|
|
|
new_mode_info.vi_mode = new_mode_num;
|
|
|
|
|
|
|
|
if (ioctl(0, CONS_MODEINFO, &new_mode_info) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "obtaining new video mode parameters");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (mode == 0) {
|
|
|
|
if (new_mode_num >= M_VESA_BASE)
|
|
|
|
mode = _IO('V', new_mode_num - M_VESA_BASE);
|
|
|
|
else
|
|
|
|
mode = _IO('S', new_mode_num);
|
1998-09-23 10:00:15 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Try setting the new mode.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (ioctl(0, mode, NULL) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "setting video mode");
|
2003-09-18 16:20:32 +00:00
|
|
|
}
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
video_mode_changed = 1;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For raster modes it's not enough to just set the mode.
|
|
|
|
* We also need to explicitly set the raster mode.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (new_mode_info.vi_flags & V_INFO_GRAPHICS) {
|
|
|
|
/* font size */
|
|
|
|
|
|
|
|
if (font_height == 0)
|
|
|
|
font_height = cur_info.console_info.font_size;
|
|
|
|
|
|
|
|
size[2] = font_height;
|
|
|
|
|
|
|
|
/* adjust columns */
|
|
|
|
|
|
|
|
if ((vesa_cols * 8 > new_mode_info.vi_width) ||
|
|
|
|
(vesa_cols <= 0)) {
|
|
|
|
size[0] = new_mode_info.vi_width / 8;
|
2001-01-25 16:53:22 +00:00
|
|
|
} else {
|
|
|
|
size[0] = vesa_cols;
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/* adjust rows */
|
|
|
|
|
|
|
|
if ((vesa_rows * font_height > new_mode_info.vi_height) ||
|
|
|
|
(vesa_rows <= 0)) {
|
|
|
|
size[1] = new_mode_info.vi_height /
|
|
|
|
font_height;
|
2001-01-25 16:53:22 +00:00
|
|
|
} else {
|
|
|
|
size[1] = vesa_rows;
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/* set raster mode */
|
|
|
|
|
1999-06-22 14:15:46 +00:00
|
|
|
if (ioctl(0, KDRASTER, size)) {
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
save_errno = errno;
|
1999-06-22 14:15:46 +00:00
|
|
|
if (cur_mode >= M_VESA_BASE)
|
2001-07-22 13:30:32 +00:00
|
|
|
ioctl(0,
|
|
|
|
_IO('V', cur_mode - M_VESA_BASE),
|
|
|
|
NULL);
|
1999-06-22 14:15:46 +00:00
|
|
|
else
|
|
|
|
ioctl(0, _IO('S', cur_mode), NULL);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
errno = save_errno;
|
|
|
|
err(1, "cannot activate raster display");
|
1999-06-22 14:15:46 +00:00
|
|
|
}
|
1998-09-15 18:16:39 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2017-04-03 06:52:02 +00:00
|
|
|
/* Recover from mode setting forgetting colors. */
|
|
|
|
fprintf(stderr, "\033[=%dF",
|
|
|
|
cur_info.console_info.mv_norm.fore);
|
|
|
|
fprintf(stderr, "\033[=%dG",
|
|
|
|
cur_info.console_info.mv_norm.back);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
(*mode_index)++;
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
}
|
1995-05-30 03:57:47 +00:00
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the number for a specified color name.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static int
|
1994-08-17 09:00:13 +00:00
|
|
|
get_color_number(char *color)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
for (i=0; i<16; i++) {
|
1994-08-17 09:00:13 +00:00
|
|
|
if (!strcmp(color, legal_colors[i]))
|
|
|
|
return i;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
1994-08-17 09:00:13 +00:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
2017-04-03 06:52:02 +00:00
|
|
|
* Set normal text and background colors.
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
2017-04-03 06:52:02 +00:00
|
|
|
set_normal_colors(int argc, char **argv, int *_index)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
|
|
|
int color;
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
if (*_index < argc && (color = get_color_number(argv[*_index])) != -1) {
|
|
|
|
(*_index)++;
|
2005-05-15 09:43:14 +00:00
|
|
|
fprintf(stderr, "\033[=%dF", color);
|
2005-01-13 03:59:44 +00:00
|
|
|
if (*_index < argc
|
Remove checks that background (bg) colors are not bright and buggy
attempts to keep them that way. The bg brightness bit is interpreted
as blinking in some modes, but it would barely be useful to disallow
setting it when it would give blinking in code which knew when that
is. The old code mostly knew this wrong, and added handling errors.
It is in fact impossible to know, since future mode switches may
change the meaning of the bit many times on the screen and in history.
Old versions of vidcontrol disallowed bg color numbers >= 8 in all
cases. This is very VGA/syscons-centric. Syscons uses the VGA defaults
of blinking fg instead of bright bg in text mode and bright bg in
graphics mode. On VGA, this is very easy to toggle at any time, and
vt blows away the VGA text mode default at boot time.
r146736 changed this to try to allow bg color numbers in graphics mode
only. This is even more VGA/syscons-centric, and there are many bugs
in this, and many nearby bugs in the parser. These are increased or
decreased by differences and bugs in vt and teken.
Perhaps the most obvious bug was that almost any vidcontrol command
which changes any color or the mode causes an error if the initial fg
color is bright. E.g., in syscons text mode, after "vidcontrol
lightwhite" to make the fg bright, another "vidcontrol lightwhite" is
rejected and buggy fixup code changes the fg to white. This is because
the bright fg color creates a bright bg color for the phantom reverse
video attribute, so was rejected. (The reverse video attribute is
phantom because teken ignores the user's setting of it and simply
reverses the fg attributes to create the bg attributes. Sometimes
some layer masks off the brightness/blinking bit, but not here.)
Perhaps the next most obvious one was that "vidcontrol lightgreen
lightblue" was misparsed as 2 settings of the fg instead of 1 setting
of the fg and 1 invalid setting of the bg. This is because the
parser supports an undocumented syntax with many parsing bugs (an
ambiguity gives this one).
I recently fix bugs in teken that broke setting of bright fg's and
bg's in the normal way. This gave more settings of then, so the old
bugs showed up more often.
2017-04-02 16:39:39 +00:00
|
|
|
&& (color = get_color_number(argv[*_index])) != -1) {
|
2005-01-13 03:59:44 +00:00
|
|
|
(*_index)++;
|
2005-05-15 09:43:14 +00:00
|
|
|
fprintf(stderr, "\033[=%dG", color);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
2017-04-03 06:52:02 +00:00
|
|
|
* Set reverse text and background colors.
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
2017-04-03 06:52:02 +00:00
|
|
|
set_reverse_colors(int argc, char **argv, int *_index)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
|
|
|
int color;
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
if ((color = get_color_number(argv[*(_index)-1])) != -1) {
|
2005-05-15 09:43:14 +00:00
|
|
|
fprintf(stderr, "\033[=%dH", color);
|
2005-01-13 03:59:44 +00:00
|
|
|
if (*_index < argc
|
Remove checks that background (bg) colors are not bright and buggy
attempts to keep them that way. The bg brightness bit is interpreted
as blinking in some modes, but it would barely be useful to disallow
setting it when it would give blinking in code which knew when that
is. The old code mostly knew this wrong, and added handling errors.
It is in fact impossible to know, since future mode switches may
change the meaning of the bit many times on the screen and in history.
Old versions of vidcontrol disallowed bg color numbers >= 8 in all
cases. This is very VGA/syscons-centric. Syscons uses the VGA defaults
of blinking fg instead of bright bg in text mode and bright bg in
graphics mode. On VGA, this is very easy to toggle at any time, and
vt blows away the VGA text mode default at boot time.
r146736 changed this to try to allow bg color numbers in graphics mode
only. This is even more VGA/syscons-centric, and there are many bugs
in this, and many nearby bugs in the parser. These are increased or
decreased by differences and bugs in vt and teken.
Perhaps the most obvious bug was that almost any vidcontrol command
which changes any color or the mode causes an error if the initial fg
color is bright. E.g., in syscons text mode, after "vidcontrol
lightwhite" to make the fg bright, another "vidcontrol lightwhite" is
rejected and buggy fixup code changes the fg to white. This is because
the bright fg color creates a bright bg color for the phantom reverse
video attribute, so was rejected. (The reverse video attribute is
phantom because teken ignores the user's setting of it and simply
reverses the fg attributes to create the bg attributes. Sometimes
some layer masks off the brightness/blinking bit, but not here.)
Perhaps the next most obvious one was that "vidcontrol lightgreen
lightblue" was misparsed as 2 settings of the fg instead of 1 setting
of the fg and 1 invalid setting of the bg. This is because the
parser supports an undocumented syntax with many parsing bugs (an
ambiguity gives this one).
I recently fix bugs in teken that broke setting of bright fg's and
bg's in the normal way. This gave more settings of then, so the old
bugs showed up more often.
2017-04-02 16:39:39 +00:00
|
|
|
&& (color = get_color_number(argv[*_index])) != -1) {
|
2005-01-13 03:59:44 +00:00
|
|
|
(*_index)++;
|
2005-05-15 09:43:14 +00:00
|
|
|
fprintf(stderr, "\033[=%dI", color);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Switch to virtual terminal #arg.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
1997-03-07 01:34:47 +00:00
|
|
|
set_console(char *arg)
|
|
|
|
{
|
|
|
|
int n;
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if(!arg || strspn(arg,"0123456789") != strlen(arg)) {
|
|
|
|
revert();
|
|
|
|
errx(1, "bad console number");
|
1997-03-07 01:34:47 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
n = atoi(arg);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1999-09-19 08:04:07 +00:00
|
|
|
if (n < 1 || n > 16) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "console number out of range");
|
2006-09-26 21:46:12 +00:00
|
|
|
} else if (ioctl(0, VT_ACTIVATE, n) == -1) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "switching vty");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
1997-03-07 01:34:47 +00:00
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Sets the border color.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
1994-08-17 09:00:13 +00:00
|
|
|
set_border_color(char *arg)
|
|
|
|
{
|
|
|
|
int color;
|
|
|
|
|
2017-08-16 15:14:46 +00:00
|
|
|
color = get_color_number(arg);
|
|
|
|
if (color == -1) {
|
|
|
|
revert();
|
|
|
|
errx(1, "invalid color '%s'", arg);
|
|
|
|
}
|
|
|
|
if (ioctl(0, KDSBORDER, color) != 0) {
|
|
|
|
revert();
|
|
|
|
err(1, "ioctl(KD_SBORDER)");
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
2000-01-12 12:30:33 +00:00
|
|
|
set_mouse_char(char *arg)
|
|
|
|
{
|
|
|
|
struct mouse_info mouse;
|
|
|
|
long l;
|
|
|
|
|
|
|
|
l = strtol(arg, NULL, 0);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-04-21 13:50:32 +00:00
|
|
|
if ((l < 0) || (l > UCHAR_MAX - 3)) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
2001-04-21 13:50:32 +00:00
|
|
|
warnx("argument to -M must be 0 through %d", UCHAR_MAX - 3);
|
2000-01-12 12:30:33 +00:00
|
|
|
return;
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2000-01-12 12:30:33 +00:00
|
|
|
mouse.operation = MOUSE_MOUSECHAR;
|
|
|
|
mouse.u.mouse_char = (int)l;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (ioctl(0, CONS_MOUSECTL, &mouse) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "setting mouse character");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
2000-01-12 12:30:33 +00:00
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Show/hide the mouse.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
1996-06-21 07:20:13 +00:00
|
|
|
set_mouse(char *arg)
|
|
|
|
{
|
|
|
|
struct mouse_info mouse;
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if (!strcmp(arg, "on")) {
|
1996-06-21 07:20:13 +00:00
|
|
|
mouse.operation = MOUSE_SHOW;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
} else if (!strcmp(arg, "off")) {
|
1996-06-21 07:20:13 +00:00
|
|
|
mouse.operation = MOUSE_HIDE;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
} else {
|
|
|
|
revert();
|
|
|
|
errx(1, "argument to -m must be either on or off");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ioctl(0, CONS_MOUSECTL, &mouse) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "%sing the mouse",
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
mouse.operation == MOUSE_SHOW ? "show" : "hid");
|
1996-06-21 07:20:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
2002-07-10 03:31:25 +00:00
|
|
|
set_lockswitch(char *arg)
|
|
|
|
{
|
|
|
|
int data;
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if (!strcmp(arg, "off")) {
|
2002-07-10 03:31:25 +00:00
|
|
|
data = 0x01;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
} else if (!strcmp(arg, "on")) {
|
2002-07-10 03:31:25 +00:00
|
|
|
data = 0x02;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
} else {
|
|
|
|
revert();
|
|
|
|
errx(1, "argument to -S must be either on or off");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ioctl(0, VT_LOCKSWITCH, &data) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "turning %s vty switching",
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
data == 0x01 ? "off" : "on");
|
2002-07-10 03:31:25 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the adapter name for a specified type.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static const char
|
1998-09-15 18:16:39 +00:00
|
|
|
*adapter_name(int type)
|
|
|
|
{
|
|
|
|
static struct {
|
|
|
|
int type;
|
2005-01-13 03:59:44 +00:00
|
|
|
const char *name;
|
1998-09-15 18:16:39 +00:00
|
|
|
} names[] = {
|
|
|
|
{ KD_MONO, "MDA" },
|
|
|
|
{ KD_HERCULES, "Hercules" },
|
|
|
|
{ KD_CGA, "CGA" },
|
|
|
|
{ KD_EGA, "EGA" },
|
|
|
|
{ KD_VGA, "VGA" },
|
1999-06-22 14:15:46 +00:00
|
|
|
{ KD_TGA, "TGA" },
|
1998-09-15 18:16:39 +00:00
|
|
|
{ -1, "Unknown" },
|
|
|
|
};
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1998-09-15 18:16:39 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; names[i].type != -1; ++i)
|
|
|
|
if (names[i].type == type)
|
|
|
|
break;
|
|
|
|
return names[i].name;
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2016-01-19 13:09:20 +00:00
|
|
|
/*
|
|
|
|
* Show active VTY, ie current console number.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static void
|
|
|
|
show_active_info(void)
|
|
|
|
{
|
|
|
|
|
|
|
|
printf("%d\n", cur_info.active_vty);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
/*
|
|
|
|
* Show graphics adapter information.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
1998-09-15 18:16:39 +00:00
|
|
|
show_adapter_info(void)
|
|
|
|
{
|
1999-01-11 03:20:32 +00:00
|
|
|
struct video_adapter_info ad;
|
1998-09-15 18:16:39 +00:00
|
|
|
|
|
|
|
ad.va_index = 0;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
if (ioctl(0, CONS_ADPINFO, &ad) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "obtaining adapter information");
|
1998-09-15 18:16:39 +00:00
|
|
|
}
|
|
|
|
|
1999-01-11 03:20:32 +00:00
|
|
|
printf("fb%d:\n", ad.va_index);
|
|
|
|
printf(" %.*s%d, type:%s%s (%d), flags:0x%x\n",
|
|
|
|
(int)sizeof(ad.va_name), ad.va_name, ad.va_unit,
|
1998-09-15 18:16:39 +00:00
|
|
|
(ad.va_flags & V_ADP_VESA) ? "VESA " : "",
|
1999-01-11 03:20:32 +00:00
|
|
|
adapter_name(ad.va_type), ad.va_type, ad.va_flags);
|
1998-09-15 18:16:39 +00:00
|
|
|
printf(" initial mode:%d, current mode:%d, BIOS mode:%d\n",
|
|
|
|
ad.va_initial_mode, ad.va_mode, ad.va_initial_bios_mode);
|
2005-01-13 03:59:44 +00:00
|
|
|
printf(" frame buffer window:0x%zx, buffer size:0x%zx\n",
|
1999-06-22 14:15:46 +00:00
|
|
|
ad.va_window, ad.va_buffer_size);
|
2005-01-13 03:59:44 +00:00
|
|
|
printf(" window size:0x%zx, origin:0x%x\n",
|
1999-06-22 14:15:46 +00:00
|
|
|
ad.va_window_size, ad.va_window_orig);
|
|
|
|
printf(" display start address (%d, %d), scan line width:%d\n",
|
|
|
|
ad.va_disp_start.x, ad.va_disp_start.y, ad.va_line_width);
|
2005-01-13 03:59:44 +00:00
|
|
|
printf(" reserved:0x%zx\n", ad.va_unused0);
|
1998-09-15 18:16:39 +00:00
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Show video mode information.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
1998-09-15 18:16:39 +00:00
|
|
|
show_mode_info(void)
|
|
|
|
{
|
|
|
|
char buf[80];
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
struct video_info info;
|
1998-09-15 18:16:39 +00:00
|
|
|
int c;
|
2010-03-29 20:12:44 +00:00
|
|
|
int mm;
|
|
|
|
int mode;
|
1998-09-15 18:16:39 +00:00
|
|
|
|
|
|
|
printf(" mode# flags type size "
|
|
|
|
"font window linear buffer\n");
|
|
|
|
printf("---------------------------------------"
|
|
|
|
"---------------------------------------\n");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
memset(&info, 0, sizeof(info));
|
2013-05-11 13:32:38 +00:00
|
|
|
for (mode = 0; mode <= M_VESA_MODE_MAX; ++mode) {
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.vi_mode = mode;
|
|
|
|
if (ioctl(0, CONS_MODEINFO, &info))
|
1998-09-15 18:16:39 +00:00
|
|
|
continue;
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
if (info.vi_mode != mode)
|
1999-06-22 14:15:46 +00:00
|
|
|
continue;
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
if (info.vi_width == 0 && info.vi_height == 0 &&
|
|
|
|
info.vi_cwidth == 0 && info.vi_cheight == 0)
|
2015-04-20 17:43:55 +00:00
|
|
|
continue;
|
1998-09-15 18:16:39 +00:00
|
|
|
|
|
|
|
printf("%3d (0x%03x)", mode, mode);
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
printf(" 0x%08x", info.vi_flags);
|
|
|
|
if (info.vi_flags & V_INFO_GRAPHICS) {
|
1998-09-15 18:16:39 +00:00
|
|
|
c = 'G';
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
if (info.vi_mem_model == V_INFO_MM_PLANAR)
|
2010-03-29 20:12:44 +00:00
|
|
|
snprintf(buf, sizeof(buf), "%dx%dx%d %d",
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.vi_width, info.vi_height,
|
|
|
|
info.vi_depth, info.vi_planes);
|
2010-03-29 20:12:44 +00:00
|
|
|
else {
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
switch (info.vi_mem_model) {
|
2010-03-29 20:12:44 +00:00
|
|
|
case V_INFO_MM_PACKED:
|
|
|
|
mm = 'P';
|
|
|
|
break;
|
|
|
|
case V_INFO_MM_DIRECT:
|
|
|
|
mm = 'D';
|
|
|
|
break;
|
|
|
|
case V_INFO_MM_CGA:
|
|
|
|
mm = 'C';
|
|
|
|
break;
|
|
|
|
case V_INFO_MM_HGC:
|
|
|
|
mm = 'H';
|
|
|
|
break;
|
|
|
|
case V_INFO_MM_VGAX:
|
|
|
|
mm = 'V';
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
mm = ' ';
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
snprintf(buf, sizeof(buf), "%dx%dx%d %c",
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.vi_width, info.vi_height,
|
|
|
|
info.vi_depth, mm);
|
2010-03-29 20:12:44 +00:00
|
|
|
}
|
1998-09-15 18:16:39 +00:00
|
|
|
} else {
|
|
|
|
c = 'T';
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1998-09-15 18:16:39 +00:00
|
|
|
snprintf(buf, sizeof(buf), "%dx%d",
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.vi_width, info.vi_height);
|
1998-09-15 18:16:39 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1998-09-15 18:16:39 +00:00
|
|
|
printf(" %c %-15s", c, buf);
|
|
|
|
snprintf(buf, sizeof(buf), "%dx%d",
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.vi_cwidth, info.vi_cheight);
|
1998-09-15 18:16:39 +00:00
|
|
|
printf(" %-5s", buf);
|
2005-01-13 03:59:44 +00:00
|
|
|
printf(" 0x%05zx %2dk %2dk",
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.vi_window, (int)info.vi_window_size/1024,
|
|
|
|
(int)info.vi_window_gran/1024);
|
2005-01-13 03:59:44 +00:00
|
|
|
printf(" 0x%08zx %dk\n",
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.vi_buffer, (int)info.vi_buffer_size/1024);
|
1998-09-15 18:16:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
1998-09-15 18:16:39 +00:00
|
|
|
show_info(char *arg)
|
|
|
|
{
|
2016-01-19 13:09:20 +00:00
|
|
|
|
|
|
|
if (!strcmp(arg, "active")) {
|
|
|
|
show_active_info();
|
|
|
|
} else if (!strcmp(arg, "adapter")) {
|
1998-09-15 18:16:39 +00:00
|
|
|
show_adapter_info();
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
} else if (!strcmp(arg, "mode")) {
|
1998-09-15 18:16:39 +00:00
|
|
|
show_mode_info();
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
} else {
|
|
|
|
revert();
|
2016-01-19 13:09:20 +00:00
|
|
|
errx(1, "argument to -i must be active, adapter, or mode");
|
1998-09-15 18:16:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
|
|
|
test_frame(void)
|
1994-08-17 09:00:13 +00:00
|
|
|
{
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
vid_info_t info;
|
2017-04-03 15:11:28 +00:00
|
|
|
const char *bg, *sep;
|
2017-01-28 02:22:15 +00:00
|
|
|
int i, fore;
|
2005-05-15 08:04:46 +00:00
|
|
|
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.size = sizeof(info);
|
|
|
|
if (ioctl(0, CONS_GETINFO, &info) == -1)
|
|
|
|
err(1, "getting console information");
|
|
|
|
|
2005-05-15 08:04:46 +00:00
|
|
|
fore = 15;
|
2017-04-03 13:06:28 +00:00
|
|
|
if (info.mv_csz < 80) {
|
|
|
|
bg = "BG";
|
|
|
|
sep = " ";
|
|
|
|
} else {
|
|
|
|
bg = "BACKGROUND";
|
|
|
|
sep = " ";
|
|
|
|
}
|
2005-05-15 08:04:46 +00:00
|
|
|
|
2005-05-15 09:43:14 +00:00
|
|
|
fprintf(stdout, "\033[=0G\n\n");
|
1994-08-17 09:00:13 +00:00
|
|
|
for (i=0; i<8; i++) {
|
2017-04-03 13:06:28 +00:00
|
|
|
fprintf(stdout,
|
|
|
|
"\033[=%dF\033[=0G%2d \033[=%dF%-7s%s"
|
|
|
|
"\033[=%dF\033[=0G%2d \033[=%dF%-12s%s"
|
|
|
|
"\033[=%dF%2d \033[=%dG%s\033[=0G%s"
|
|
|
|
"\033[=%dF%2d \033[=%dG%s\033[=0G\n",
|
|
|
|
fore, i, i, legal_colors[i], sep,
|
|
|
|
fore, i + 8, i + 8, legal_colors[i + 8], sep,
|
|
|
|
fore, i, i, bg, sep,
|
|
|
|
fore, i + 8, i + 8, bg);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
2005-05-15 09:43:14 +00:00
|
|
|
fprintf(stdout, "\033[=%dF\033[=%dG\033[=%dH\033[=%dI\n",
|
1995-05-30 03:57:47 +00:00
|
|
|
info.mv_norm.fore, info.mv_norm.back,
|
1994-08-17 09:00:13 +00:00
|
|
|
info.mv_rev.fore, info.mv_rev.back);
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-05-19 06:47:36 +00:00
|
|
|
/*
|
|
|
|
* Snapshot the video memory of that terminal, using the CONS_SCRSHOT
|
|
|
|
* ioctl, and writes the results to stdout either in the special
|
|
|
|
* binary format (see manual page for details), or in the plain
|
|
|
|
* text format.
|
|
|
|
*/
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
2002-08-19 16:33:23 +00:00
|
|
|
dump_screen(int mode, int opt)
|
2001-05-19 06:47:36 +00:00
|
|
|
{
|
|
|
|
scrshot_t shot;
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
vid_info_t info;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
info.size = sizeof(info);
|
|
|
|
if (ioctl(0, CONS_GETINFO, &info) == -1) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
err(1, "getting console information");
|
2001-05-19 06:47:36 +00:00
|
|
|
}
|
|
|
|
|
2002-08-19 16:33:23 +00:00
|
|
|
shot.x = shot.y = 0;
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
shot.xsize = info.mv_csz;
|
|
|
|
shot.ysize = info.mv_rsz;
|
2002-08-19 16:33:23 +00:00
|
|
|
if (opt == DUMP_ALL)
|
Remove the global variable 'info' and fix associated bugs and style bugs.
This variable was used 4 times in 1 function and all uses were wrong.
The 4 uses were in he test_frame() (show) function, to try to restore
4 colors, 2 unnecessarily and these 2 now broken. This was wrong
because it is the previous colors that must be restored, but the global
holds the original colors. Excessive setting of colors at the end
restored the previous colors correctly in most cases, but I removed
this a couple of revisions ago.
Originally, this variable had 1 correct use, to test for being on a vty
as a side effect of initializing it. This is now down in init(), and
init() also leaves a better-named global with the same contents.
Fix this by reading the current console info into a local variable in
test_frame(), as is done for several other functions. Fix style bugs
in this reading for all callers:
- extra blank lines
- all error messages different. The first one now in init() is not as
specific as the old one, but it is after a different specific one for
another ioctl and is unlikely to be reached when the first ioctl
succeeds. Ones after the first are to repeat the ioctl, so are even
more likely to be reached. The correctness of full removal of the
old global depends on the error handling for failure to initialize
it being unreachable.
- err() instead of warn() for failure in load_font(). This is almost
unreachable, and it makes no sense to continue after undoing previous
changes with revert().
- unreachable return after err() for failure in dump_screen().
Undo large renaming of local variables from the good name 'info' to the
bad name _info, which was done to protect the buggy global's bad name
from -Wshadow warnings.
2017-04-03 10:47:01 +00:00
|
|
|
shot.ysize += info.mv_hsz;
|
2002-08-19 16:33:23 +00:00
|
|
|
|
|
|
|
shot.buf = alloca(shot.xsize * shot.ysize * sizeof(u_int16_t));
|
2001-05-19 06:47:36 +00:00
|
|
|
if (shot.buf == NULL) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "failed to allocate memory for dump");
|
2001-05-19 06:47:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ioctl(0, CONS_SCRSHOT, &shot) == -1) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "dumping screen");
|
2001-05-19 06:47:36 +00:00
|
|
|
}
|
|
|
|
|
2002-08-19 16:33:23 +00:00
|
|
|
if (mode == DUMP_FMT_RAW) {
|
2001-05-19 06:47:36 +00:00
|
|
|
printf("SCRSHOT_%c%c%c%c", DUMP_FMT_REV, 2,
|
|
|
|
shot.xsize, shot.ysize);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-05-19 06:47:36 +00:00
|
|
|
fflush(stdout);
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
write(STDOUT_FILENO, shot.buf,
|
|
|
|
shot.xsize * shot.ysize * sizeof(u_int16_t));
|
2001-05-19 06:47:36 +00:00
|
|
|
} else {
|
|
|
|
char *line;
|
|
|
|
int x, y;
|
|
|
|
u_int16_t ch;
|
|
|
|
|
|
|
|
line = alloca(shot.xsize + 1);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-05-19 06:47:36 +00:00
|
|
|
if (line == NULL) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
|
|
|
errx(1, "failed to allocate memory for line buffer");
|
2001-05-19 06:47:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (y = 0; y < shot.ysize; y++) {
|
|
|
|
for (x = 0; x < shot.xsize; x++) {
|
|
|
|
ch = shot.buf[x + (y * shot.xsize)];
|
|
|
|
ch &= 0xff;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-05-19 06:47:36 +00:00
|
|
|
if (isprint(ch) == 0)
|
|
|
|
ch = ' ';
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-05-19 06:47:36 +00:00
|
|
|
line[x] = (char)ch;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Trim trailing spaces */
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-05-19 06:47:36 +00:00
|
|
|
do {
|
|
|
|
line[x--] = '\0';
|
|
|
|
} while (line[x] == ' ' && x != 0);
|
|
|
|
|
|
|
|
puts(line);
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-05-19 06:47:36 +00:00
|
|
|
fflush(stdout);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the console history buffer size.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
2001-05-28 11:05:28 +00:00
|
|
|
set_history(char *opt)
|
|
|
|
{
|
|
|
|
int size;
|
|
|
|
|
|
|
|
size = atoi(opt);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2001-05-28 11:05:28 +00:00
|
|
|
if ((*opt == '\0') || size < 0) {
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
revert();
|
2017-11-21 13:55:10 +00:00
|
|
|
errx(1, "argument must not be less than zero");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ioctl(0, CONS_HISTORY, &size) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "setting history buffer size");
|
2001-05-28 11:05:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear the console history buffer.
|
|
|
|
*/
|
|
|
|
|
2005-01-13 03:59:44 +00:00
|
|
|
static void
|
|
|
|
clear_history(void)
|
2001-05-28 11:05:28 +00:00
|
|
|
{
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if (ioctl(0, CONS_CLRHIST) == -1) {
|
|
|
|
revert();
|
Save errno across revert().
Change 25 uses of errc() to err(). 2 of these were correct. 23 used
errno for the arg so were just a verbose spelling of err(). 5 of these
were just style bugs, and 18 depended on revert() saving errno.
1 warn() also depended on revert() saving errno.
Remove 2 warnx()'s that duplicate the message from a later errx().
These used to be before returns, and should have reported errno in
some cases. errno is also not reported for for openguess() failures.
Only "restore" the video mode in revert() if the mode was just set
(necessarily partially). Setting the mode to its current setting
doesn't "restore" it, but resets it, with the least harmful change
being to clear the screen. revert() is called even for some harmless
syntax errors and usually did nothing except reset the mode. Now it
usually does nothing. The only things that it tries to restore apart
from the mode are the active vty number, the screen map, 2 colors that
only need to be restored (only after a mode change) to fix kernel bugs,
and 3 colors that can't be restored due to kernel bugs. (This is
mostly for sc, since vt doesn't support mode changes.)
revert() is not called for syntax and setting errors after [mode], so
the mode reset is only done for failures to set raster mode after
setting graphics mode. normal colors can only be set after [mode],
and that is why reverting them should be unnecessary.
2017-04-03 09:21:00 +00:00
|
|
|
err(1, "clearing history buffer");
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
}
|
2001-05-28 11:05:28 +00:00
|
|
|
}
|
|
|
|
|
2019-02-22 06:41:47 +00:00
|
|
|
static int
|
|
|
|
get_terminal_emulator(int i, struct term_info *tip)
|
|
|
|
{
|
|
|
|
tip->ti_index = i;
|
|
|
|
if (ioctl(0, CONS_GETTERM, tip) == 0)
|
|
|
|
return (1);
|
2019-02-22 07:00:23 +00:00
|
|
|
strlcpy((char *)tip->ti_name, "unknown", sizeof(tip->ti_name));
|
|
|
|
strlcpy((char *)tip->ti_desc, "unknown", sizeof(tip->ti_desc));
|
2019-02-22 06:41:47 +00:00
|
|
|
return (0);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
get_terminal_emulators(void)
|
|
|
|
{
|
|
|
|
struct term_info ti;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < 10; i++) {
|
|
|
|
if (get_terminal_emulator(i, &ti) == 0)
|
|
|
|
break;
|
|
|
|
printf("%d: %s (%s)%s\n", i, ti.ti_name, ti.ti_desc,
|
|
|
|
i == 0 ? " (active)" : "");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
set_terminal_emulator(const char *name)
|
|
|
|
{
|
|
|
|
struct term_info old_ti, ti;
|
|
|
|
|
|
|
|
get_terminal_emulator(0, &old_ti);
|
2019-02-22 07:00:23 +00:00
|
|
|
strlcpy((char *)ti.ti_name, name, sizeof(ti.ti_name));
|
2019-02-22 06:41:47 +00:00
|
|
|
if (ioctl(0, CONS_SETTERM, &ti) != 0)
|
|
|
|
warn("SETTERM '%s'", name);
|
|
|
|
get_terminal_emulator(0, &ti);
|
|
|
|
printf("%s (%s) -> %s (%s)\n", old_ti.ti_name, old_ti.ti_desc,
|
|
|
|
ti.ti_name, ti.ti_desc);
|
|
|
|
}
|
|
|
|
|
2009-11-11 08:39:57 +00:00
|
|
|
static void
|
|
|
|
set_terminal_mode(char *arg)
|
|
|
|
{
|
|
|
|
|
|
|
|
if (strcmp(arg, "xterm") == 0)
|
|
|
|
fprintf(stderr, "\033[=T");
|
|
|
|
else if (strcmp(arg, "cons25") == 0)
|
|
|
|
fprintf(stderr, "\033[=1T");
|
|
|
|
}
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1997-03-07 01:34:47 +00:00
|
|
|
int
|
1994-08-17 09:00:13 +00:00
|
|
|
main(int argc, char **argv)
|
|
|
|
{
|
2012-06-29 12:55:36 +00:00
|
|
|
char *font, *type, *termmode;
|
2014-05-29 13:09:48 +00:00
|
|
|
const char *opts;
|
2002-08-19 16:33:23 +00:00
|
|
|
int dumpmod, dumpopt, opt;
|
1995-05-30 03:57:47 +00:00
|
|
|
|
2014-05-29 13:09:48 +00:00
|
|
|
vt4_mode = is_vt4();
|
|
|
|
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
init();
|
|
|
|
|
2002-08-19 16:33:23 +00:00
|
|
|
dumpmod = 0;
|
|
|
|
dumpopt = DUMP_FBF;
|
2012-06-29 12:55:36 +00:00
|
|
|
termmode = NULL;
|
2014-05-29 13:09:48 +00:00
|
|
|
if (vt4_mode)
|
2014-10-23 12:38:05 +00:00
|
|
|
opts = "b:Cc:fg:h:Hi:M:m:pPr:S:s:T:t:x";
|
2014-05-29 13:09:48 +00:00
|
|
|
else
|
2019-02-22 06:41:47 +00:00
|
|
|
opts = "b:Cc:deE:fg:h:Hi:l:LM:m:pPr:S:s:T:t:x";
|
2014-05-29 13:09:48 +00:00
|
|
|
|
|
|
|
while ((opt = getopt(argc, argv, opts)) != -1)
|
1994-08-17 09:00:13 +00:00
|
|
|
switch(opt) {
|
2001-05-28 11:05:28 +00:00
|
|
|
case 'b':
|
|
|
|
set_border_color(optarg);
|
|
|
|
break;
|
|
|
|
case 'C':
|
|
|
|
clear_history();
|
|
|
|
break;
|
|
|
|
case 'c':
|
|
|
|
set_cursor_type(optarg);
|
|
|
|
break;
|
|
|
|
case 'd':
|
2014-05-29 13:09:48 +00:00
|
|
|
if (vt4_mode)
|
|
|
|
break;
|
2001-05-28 11:05:28 +00:00
|
|
|
print_scrnmap();
|
|
|
|
break;
|
2019-02-22 06:41:47 +00:00
|
|
|
case 'E':
|
|
|
|
if (vt4_mode)
|
|
|
|
break;
|
|
|
|
set_terminal_emulator(optarg);
|
|
|
|
break;
|
|
|
|
case 'e':
|
|
|
|
if (vt4_mode)
|
|
|
|
break;
|
|
|
|
get_terminal_emulators();
|
|
|
|
break;
|
2001-05-28 11:05:28 +00:00
|
|
|
case 'f':
|
2014-10-23 12:38:05 +00:00
|
|
|
optarg = nextarg(argc, argv, &optind, 'f', 0);
|
|
|
|
if (optarg != NULL) {
|
|
|
|
font = nextarg(argc, argv, &optind, 'f', 0);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2014-10-23 12:38:05 +00:00
|
|
|
if (font == NULL) {
|
|
|
|
type = NULL;
|
|
|
|
font = optarg;
|
|
|
|
} else
|
|
|
|
type = optarg;
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2014-10-23 12:38:05 +00:00
|
|
|
load_font(type, font);
|
|
|
|
} else {
|
|
|
|
if (!vt4_mode)
|
|
|
|
usage(); /* Switch syscons to ROM? */
|
|
|
|
|
|
|
|
load_default_vt4font();
|
|
|
|
}
|
2001-05-28 11:05:28 +00:00
|
|
|
break;
|
|
|
|
case 'g':
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
if (sscanf(optarg, "%dx%d",
|
|
|
|
&vesa_cols, &vesa_rows) != 2) {
|
|
|
|
revert();
|
2001-05-28 11:05:28 +00:00
|
|
|
warnx("incorrect geometry: %s", optarg);
|
1994-08-17 09:00:13 +00:00
|
|
|
usage();
|
2001-05-28 11:05:28 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
break;
|
2001-05-28 11:05:28 +00:00
|
|
|
case 'h':
|
|
|
|
set_history(optarg);
|
|
|
|
break;
|
2002-08-19 16:33:23 +00:00
|
|
|
case 'H':
|
|
|
|
dumpopt = DUMP_ALL;
|
|
|
|
break;
|
2001-05-28 11:05:28 +00:00
|
|
|
case 'i':
|
|
|
|
show_info(optarg);
|
|
|
|
break;
|
|
|
|
case 'l':
|
2014-05-29 13:09:48 +00:00
|
|
|
if (vt4_mode)
|
|
|
|
break;
|
2001-05-28 11:05:28 +00:00
|
|
|
load_scrnmap(optarg);
|
|
|
|
break;
|
|
|
|
case 'L':
|
2014-05-29 13:09:48 +00:00
|
|
|
if (vt4_mode)
|
|
|
|
break;
|
2001-05-28 11:05:28 +00:00
|
|
|
load_default_scrnmap();
|
|
|
|
break;
|
|
|
|
case 'M':
|
|
|
|
set_mouse_char(optarg);
|
|
|
|
break;
|
|
|
|
case 'm':
|
|
|
|
set_mouse(optarg);
|
|
|
|
break;
|
|
|
|
case 'p':
|
2002-08-19 16:33:23 +00:00
|
|
|
dumpmod = DUMP_FMT_RAW;
|
2001-05-28 11:05:28 +00:00
|
|
|
break;
|
|
|
|
case 'P':
|
2002-08-19 16:33:23 +00:00
|
|
|
dumpmod = DUMP_FMT_TXT;
|
2001-05-28 11:05:28 +00:00
|
|
|
break;
|
|
|
|
case 'r':
|
2017-04-03 06:52:02 +00:00
|
|
|
set_reverse_colors(argc, argv, &optind);
|
2001-05-28 11:05:28 +00:00
|
|
|
break;
|
2002-07-10 03:31:25 +00:00
|
|
|
case 'S':
|
|
|
|
set_lockswitch(optarg);
|
|
|
|
break;
|
2001-05-28 11:05:28 +00:00
|
|
|
case 's':
|
|
|
|
set_console(optarg);
|
|
|
|
break;
|
2009-11-11 08:39:57 +00:00
|
|
|
case 'T':
|
2012-06-29 12:55:36 +00:00
|
|
|
if (strcmp(optarg, "xterm") != 0 &&
|
|
|
|
strcmp(optarg, "cons25") != 0)
|
|
|
|
usage();
|
|
|
|
termmode = optarg;
|
2009-11-11 08:39:57 +00:00
|
|
|
break;
|
2001-05-28 11:05:28 +00:00
|
|
|
case 't':
|
|
|
|
set_screensaver_timeout(optarg);
|
|
|
|
break;
|
|
|
|
case 'x':
|
|
|
|
hex = 1;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
usage();
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2002-08-19 16:33:23 +00:00
|
|
|
if (dumpmod != 0)
|
|
|
|
dump_screen(dumpmod, dumpopt);
|
2017-04-03 06:52:02 +00:00
|
|
|
video_mode(argc, argv, &optind);
|
|
|
|
set_normal_colors(argc, argv, &optind);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1994-08-17 09:00:13 +00:00
|
|
|
if (optind < argc && !strcmp(argv[optind], "show")) {
|
|
|
|
test_frame();
|
|
|
|
optind++;
|
|
|
|
}
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
2012-06-29 12:55:36 +00:00
|
|
|
if (termmode != NULL)
|
|
|
|
set_terminal_mode(termmode);
|
Add VESA mode support for syscons, which enables the support of 15, 16,
24, and 32 bit modes. To use that, syscons(4) must be built with
the compile time option 'options SC_PIXEL_MODE', and VESA support (a.k.a.
vesa.ko) must be either loaded, or be compiled into the kernel.
Do not return EINVAL when the mouse state is changed to what it already is,
which seems to cause problems when you have two mice attached, and
applications are not likely obtain useful information through the EINVAL
caused by showing the mouse pointer twice.
Teach vidcontrol(8) about mode names like MODE_<NUMBER>, where <NUMBER> is
the video mode number from the vidcontrol -i mode output. Also, revert the
video mode if something fails.
Obtained from: DragonFlyBSD
Discussed at: current@ with patch attached [1]
PR: kern/71142 [2]
Submitted by: Xuefeng DENG <dsnofe at msn com> [1],
Cyrille Lefevre <cyrille dot lefevre at laposte dot net> [2]
2005-05-29 08:43:44 +00:00
|
|
|
|
1997-10-27 07:52:10 +00:00
|
|
|
if ((optind != argc) || (argc == 1))
|
1994-08-17 09:00:13 +00:00
|
|
|
usage();
|
2017-04-03 06:52:02 +00:00
|
|
|
return (0);
|
1994-08-17 09:00:13 +00:00
|
|
|
}
|
|
|
|
|