console remains blanked

console remains blanked

[Albert Herranz]

Hi,

Looks like, since [1] was merged, a blanked console
(due to inactivity for example) doesn't get unblanked
anymore when new output is written to it.

This hunk of the already metioned patch, which
modifies vt_console_print() in drivers/char/vt.c, is
possibly the cause:

@@ -2220,9 +2220,6 @@
 	}
 	set_cursor(vc);
 
-	if (!oops_in_progress)
-		poke_blanked_console();
-
 quit:
 	clear_bit(0, &printing);
 }


Is that new behaviour intentional?
The old behaviour looks more interesting to me,
allowing one to see console messages immediately even
if the console was blanked after some idle time.

Cheers,
Albert

[1]
http://marc.theaimsgroup.com/?l=linux-kernel&m=111052009232499&w=2



		
______________________________________________ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es

Re: console remains blanked

[Jan Engelhardt]

>Looks like, since [1] was merged, a blanked console
>(due to inactivity for example) doesn't get unblanked
>anymore when new output is written to it.

The console is unblanked when you hit a key (or probably move a mouse too), 
not when some application outputs something on stdout/stderr/etc.

>[1]
>http://marc.theaimsgroup.com/?l=linux-kernel&m=111052009232499&w=2

Which kernel versions have this patch? I'm on 2.6.13-rc1 and have no problems 
with unblanking.



Jan Engelhardt
-- 

Re: console remains blanked

[Albert Herranz]

Hi,

 --- Jan Engelhardt <jengelh@linux01.gwdg.de>
escribió:
> The console is unblanked when you hit a key (or
> probably move a mouse too), 
> not when some application outputs something on
> stdout/stderr/etc.

Before 2.6.12-rc2, the console was unblanked by just
writing to the console.
For keyboardless and mouseless systems (which is my
case, embedded) this new behaviour is a bit annoying.

> Which kernel versions have this patch? I'm on
> 2.6.13-rc1 and have no problems 
> with unblanking.

I have this problem since 2.6.12-rc2.
If I add back the patch hunk specified in my original
message, the blanking behaviour changes to that
present in pre-2.6.12-rc2 kernels.

I just would like to know if this new behaviour is
just intentional and makes sense to everyone (except
me :-)

Thanks for your feedback,
Albert



		
______________________________________________ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es

Re: console remains blanked

[Jan Engelhardt]

>Before 2.6.12-rc2, the console was unblanked by just
>writing to the console.
>For keyboardless and mouseless systems (which is my
>case, embedded) this new behaviour is a bit annoying.

Interesting. I have observed the following (2.6.13-rc1 and a little 
earlier):
    mplayer bla.avi -vo cvidix
After the blanking time, all chars turn black[1] but are still "visible" 
thanks the movie in the background - a vga palette manipulation to the entries 
0-15 as it seems. This is quite different to writing 80x25 the space character.



Jan Engelhardt
-- 

Re: console remains blanked

[Benjamin Herrenschmidt]

On Thu, 2005-07-14 at 01:12 +0200, Albert Herranz wrote:
> Hi,
> 
> Looks like, since [1] was merged, a blanked console
> (due to inactivity for example) doesn't get unblanked
> anymore when new output is written to it.
> 
> This hunk of the already metioned patch, which
> modifies vt_console_print() in drivers/char/vt.c, is
> possibly the cause:

Yes. We discussed that with Linus back then. The problem is that the
printk subsystem tend to abuse calling low level drivers at interrupt
time, and in the case of blanking/unblanking, this can be a problem.
Radeonfb for example relies on beeing able to schedule() at
blank/unblank time.

If this "feature" is really important, maybe the best is to trigger the
workqueue and do the ublank from there.

Ben.

Re: console remains blanked

[Benjamin Herrenschmidt]

> 
> I have this problem since 2.6.12-rc2.
> If I add back the patch hunk specified in my original
> message, the blanking behaviour changes to that
> present in pre-2.6.12-rc2 kernels.

And you'll have nice scheduling in atomic for any printk() done in
atomic context that triggers the unblank() when using radeonfb on an
LVDS LCD panel...
 
> I just would like to know if this new behaviour is
> just intentional and makes sense to everyone (except
> me :-)

Re: console remains blanked

[Benjamin Herrenschmidt]

On Thu, 2005-07-14 at 13:38 +0200, Jan Engelhardt wrote:
> >Before 2.6.12-rc2, the console was unblanked by just
> >writing to the console.
> >For keyboardless and mouseless systems (which is my
> >case, embedded) this new behaviour is a bit annoying.
> 
> Interesting. I have observed the following (2.6.13-rc1 and a little 
> earlier):
>     mplayer bla.avi -vo cvidix
> After the blanking time, all chars turn black[1] but are still "visible" 
> thanks the movie in the background - a vga palette manipulation to the entries 
> 0-15 as it seems. This is quite different to writing 80x25 the space character.
> 

I don't think this is related to the patch Albert is talking about

Ben.

Re: console remains blanked

[Albert Herranz]

Hi Ben,

 --- Benjamin Herrenschmidt <benh@kernel.crashing.org>
escribió:
> Yes. We discussed that with Linus back then. The
> problem is that the
> printk subsystem tend to abuse calling low level
> drivers at interrupt
> time, and in the case of blanking/unblanking, this
> can be a problem.
> Radeonfb for example relies on beeing able to
> schedule() at
> blank/unblank time.

Ok.

> If this "feature" is really important, maybe the
> best is to trigger the
> workqueue and do the ublank from there.

It looks like I'm the only one concerned, so don't
worry. I'll workaround it.

Thanks for your feedback.

Cheers,
Albert




		
______________________________________________ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es