SVGATextMode on 2.6.11

SVGATextMode on 2.6.11

[Alan Curry]

With 2.6.11, I can no longer change the cursor with SVGATextMode. Previously,
a block cursor could be selected by
  echo Cursor 0-31 >> /etc/TextConfig ; SVGATextMode
and the cursor would be a block. On all consoles. Forever.

To accomplish the same thing using the softcursor escape sequences, I must:
1. at boot, echo '^[[?8c' to each of /dev/tty1 through /dev/tty63.
2. hack terminfo to contain ^[[?8c in place of ^[[?0c
3. install the hacked terminfo on all other machines that I will log into
remotely

This still isn't quite right: the reset sequence ^[c destroys the block
cursor because the underline cursor is still the default. An SVGATextMode
block cursor isn't affected by ^[c -- it truly *becomes* the default, rather
than being an option that is lost on reset. That's why I've always used
SVGATextMode to set the cursor: I don't ever want to see an underline cursor
anywhere, regardless of what terminfo says and /usr/bin/reset does.

Was SVGATextMode's cursor-setting ability removed as a result of an
intentional change, or might it get fixed? Or might CUR_DEFAULT become
tunable? Maybe another control sequence could make the current cursor
settings the default, like setterm -store does for foreground and background
colors.

On another note, the resize function of SVGATextMode has been affected
strangely too. Sometimes, when resizing the screen to a mode larger than
80x25, the video settings come out correctly but the terminal only uses the
first 25 lines, with the bottom of the screen being blank. This one is hard
to reproduce. I can reproduce it by doing a full boot (which includes an
SVGATextMode call from /etc/rcS.d/S60svgatextmode) followed by a manual
SVGATextMode on tty2. The first one works, and the second one screws up the
terminal size. When I try to reproduce that series of events without the call
from /etc/rcS.d, the problem doesn't show up.

In any case, when that problem _does_ show up, it can be fixed by immediately
running the same command again, on the same tty where it just screwed up. And
it never fails twice without an intervening reboot.

Re: SVGATextMode on 2.6.11

[Andrew Morton]

"Alan Curry" <pacman-kernel@manson.clss.net> wrote:
>
> With 2.6.11, I can no longer change the cursor with SVGATextMode. Previously,
> a block cursor could be selected by
>   echo Cursor 0-31 >> /etc/TextConfig ; SVGATextMode
> and the cursor would be a block. On all consoles. Forever.
> 
> To accomplish the same thing using the softcursor escape sequences, I must:
> 1. at boot, echo '^[[?8c' to each of /dev/tty1 through /dev/tty63.
> 2. hack terminfo to contain ^[[?8c in place of ^[[?0c
> 3. install the hacked terminfo on all other machines that I will log into
> remotely
> 
> This still isn't quite right: the reset sequence ^[c destroys the block
> cursor because the underline cursor is still the default. An SVGATextMode
> block cursor isn't affected by ^[c -- it truly *becomes* the default, rather
> than being an option that is lost on reset. That's why I've always used
> SVGATextMode to set the cursor: I don't ever want to see an underline cursor
> anywhere, regardless of what terminfo says and /usr/bin/reset does.
> 
> Was SVGATextMode's cursor-setting ability removed as a result of an
> intentional change, or might it get fixed? Or might CUR_DEFAULT become
> tunable? Maybe another control sequence could make the current cursor
> settings the default, like setterm -store does for foreground and background
> colors.
> 
> On another note, the resize function of SVGATextMode has been affected
> strangely too. Sometimes, when resizing the screen to a mode larger than
> 80x25, the video settings come out correctly but the terminal only uses the
> first 25 lines, with the bottom of the screen being blank. This one is hard
> to reproduce. I can reproduce it by doing a full boot (which includes an
> SVGATextMode call from /etc/rcS.d/S60svgatextmode) followed by a manual
> SVGATextMode on tty2. The first one works, and the second one screws up the
> terminal size. When I try to reproduce that series of events without the call
> from /etc/rcS.d, the problem doesn't show up.
> 
> In any case, when that problem _does_ show up, it can be fixed by immediately
> running the same command again, on the same tty where it just screwed up. And
> it never fails twice without an intervening reboot.

This one appears to be a regression introduced by "vgacon fixes to help font restauration in X11", at

http://linux.bkbits.net:8080/linux-2.5/diffs/drivers/video/console/vgacon.c@1.24?nav=index.html|src/|src/drivers|src/drivers/video|src/drivers/video/console|hist/drivers/video/console/vgacon.c

Nobody really owns that code, so one option is to simply revert that
change.

Re: SVGATextMode on 2.6.11

[Andries Brouwer]

> "Alan Curry" <pacman-kernel@manson.clss.net> wrote:
>>
>> With 2.6.11, I can no longer change the cursor with SVGATextMode. Previously,
>> a block cursor could be selected by
>>   echo Cursor 0-31 >> /etc/TextConfig ; SVGATextMode
>> and the cursor would be a block. On all consoles. Forever.
>> 
>> To accomplish the same thing using the softcursor escape sequences, I must:
>> 1. at boot, echo '^[[?8c' to each of /dev/tty1 through /dev/tty63.
>> 2. hack terminfo to contain ^[[?8c in place of ^[[?0c
>> 3. install the hacked terminfo on all other machines that I will log into
>> remotely
>> 
>> This still isn't quite right: the reset sequence ^[c destroys the block
>> cursor because the underline cursor is still the default.

Have you tried to recompile with a different default?
Look at <linux/console_struct.h>, and change the line
	#define CUR_DEFAULT CUR_UNDERLINE
to e.g.
	#define CUR_DEFAULT CUR_BLOCK

>> An SVGATextMode
>> block cursor isn't affected by ^[c -- it truly *becomes* the default

True - it is obtained by hardware reprogramming. But having lots of programs
touch the hardware is getting less popular.


Concerning your 1. - You know that such an echo actually creates the VC?
I still recall the times that there was not enough memory for more than
four or five VCs, but probably you don't mind wasting a few hundred kB.

Andries

Re: SVGATextMode on 2.6.11

[Alan Curry]

Andries Brouwer writes the following:
>
>> "Alan Curry" <pacman-kernel@manson.clss.net> wrote:
>>> An SVGATextMode
>>> block cursor isn't affected by ^[c -- it truly *becomes* the default
>
>True - it is obtained by hardware reprogramming. But having lots of programs
>touch the hardware is getting less popular.

Yes, I realize that SVGATextMode is probably considered obsolete by now. If
the new cursor-restoring code actually solved a problem, SVGATextMode
breakage is an acceptable side effect.

>Concerning your 1. - You know that such an echo actually creates the VC?
>I still recall the times that there was not enough memory for more than
>four or five VCs, but probably you don't mind wasting a few hundred kB.

I did find a better way, as explained in a subsequent message: Set the
console font before changing the cursor, and don't touch it afterward.

Re: SVGATextMode on 2.6.11

[Alan Curry]

I wrote:
>
>Was SVGATextMode's cursor-setting ability removed as a result of an
>intentional change, or might it get fixed? Or might CUR_DEFAULT become
>tunable? Maybe another control sequence could make the current cursor
>settings the default, like setterm -store does for foreground and background
>colors.

I found the cause of this new behavior: font loading. SVGATextMode can be
configured to load a font with consolechars. It does that after setting the
cursor. In 2.6.11 vgacon_adjust_height() was changed to reset the cursor in
addition to the font size. The solution is: disable SVGATextMode's font
loading, and if you want to change the font, do it before you run SVGATextMode.

The second problem remains a mystery:

>On another note, the resize function of SVGATextMode has been affected
>strangely too. Sometimes, when resizing the screen to a mode larger than
>80x25, the video settings come out correctly but the terminal only uses the
>first 25 lines, with the bottom of the screen being blank. This one is hard
>to reproduce. I can reproduce it by doing a full boot (which includes an
>SVGATextMode call from /etc/rcS.d/S60svgatextmode) followed by a manual
>SVGATextMode on tty2. The first one works, and the second one screws up the
>terminal size. When I try to reproduce that series of events without the call
>from /etc/rcS.d, the problem doesn't show up.
>
>In any case, when that problem _does_ show up, it can be fixed by immediately
>running the same command again, on the same tty where it just screwed up. And
>it never fails twice without an intervening reboot.