I have experimentally determined that I can turn off
the automatic screen blanking with the following escape
sequence.
const char blk[]={27, '[', '9', ';', '0', ']', 0};
main()
{
printf(blk);
}
I need to know what the appropriate ioctl() is to do this
directly without using escape sequences. I have searched
the 2.4.20 sources and can't find any documentation for
anything that remotely even looks like it turns off the
automatic blanking. The code appears to be truly magic.
This is important for some imbeded systems because there
isn't any input available, and the screen output gets shut
off and can't be turned on except by re-booting.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Mon, Jul 28, 2003 at 04:00:03PM -0400, Richard B. Johnson wrote:
> I have experimentally determined that I can turn off
> the automatic screen blanking with the following escape
> sequence.
I'm not aware of an ioctl for this, however experimental determination
is hardly necessary, see setterm (specificly the -blank bit).
--
Frank v Waveren Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|chello.nl] ICQ#10074100 1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/[email protected] 7BD9 09C0 3AC1 6DF2
Le lun 28 jui 2003 16:00:03 GMT, Richard B. Johnson a tapot? sur son clavier :
> I have experimentally determined that I can turn off
> the automatic screen blanking with the following escape
> sequence.
>
> const char blk[]={27, '[', '9', ';', '0', ']', 0};
> main()
> {
> printf(blk);
> }
Yes, this is what setterm -blank 0 does. See setterm_command() in
drivers/char/console.c(2.4) or vt.c(2.6)
> I need to know what the appropriate ioctl() is to do this
> directly without using escape sequences.
It's not possible even with current 2.6.0-test2 but could be added to
tioclinux in a few lines.
Regards,
Samuel Thibault
> I need to know what the appropriate ioctl() is to do this
> directly without using escape sequences. I have searched
> the 2.4.20 sources and can't find any documentation for
> anything that remotely even looks like it turns off the
> automatic blanking. The code appears to be truly magic.
You could have just run "setterm -blank 0"
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
On Mon, 28 Jul 2003, Frank v Waveren wrote:
> On Mon, Jul 28, 2003 at 04:00:03PM -0400, Richard B. Johnson wrote:
> > I have experimentally determined that I can turn off
> > the automatic screen blanking with the following escape
> > sequence.
> I'm not aware of an ioctl for this, however experimental determination
> is hardly necessary, see setterm (specificly the -blank bit).
>
`setterm` sends escape-sequences to the terminal as well as using
ioctl(1, TCGETS) and TCSETS ioctl() calls. These ioctls() deal
with the termios structure which was no documented provision for
dealing with screen blanking. And, the experimental work involved
finding out what escape sequences were being sent to the terminal
since there is no known documentation of this specific method of
controlling the virtual terminal.
It is impossible to send escape sequences to an input that does
not exist. That's why I need to know how to stop the kernel's
insistence on turning off the screen.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Mon, Jul 28, 2003 at 04:00:03PM -0400, Richard B. Johnson wrote:
> I have experimentally determined that I can turn off
> the automatic screen blanking with the following escape
> sequence.
>
> const char blk[]={27, '[', '9', ';', '0', ']', 0};
> main()
> {
> printf(blk);
> }
>
> I need to know what the appropriate ioctl() is to do this
The variable blankinterval is static in console.c.
No, no ioctl, just the escape sequence. (2.4.21)
Richard B. Johnson said:
<snip>
> It is impossible to send escape sequences to an input that does
> not exist. That's why I need to know how to stop the kernel's
> insistence on turning off the screen.
from 'strace setterm -blank 0':
write(1, "\33[9;0]", 6) = 6
which means you want to write the escape sequence to standard output (fd
1), or /dev/tty0 if your code is not attached to the current console. This
should be independent of any input devices that may or may not be there.
--
Charles Lepple <ghz.cc!clepple>
http://www.ghz.cc/charles/
On Mon, 28 Jul 2003, Charles Lepple wrote:
> Richard B. Johnson said:
> <snip>
> > It is impossible to send escape sequences to an input that does
> > not exist. That's why I need to know how to stop the kernel's
> > insistence on turning off the screen.
>
> from 'strace setterm -blank 0':
>
> write(1, "\33[9;0]", 6) = 6
>
> which means you want to write the escape sequence to standard output (fd
> 1), or /dev/tty0 if your code is not attached to the current console. This
> should be independent of any input devices that may or may not be there.
>
> --
> Charles Lepple <ghz.cc!clepple>
> http://www.ghz.cc/charles/
Yes. This is f*ing absurb. A default that kills the screen and the
requirement to send some @!_$%!@$ sequences to turn it off. This
is absolute crap, absolutely positively, with no possible justification
whatsoever. If I made an ioctl, it will probably be rejected.........
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Yes. This is f*ing absurb. A default that kills the screen and the
requirement to send some @!_$%!@$ sequences to turn it off. This
is absolute crap, absolutely positively, with no possible justification
whatsoever. If I made an ioctl, it will probably be rejected.........
What language. What about the below (not compiled, not tested)?
diff -u --recursive --new-file -X /linux/dontdiff a/drivers/char/vt.c b/drivers/char/vt.c
--- a/drivers/char/vt.c Mon Jun 23 04:43:32 2003
+++ b/drivers/char/vt.c Tue Jul 29 15:36:58 2003
@@ -2294,6 +2294,12 @@
case TIOCL_BLANKEDSCREEN:
ret = console_blanked;
break;
+ case TIOCL_SETBLANKINTERVAL:
+ if (get_user(data, (char *)arg+1))
+ ret = -EFAULT;
+ else
+ blankinterval = ((unsigned)data)*60*HZ;
+ break;
default:
ret = -EINVAL;
break;
diff -u --recursive --new-file -X /linux/dontdiff a/include/linux/tiocl.h b/include/linux/tiocl.h
--- a/include/linux/tiocl.h Sun Jun 15 01:41:07 2003
+++ b/include/linux/tiocl.h Tue Jul 29 15:34:39 2003
@@ -34,5 +34,6 @@
#define TIOCL_SCROLLCONSOLE 13 /* scroll console */
#define TIOCL_BLANKSCREEN 14 /* keep screen blank even if a key is pressed */
#define TIOCL_BLANKEDSCREEN 15 /* return which vt was blanked */
+#define TIOCL_SETBLANKINTERVAL 16 /* in minutes; 0: don't blank */
#endif /* _LINUX_TIOCL_H */
On Tue, 29 Jul 2003 [email protected] wrote:
> Yes. This is f*ing absurb. A default that kills the screen and the
> requirement to send some @!_$%!@$ sequences to turn it off. This
> is absolute crap, absolutely positively, with no possible justification
> whatsoever. If I made an ioctl, it will probably be rejected.........
>
> What language. What about the below (not compiled, not tested)?
>
[SNIPPED...]
I think you need to call poke_blanked_console() after setting the
blanking interval. Also this won't patch on 2.4.20 because the
header file is different. Anyway, I will try it after I take a
work-break.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
> I think you need to call poke_blanked_console() after setting
There is already an unblank subioctl of TIOCLINUX.
> Yes. This is f*ing absurb. A default that kills the screen and the
> requirement to send some @!_$%!@$ sequences to turn it off. This
> is absolute crap, absolutely positively, with no possible justification
> whatsoever. If I made an ioctl, it will probably be rejected.........
Welcome to the world of ESC sequences. These are terminal standards. Sorry.
On Tue, Jul 29, 2003 at 05:51:00PM +0100, James Simmons wrote:
> Welcome to the world of ESC sequences. These are terminal standards. Sorry.
No. This was a nonstandard private Linux invention.
On Tue, 29 Jul 2003, James Simmons wrote:
>
> > Yes. This is f*ing absurb. A default that kills the screen and the
> > requirement to send some @!_$%!@$ sequences to turn it off. This
> > is absolute crap, absolutely positively, with no possible justification
> > whatsoever. If I made an ioctl, it will probably be rejected.........
>
> Welcome to the world of ESC sequences. These are terminal standards. Sorry.
>
No. There are no ANSI, nor DEC nor AT&T nor IRIS, nor IBM, nor any
other terminals that have screen-blanking capabilities. These are
the inventions of later-date emulations. If my DEC VT-220 screen
went blank I would need to have it serviced.
This is a PC invention that was adopted by Linux. It's very poor
design to have screen blanking enabled as the default. It's a
feature that should be enabled if wanted, not forced.
If you are not on-site within 10 minutes of having a remote
system fail, you can't see what's on the screen when you
plug in your monitor because the console driver has dutifully
blanked the screen. And, you can write escape sequences from
a task that doesn't exist. If `init` or whatever substitutes
for it fails to execute, unless you are watching, or can observe
the result before the screen blanks, you can't see what happened.
It is very poor design.
If the machine had blanking disabled by default, then the
usual SYS-V startup scripts could execute setterm to enable
it IFF it was wanted.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
On Maw, 2003-07-29 at 18:54, Richard B. Johnson wrote:
> No. There are no ANSI, nor DEC nor AT&T nor IRIS, nor IBM, nor any
> other terminals that have screen-blanking capabilities. These are
> the inventions of later-date emulations. If my DEC VT-220 screen
> went blank I would need to have it serviced.
Quite a few of the terminals did have their own screenblank, certainly
post vt220 it was very common. However nobody really used escape codes
for it. Screenblank existed to protect the display and the display spent
most of its time -not- logged into a system.
On Tue, 29 Jul 2003, Richard B. Johnson wrote:
> If the machine had blanking disabled by default, then the
> usual SYS-V startup scripts could execute setterm to enable
> it IFF it was wanted.
optimise for the common case, just fix your box and be done with it.
--
function.linuxpower.ca
Zwane Mwaikambo wrote:
> > If the machine had blanking disabled by default, then the
> > usual SYS-V startup scripts could execute setterm to enable
> > it IFF it was wanted.
>
> optimise for the common case, just fix your box and be done with it.
One of Richard's points is that there is presently no way to fix the
box in userspace. If the kernel crashes during boot, it will blank
the screen and there is no way to unblank it in that state.
-- Jamie
On Wed, Jul 30, 2003 at 02:25:33AM +0100, Jamie Lokier wrote:
> Zwane Mwaikambo wrote:
> > > If the machine had blanking disabled by default, then the
> > > usual SYS-V startup scripts could execute setterm to enable
> > > it IFF it was wanted.
> >
> > optimise for the common case, just fix your box and be done with it.
>
> One of Richard's points is that there is presently no way to fix the
> box in userspace. If the kernel crashes during boot, it will blank
> the screen and there is no way to unblank it in that state.
I know that it is hack, but does not adding (wher ^[ is escape character)
append="blanking=^[[9;0]"
into /etc/lilo.conf solve this blanking problem?
Best regards,
Petr Vandrovec
[email protected]
On Wed, 30 Jul 2003, Jamie Lokier wrote:
> One of Richard's points is that there is presently no way to fix the
> box in userspace. If the kernel crashes during boot, it will blank
> the screen and there is no way to unblank it in that state.
Well something like this should work without complicating things during
panic.
Index: linux-2.6.0-test2/arch/i386/kernel/traps.c
===================================================================
RCS file: /build/cvsroot/linux-2.6.0-test2/arch/i386/kernel/traps.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 traps.c
--- linux-2.6.0-test2/arch/i386/kernel/traps.c 30 Jul 2003 00:06:00 -0000 1.1.1.1
+++ linux-2.6.0-test2/arch/i386/kernel/traps.c 30 Jul 2003 01:34:12 -0000
@@ -248,6 +248,7 @@ bug:
}
spinlock_t die_lock = SPIN_LOCK_UNLOCKED;
+int dont_blank_on_panic;
void die(const char * str, struct pt_regs * regs, long err)
{
@@ -261,8 +262,11 @@ void die(const char * str, struct pt_reg
show_registers(regs);
bust_spinlocks(0);
spin_unlock_irq(&die_lock);
- if (in_interrupt())
+ if (in_interrupt()) {
+ dont_blank_on_panic = 1;
+ barrier();
panic("Fatal exception in interrupt");
+ }
if (panic_on_oops) {
printk(KERN_EMERG "Fatal exception: panic in 5 seconds\n");
Index: linux-2.6.0-test2/drivers/char/vt.c
===================================================================
RCS file: /build/cvsroot/linux-2.6.0-test2/drivers/char/vt.c,v
retrieving revision 1.1.1.1
diff -u -p -B -r1.1.1.1 vt.c
--- linux-2.6.0-test2/drivers/char/vt.c 30 Jul 2003 00:06:17 -0000 1.1.1.1
+++ linux-2.6.0-test2/drivers/char/vt.c 30 Jul 2003 01:33:41 -0000
@@ -2696,10 +2696,11 @@ static void vesa_powerdown_screen(unsign
static void timer_do_blank_screen(int entering_gfx, int from_timer_handler)
{
+ extern int dont_blank_on_panic;
int currcons = fg_console;
int i;
- if (console_blanked)
+ if (console_blanked || dont_blank_on_panic)
return;
/* entering graphics mode? */
--
function.linuxpower.ca
"Richard B. Johnson" <[email protected]> writes:
> No. There are no ANSI, nor DEC nor AT&T nor IRIS, nor IBM, nor any
> other terminals that have screen-blanking capabilities.
Yes there are. I guess you never used any of them.
[The brand that immediately comes to mind is Wyse, but I seem to recall
the H29 having this capability too...]
-Miles
--
[|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that
will make every christian in the world foamm at the mouth?
[iddt] nurg, that's the goal
On Wed, Jul 30, 2003 at 03:40:04AM +0200, Petr Vandrovec wrote:
>
> I know that it is hack, but does not adding (wher ^[ is escape character)
>
> append="blanking=^[[9;0]"
>
> into /etc/lilo.conf solve this blanking problem?
Unfortunately it does not work, printk() goes always through simple
layer which understands only CR, LF and BS. So left arrow is printed
instead of interpreting ESC.
Petr
On Tue, Jul 29, 2003 at 08:17:15PM -0400, you [Zwane Mwaikambo] wrote:
> On Tue, 29 Jul 2003, Richard B. Johnson wrote:
>
> > If the machine had blanking disabled by default, then the
> > usual SYS-V startup scripts could execute setterm to enable
> > it IFF it was wanted.
>
> optimise for the common case,
I would argue the other way around. The majority of desktop users run X,
console blanking won't help them anyway. The server users tend to have KVM
or switch monitor cables on the fly - in most such cases console blanking
hurts more than helps (since you can't tell which box is connected to which
monitor etc.)
And console blanking is not real DPMS power save anyway.
> just fix your box and be done with it.
Most times when you need to have it fixed is when your box has mysteriously
locked up, and you'd wan't to know if there was a oops on the screen. No can
do - the console is already blanked. By then it is too late to fix it.
In what cases is console blanking so hugely important these days, anyway?
-- v --
[email protected]
On Wed, Jul 30, 2003 at 11:16:05AM +0900, Miles Bader wrote:
> "Richard B. Johnson" <[email protected]> writes:
> > No. There are no ANSI, nor DEC nor AT&T nor IRIS, nor IBM, nor any
> > other terminals that have screen-blanking capabilities.
>
> Yes there are. I guess you never used any of them.
>
> [The brand that immediately comes to mind is Wyse, but I seem to recall
> the H29 having this capability too...]
I can't speak for the others but according to my Wyse 50
manual the S.SAVER feature in the field level 4 menu
has a default value of OFF.
My recollection is that this was common among the VDTs which
suffered considerably from burn-in. Many of the later
models had the feature but it was a hardware setting
controlled via a configuration menu or a dip-switch. You
want the setting to persist across logins and power cycling.
It really should be disabled in-kernel by default. The
distribution RC scripts would as a default then enable it
late in the boot process. In a server setting where it
isn't wanted the admin should know enough to prevent its
being enabled.
I too have been bitten by this on servers where the console
display is either powered down or disconnected for months at
a time. The error messages leading to the hang may be in
the display buffer but they can't be seen.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On Wednesday 30 July 2003 01:22, Ville Herva wrote:
>On Tue, Jul 29, 2003 at 08:17:15PM -0400, you [Zwane Mwaikambo]
wrote:
>> On Tue, 29 Jul 2003, Richard B. Johnson wrote:
>> > If the machine had blanking disabled by default, then the
>> > usual SYS-V startup scripts could execute setterm to enable
>> > it IFF it was wanted.
>>
>> optimise for the common case,
>
>I would argue the other way around. The majority of desktop users
> run X, console blanking won't help them anyway. The server users
> tend to have KVM or switch monitor cables on the fly - in most such
> cases console blanking hurts more than helps (since you can't tell
> which box is connected to which monitor etc.)
>
>And console blanking is not real DPMS power save anyway.
>
>> just fix your box and be done with it.
>
>Most times when you need to have it fixed is when your box has
> mysteriously locked up, and you'd wan't to know if there was a oops
> on the screen. No can do - the console is already blanked. By then
> it is too late to fix it.
>
>In what cases is console blanking so hugely important these days,
> anyway?
I feel like I should concur here, as console blanking has bit me more
than once. A compile time option, grub/lilo append, whatever, but in
any event it should be unconditionally disableable if one so chooses.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
On Tue, Jul 29, 2003 at 08:17:15PM -0400, Zwane Mwaikambo wrote:
> On Tue, 29 Jul 2003, Richard B. Johnson wrote:
>
> > If the machine had blanking disabled by default, then the
> > usual SYS-V startup scripts could execute setterm to enable
> > it IFF it was wanted.
>
> optimise for the common case, just fix your box and be done with it.
To borrow from the medical community: "First, do no harm."
There is harm in having blanking enabled during the boot
sequence as well as later. There is very little harm in no
screen blanking at all. There is no harm in deferring the
entablement of screen blanking until some time in the RC
scripts where it can be prevented by those who know better.
There is no need for auto-blanking to be a boot parameter if
it defaults to off. Boot parameters are the least optimal
treatment of this issue.
The common case of which you speak is the least optimised
environment you're likely to find.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
Here ya go... This rips out the screen blanking code by the
roots since the kind and gentle approach didn't seem to be what
you were looking for. :-)
--- linux/drivers/char/console.c.orig
+++ linux/drivers/char/console.c
@@ -144,7 +144,6 @@
static int con_open(struct tty_struct *, struct file *);
static void vc_init(unsigned int console, unsigned int rows,
unsigned int cols, int do_clear);
-static void blank_screen(unsigned long dummy);
static void gotoxy(int currcons, int new_x, int new_y);
static void save_cur(int currcons);
static void reset_terminal(int currcons, int do_clear);
@@ -152,7 +151,6 @@
static void set_vesa_blanking(unsigned long arg);
static void set_cursor(int currcons);
static void hide_cursor(int currcons);
-static void unblank_screen_t(unsigned long dummy);
static void console_callback(void *ignored);
static int printable; /* Is console ready for printing? */
@@ -205,8 +203,6 @@
*/
int (*console_blank_hook)(int);
-static struct timer_list console_timer;
-
/*
* Low-Level Functions
*/
@@ -2488,12 +2484,6 @@
if (tty_register_driver(&console_driver))
panic("Couldn't register console driver\n");
- init_timer(&console_timer);
- console_timer.function = blank_screen;
- if (blankinterval) {
- mod_timer(&console_timer, jiffies + blankinterval);
- }
-
/*
* kmalloc is not running yet - we use the bootmem allocator.
*/
@@ -2629,39 +2619,6 @@
console_driver.minor_start + i);
}
-/*
- * This is called by a timer handler
- */
-static void vesa_powerdown(void)
-{
- struct vc_data *c = vc_cons[fg_console].d;
- /*
- * Power down if currently suspended (1 or 2),
- * suspend if currently blanked (0),
- * else do nothing (i.e. already powered down (3)).
- * Called only if powerdown features are allowed.
- */
- switch (vesa_blank_mode) {
- case VESA_NO_BLANKING:
- c->vc_sw->con_blank(c, VESA_VSYNC_SUSPEND+1);
- break;
- case VESA_VSYNC_SUSPEND:
- case VESA_HSYNC_SUSPEND:
- c->vc_sw->con_blank(c, VESA_POWERDOWN+1);
- break;
- }
-}
-
-/*
- * This is a timer handler
- */
-static void vesa_powerdown_screen(unsigned long dummy)
-{
- console_timer.function = unblank_screen_t;
-
- vesa_powerdown();
-}
-
static void timer_do_blank_screen(int entering_gfx, int from_timer_handler)
{
int currcons = fg_console;
@@ -2687,17 +2644,6 @@
}
hide_cursor(currcons);
- if (!from_timer_handler)
- del_timer_sync(&console_timer);
- if (vesa_off_interval) {
- console_timer.function = vesa_powerdown_screen;
- mod_timer(&console_timer, jiffies + vesa_off_interval);
- } else {
- if (!from_timer_handler)
- del_timer_sync(&console_timer);
- console_timer.function = unblank_screen_t;
- }
-
save_screen(currcons);
/* In case we need to reset origin, blanking hook returns 1 */
i = sw->con_blank(vc_cons[currcons].d, 1);
@@ -2717,14 +2663,6 @@
}
/*
- * This is a timer handler
- */
-static void unblank_screen_t(unsigned long dummy)
-{
- unblank_screen();
-}
-
-/*
* Called by timer as well as from vt_console_driver
*/
void unblank_screen(void)
@@ -2742,11 +2680,6 @@
if (vcmode != KD_TEXT)
return; /* but leave console_blanked != 0 */
- console_timer.function = blank_screen;
- if (blankinterval) {
- mod_timer(&console_timer, jiffies + blankinterval);
- }
-
console_blanked = 0;
if (console_blank_hook)
console_blank_hook(0);
@@ -2757,25 +2690,10 @@
set_cursor(fg_console);
}
-/*
- * This is both a user-level callable and a timer handler
- */
-static void blank_screen(unsigned long dummy)
-{
- timer_do_blank_screen(0, 1);
-}
-
void poke_blanked_console(void)
{
- del_timer(&console_timer);
if (!vt_cons[fg_console] || vt_cons[fg_console]->vc_mode == KD_GRAPHICS)
return;
- if (console_blanked) {
- console_timer.function = unblank_screen_t;
- mod_timer(&console_timer, jiffies); /* Now */
- } else if (blankinterval) {
- mod_timer(&console_timer, jiffies + blankinterval);
- }
}
/*
@@ -3001,7 +2919,7 @@
unblank_screen();
break;
case PM_SUSPEND:
- do_blank_screen(0);
+ unblank_screen();
break;
}
return 0;
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Zwane Mwaikambo, Wed, Jul 30, 2003 03:37:26 +0200:
> On Wed, 30 Jul 2003, Jamie Lokier wrote:
>
> > One of Richard's points is that there is presently no way to fix the
> > box in userspace. If the kernel crashes during boot, it will blank
> > the screen and there is no way to unblank it in that state.
>
> Well something like this should work without complicating things during
> panic.
>
Does it unblank screen if panic happened while the screen was blanked?
are you really sure the kernel default is to blank?
on my slackware systems there is a setterm -blank 15 in the startup
scripts and all I have ever needed to do (1.2 through 2.4 kernels) is to
comment this out and the screen never blanks.
David Lang
On Wed, 30 Jul 2003, Alex Riesen wrote:
> Date: Wed, 30 Jul 2003 09:14:17 +0200
> From: Alex Riesen <[email protected]>
> To: Zwane Mwaikambo <[email protected]>
> Cc: Linux kernel <[email protected]>
> Subject: Re: Turning off automatic screen clanking
>
> Zwane Mwaikambo, Wed, Jul 30, 2003 03:37:26 +0200:
> > On Wed, 30 Jul 2003, Jamie Lokier wrote:
> >
> > > One of Richard's points is that there is presently no way to fix the
> > > box in userspace. If the kernel crashes during boot, it will blank
> > > the screen and there is no way to unblank it in that state.
> >
> > Well something like this should work without complicating things during
> > panic.
> >
>
> Does it unblank screen if panic happened while the screen was blanked?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Wed, 30 Jul 2003, Erik Andersen wrote:
>
> Here ya go... This rips out the screen blanking code by the
> roots since the kind and gentle approach didn't seem to be what
> you were looking for. :-)
Come on...
That's not necessary! I'm looking for either making it default
to "no blanking" so startup scripts need to enable this feature,
or an ioctl to turn it off.
The 'kindest and gentlist' approach was to simply set the timer
variable "blankinterval" (line 165 in console.c) to 0 instead of
10*60*HZ. This doesn't work. The screen still blanks in 10 minutes.
The next approach was to make an ioctl function. I was supplied with
1/2 what was necessary and, if I add the rest (a trivial call), it
will work, however that extra code may probably be rejected as
'bloat'.
What I'm working on now, when I can get the time, is trying to
find out how come initialization to zero doesn't work and making
it work. Once this is done, there should not be any technical
reasons why it can't be included in the standard kernel.
The current enabling of the blanker by default is clearly policy
and it has been well established that policy decisions should be
outside the kernel.
[SNIPPED (neat) patch...]
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Note 96.31% of all statistics are fiction.
Zwane Mwaikambo wrote:
> On Wed, 30 Jul 2003, Jamie Lokier wrote:
>
>
>>One of Richard's points is that there is presently no way to fix the
>>box in userspace. If the kernel crashes during boot, it will blank
>>the screen and there is no way to unblank it in that state.
>
>
> Well something like this should work without complicating things during
> panic.
>
[snip]
This looks like it prevents blanking after panic. What about UNblanking
during panic?
Ville Herva wrote:
> On Tue, Jul 29, 2003 at 08:17:15PM -0400, you [Zwane Mwaikambo] wrote:
> Most times when you need to have it fixed is when your box has mysteriously
> locked up, and you'd wan't to know if there was a oops on the screen. No can
> do - the console is already blanked. By then it is too late to fix it.
>
> In what cases is console blanking so hugely important these days, anyway?
Why don't we borrow a trick from my old Atari 8-bit computer. Instead
of blanking, cycle the colors. Best of both worlds: You save your
monitor AND you get to see what's on the screen.
On Thu, 31 Jul 2003, Timothy Miller wrote:
> [snip]
>
> This looks like it prevents blanking after panic. What about UNblanking
> during panic?
iirc the screen already unblanks. But it's been a while since i've looked
at a panic'ing box via the screen.
--
function.linuxpower.ca
Zwane Mwaikambo wrote:
> On Thu, 31 Jul 2003, Timothy Miller wrote:
> > This looks like it prevents blanking after panic. What about UNblanking
> > during panic?
>
> iirc the screen already unblanks. But it's been a while since i've looked
> at a panic'ing box via the screen.
That's still not good enough if the boot-time crash is not a panic.
-- Jamie
On Thu, Jul 31, 2003 at 10:36:30AM -0400, Timothy Miller wrote:
>
>
> Ville Herva wrote:
> >On Tue, Jul 29, 2003 at 08:17:15PM -0400, you [Zwane Mwaikambo] wrote:
>
> >Most times when you need to have it fixed is when your box has mysteriously
> >locked up, and you'd wan't to know if there was a oops on the screen. No
> >can
> >do - the console is already blanked. By then it is too late to fix it.
> >
> >In what cases is console blanking so hugely important these days, anyway?
>
>
> Why don't we borrow a trick from my old Atari 8-bit computer. Instead
> of blanking, cycle the colors. Best of both worlds: You save your
> monitor AND you get to see what's on the screen.
hmm, ignoring the issue that modern monitors will not
suffer the burnin, how would it help to cycle the colors?
the only valid solution would be inverting the image on
a regular basis, and I don't think that this would be
appreciated ...
just my opinion,
Herbert
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
On Thu, 31 Jul 2003, Herbert [iso-8859-1] P?tzl wrote:
> hmm, ignoring the issue that modern monitors will not
> suffer the burnin, how would it help to cycle the colors?
Modern monitors DO still suffer from burn-in. I have a few monitors here
that have noticeable burn in from applications that constantly show the
same image.
Mike
Herbert P?tzl wrote:
>>Why don't we borrow a trick from my old Atari 8-bit computer. Instead
>>of blanking, cycle the colors. Best of both worlds: You save your
>>monitor AND you get to see what's on the screen.
>
>
> hmm, ignoring the issue that modern monitors will not
> suffer the burnin, how would it help to cycle the colors?
> the only valid solution would be inverting the image on
> a regular basis, and I don't think that this would be
> appreciated ...
>
So, if there's no point to having screen-blanking, why is it in there to
begin with? To protect OLD monitors from burnin?
Is screen-blanking there just to make people feel better who think they
need screen-blanking? As I understand, it doesn't do any
power-management stuff anyhow.
What's the deal?
Richard B. Johnson wrote:
> The 'kindest and gentlist' approach was to simply set the timer
> variable "blankinterval" (line 165 in console.c) to 0 instead of
> 10*60*HZ. This doesn't work. The screen still blanks in 10 minutes.
console.c line 2491 (function con_init:)
init_timer(&console_timer);
console_timer.function = blank_screen;
if (blankinterval) {
mod_timer(&console_timer, jiffies + blankinterval);
}
So the trick appears to be to not initialize console_timer. Then, on line
1283 (function setterm_command:)
case 9: /* set blanking interval */
blankinterval = ((par[1] < 60) ? par[1] : 60) * 60 * HZ;
poke_blanked_console();
break;
Do some "magic" to initialize console_timer if it is not.
I think blanking by default is bad. Many times it bite me in the past. Same
old history: only monitor, no keyboard, couldn't see what's going on until I
plugged a keyboard (which of course, was in another room.)
BTW:
Zwane Mwaikambo wrote:
> On Tue, 29 Jul 2003, Richard B. Johnson wrote:
> > If the machine had blanking disabled by default, then the
> > usual SYS-V startup scripts could execute setterm to enable
> > it IFF it was wanted.
>
> optimise for the common case, just fix your box and be done with it.
*IF* Linux primary target is the server market then, what kind of optimization
in console blanking if you need to hack your init script and insert "setterm
-blank 0" somewhere??
Regards,
Norberto
On 31 Jul 03 at 15:55, Timothy Miller wrote:
> So, if there's no point to having screen-blanking, why is it in there to
> begin with? To protect OLD monitors from burnin?
For example. My 8 years old EIZO F764M must not be powered down/powersaved
for more than few seconds, otherwise it takes about two days to get
convergence back right (monitor "fixes" itself, it is just unusable until
it does so as there is about 0.5cm distance between red and green and
green and blue components...).
> Is screen-blanking there just to make people feel better who think they
> need screen-blanking? As I understand, it doesn't do any
> power-management stuff anyhow.
setterm -powersave powerdown. I used it until monitor told me that it was
bad idea.
Petr Vandrovec
On Thu, 31 Jul 2003, Norberto BENSA wrote:
> Zwane Mwaikambo wrote:
> > On Tue, 29 Jul 2003, Richard B. Johnson wrote:
> > > If the machine had blanking disabled by default, then the
> > > usual SYS-V startup scripts could execute setterm to enable
> > > it IFF it was wanted.
> >
> > optimise for the common case, just fix your box and be done with it.
>
> *IF* Linux primary target is the server market then, what kind of optimization
> in console blanking if you need to hack your init script and insert "setterm
> -blank 0" somewhere??
oh lord, you make it sound like a lot of work.
<insert reply about 'working out of the box'>
You're convincing the wrong person, it's not a difficult problem just send
a patch already instead of slinging arguments for and against back and
forth.
--
function.linuxpower.ca
On Thu, 31 Jul 2003, Jamie Lokier wrote:
> Zwane Mwaikambo wrote:
> > On Thu, 31 Jul 2003, Timothy Miller wrote:
> > > This looks like it prevents blanking after panic. What about UNblanking
> > > during panic?
> >
> > iirc the screen already unblanks. But it's been a while since i've looked
> > at a panic'ing box via the screen.
>
> That's still not good enough if the boot-time crash is not a panic.
You mean oopses?
--
function.linuxpower.ca
On Thursday 31 Jul 2003 20:55, Timothy Miller wrote:
> Herbert P?tzl wrote:
> >>Why don't we borrow a trick from my old Atari 8-bit computer. Instead
> >>of blanking, cycle the colors. Best of both worlds: You save your
> >>monitor AND you get to see what's on the screen.
> >
> > hmm, ignoring the issue that modern monitors will not
> > suffer the burnin, how would it help to cycle the colors?
> > the only valid solution would be inverting the image on
> > a regular basis, and I don't think that this would be
> > appreciated ...
>
> So, if there's no point to having screen-blanking, why is it in there to
> begin with? To protect OLD monitors from burnin?
>
> Is screen-blanking there just to make people feel better who think they
> need screen-blanking? As I understand, it doesn't do any
> power-management stuff anyhow.
You say that, and I certainly remember it saying just about the same thing in
the kernel configuration help. However there is also this from the Debian
init file /etc/init.d/console-screen.sh
# screensaver stuff
setterm_args=""
if [ "$BLANK_TIME" ]; then
setterm_args="$setterm_args -blank $BLANK_TIME"
fi
if [ "$BLANK_DPMS" ]; then
setterm_args="$setterm_args -powersave $BLANK_DPMS"
fi
if [ "$POWERDOWN_TIME" ]; then
setterm_args="$setterm_args -powerdown $POWERDOWN_TIME"
fi
if [ "$setterm_args" ]; then
setterm $setterm_args
I know for sure it worked with 2.4 and am fairly sure it still works with
2.6.0-test#.
--
Ian.
Zwane Mwaikambo wrote:
> > > iirc the screen already unblanks. But it's been a while since i've looked
> > > at a panic'ing box via the screen.
> >
> > That's still not good enough if the boot-time crash is not a panic.
>
> You mean oopses?
I mean if /sbin/init or /linuxrc crash early, for example.
-- Jamie
On Fri, 1 Aug 2003, Jamie Lokier wrote:
> Zwane Mwaikambo wrote:
> > > > iirc the screen already unblanks. But it's been a while since i've looked
> > > > at a panic'ing box via the screen.
> > >
> > > That's still not good enough if the boot-time crash is not a panic.
> >
> > You mean oopses?
>
> I mean if /sbin/init or /linuxrc crash early, for example.
Boottime crashes are different, they are usually reproducible and you
should just reboot and watch it.
--
function.linuxpower.ca
Timothy Miller <[email protected]> writes:
Hello Timothy,
> So, if there's no point to having screen-blanking, why is it in there
> to begin with? To protect OLD monitors from burnin?
> Is screen-blanking there just to make people feel better who think
> they need screen-blanking? As I understand, it doesn't do any
> power-management stuff anyhow.
My monitor (Iiyama Vision Master Pro 21) turns its power off as soon
as it realizes that the screen was staying black for a certain amount
of time (configurable). It hasn't anything to do with power management
stuff, since I can also reproduce it by turning the cursor off and
then typing "clear; sleep 10000000" in my shell.
That's why I appreciate the kernel console blanking.
Although I suppose it would do the same if you just cycle the colors,
since the monitor shouldn't notice the difference. But you would have
to cycle the colors to black, I guess. "very dark grey" would probably
not be enough.
And then I see no point in cycling the colors instead of blanking.
Julien
On Sunday 03 Aug 2003 11:40, Julien Oster wrote:
> My monitor (Iiyama Vision Master Pro 21) turns its power off as soon
> as it realizes that the screen was staying black for a certain amount
> of time (configurable). It hasn't anything to do with power management
> stuff, since I can also reproduce it by turning the cursor off and
> then typing "clear; sleep 10000000" in my shell.
My old monitor, Iiyama VisionMaster Pro 400, was meant to do this too, but it
never worked. It only ever went into power saving when the distro I had
installed set this option during boot. Up till then I'd simply believed the
kernel config help where it mentioned not doing power saving and so never
looked for the option! Up to then I'd only had DPMS available through X.
BTW, I assume you have screen blanking and power saving disabled by setterm
when the monitor goes into power saving mode?
--
Ian.
Julien Oster wrote:
>
>
> And then I see no point in cycling the colors instead of blanking.
>
The idea is to save your screen from burn-in AND be able to read it at
the same time. I wasn't considering power-saving. If you keep changing
the colors on the screen but maintain contrast between characters and
the background, that would do the trick.