Hi all,
This patch fixes a long-standing vgacon bug: characters with the bright
bit set were left on the screen and not blacked out.
All I did was that I lookuped up some examples on the net about setting
the vga palette, and added the call missing from the linux kernel, but
included in all other ones. It works for me.
You can test this by writing something with the bright set to the
console, for example:
echo -e "\e[1;31mhello there\e[0m"
and then wait for the console to blank itself (by default, after 10 mins
of inactivity), maybe making it faster using
setterm -blank 1
so you only have to wait 1 minute.
Signed-off-by: Pozsar Balazs <[email protected]>
Please review and apply,
--
pozsy
--- orig/drivers/video/console/vgacon.c 2005-10-11 03:19:19.000000000 +0200
+++ pozsy/drivers/video/console/vgacon.c 2005-10-20 15:41:18.000000000 +0200
@@ -575,6 +510,7 @@ static void vga_set_palette(struct vc_da
{
int i, j;
+ vga_w(state.vgabase, VGA_PEL_MSK, 0xff);
for (i = j = 0; i < 16; i++) {
vga_w(state.vgabase, VGA_PEL_IW, table[i]);
vga_w(state.vgabase, VGA_PEL_D, vc->vc_palette[j++] >> 2);
@@ -717,6 +653,7 @@ static void vga_pal_blank(struct vgastat
{
int i;
+ vga_w(state->vgabase, VGA_PEL_MSK, 0xff);
for (i = 0; i < 16; i++) {
vga_w(state->vgabase, VGA_PEL_IW, i);
vga_w(state->vgabase, VGA_PEL_D, 0);
On 10/20/05, Pozsar Balazs <[email protected]> wrote:
> Hi all,
>
> This patch fixes a long-standing vgacon bug: characters with the bright
> bit set were left on the screen and not blacked out.
> All I did was that I lookuped up some examples on the net about setting
> the vga palette, and added the call missing from the linux kernel, but
> included in all other ones. It works for me.
Thanks for this. Looks like the palette mask is set to something funky. I had
the same problem on my machine but never got annoyed enough to poke
around in the code.
-Bob
Pozsar Balazs <[email protected]> wrote:
> This patch fixes a long-standing vgacon bug: characters with the bright
> bit set were left on the screen and not blacked out.
> All I did was that I lookuped up some examples on the net about setting
> the vga palette, and added the call missing from the linux kernel, but
> included in all other ones. It works for me.
This is strange, since according to my documentation, the value should have
been initialized to 0xff and never been changed. Can you test setting this
value during initialisation (around line 259, if I read correctly) instead?
I don't know if I can test it myself soon enough.
(I'm not the maintainer, I just happen to have some documentation).
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
On Thu, Oct 20, 2005 at 11:23:01PM +0200, Bodo Eggert wrote:
> Pozsar Balazs <[email protected]> wrote:
>
> > This patch fixes a long-standing vgacon bug: characters with the bright
> > bit set were left on the screen and not blacked out.
> > All I did was that I lookuped up some examples on the net about setting
> > the vga palette, and added the call missing from the linux kernel, but
> > included in all other ones. It works for me.
>
> This is strange, since according to my documentation, the value should have
> been initialized to 0xff and never been changed. Can you test setting this
> value during initialisation (around line 259, if I read correctly) instead?
> I don't know if I can test it myself soon enough.
>
> (I'm not the maintainer, I just happen to have some documentation).
Maybe I can test it tomorrow. But as the posted patch work as-is, cannot
do any harm because it just makes sure the register is set as it should
be, and we are talking about a not-so-often called slowpath, I think it
should just be merged and get forgotten, without making a big hassle
making around it :)
On the other side, as this bug is a little annoyment, it can be tested
in -mm until 2.6.15 or so. I have the cure now, so I'm happy with it :)
--
pozsy
Pozsar Balazs wrote:
> Hi all,
>
> This patch fixes a long-standing vgacon bug: characters with the bright
> bit set were left on the screen and not blacked out.
I cannot reproduce the bug though, so this bug probably depends on the
chipset implementation of VGA. Everything works perfectly whatever value
is written to 0x3c6, so this register is either ignored or hardwired to
0xff.
> All I did was that I lookuped up some examples on the net about setting
> the vga palette, and added the call missing from the linux kernel, but
> included in all other ones. It works for me.
>
> You can test this by writing something with the bright set to the
> console, for example:
> echo -e "\e[1;31mhello there\e[0m"
> and then wait for the console to blank itself (by default, after 10 mins
> of inactivity), maybe making it faster using
> setterm -blank 1
> so you only have to wait 1 minute.
The patch is obviously correct, and makes vgacon safe from rogue apps
that sets the the palette mask register to a different value.
>
>
> Signed-off-by: Pozsar Balazs <[email protected]>
Acked-by: Antonino Daplas <[email protected]>
Bodo Eggert wrote:
> Pozsar Balazs <[email protected]> wrote:
>
>> This patch fixes a long-standing vgacon bug: characters with the bright
>> bit set were left on the screen and not blacked out.
>> All I did was that I lookuped up some examples on the net about setting
>> the vga palette, and added the call missing from the linux kernel, but
>> included in all other ones. It works for me.
>
> This is strange, since according to my documentation, the value should have
> been initialized to 0xff and never been changed. Can you test setting this
> value during initialisation (around line 259, if I read correctly) instead?
> I don't know if I can test it myself soon enough.
Actually, I don't see the palette mask (0x3c6) set anywhere in vgacon. The code
in line 259 sets the first 16 entries of the internal palette (0x3c0: 0x0-0xf)
so it points to the first 16 entries of the DAC.
Tony