[lkml]   [2005]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectSVGATextMode on 2.6.11
    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

    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

    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.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:10    [W:0.021 / U:12.172 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site