[lkml]   [2004]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Linux-fbdev-devel] Re: fbdv/fbcon pending problems
    On Tue, 24 Feb 2004 07:36 pm, Geert Uytterhoeven wrote:
    > On Tue, 24 Feb 2004, Stuart Young wrote:
    > > On Mon, 23 Feb 2004 11:53 am, Benjamin Herrenschmidt wrote:
    > > > - Logo problems. When booting with a logo, then going to getty, the
    > > > logo doesn't get erased until we actually switch to another console (or
    > > > reset the console). At this point, using things like vi & scrolling up
    > > > doesn't work properly. Actually, last time I tried, I had to switch
    > > > back & forth twice before my console that had the logo got fully
    > > > working with vi.
    > >
    > > If it's possible to unlock this region so that it scrolls again from
    > > userspace (ie: not resetting/clearing it, just unlocking it), then it's
    > > just a simple matter of checking wether the current console is an fb
    > > device, and if it is, making it unlock the scrolling region. In Debian,
    > > this could be done in /etc/init.d/rmnologin, or even in /etc/profile if
    > > someone would rather it done after login.
    > There should be an ANSI escape sequence for resetting the scroll region.
    > Just send that to the console.

    Yup there is. It's Esc [r , however this also returns the cursor to the top of
    the screen. You can use Esc [s & Esc [u to save and restore the current
    cursor position, so it's just a matter of putting them around it thus:
    Esc [s Esc [r Esc [u

    Or with echo (in a bash script - \\'s to escape it from the shell):
    echo -ne \\033[s\\033[r\\033[u

    Now there is a problem with this solution: This leaves the logo (and any
    boot-time drawn graphics in the unscrollable region) on the screen. When text
    scrolls up the screen, these graphics do not scroll, and are only removed
    when a character overwrites the graphics position on the screen. If you have
    a number of graphics on the screen (or a machine with a number of processors,
    and therefore a number of tux logos), you'll find that you end up with
    spurious graphical artifacts left on the display where the text hasn't
    directly overwritten the image.

    Now you'd think that you could easily just wipe (n) lines off the screen,
    probably using ansi escape sequences. Well it sort of works, but then you
    need to know how big the logo is, how big the font is (as you're working with
    an ascii to graphical representation), and just how much of the screen to
    wipe, to get it right for all the various fbcon display arrangements. While
    the info might be available to userspace to figure this out, it stops being

    Probably could just talk to the fb driver directly (from the shell) and wipe
    that section of screen. Fun fun fun... Hrm.. Time to look into it.

    Of course, you could just clear the screen.....

    Note: Fixing this in a binary is pretty much a no-no. How many dists will want
    to add another binary to their systems, or patch something like getty simply
    to fix a display artifact? I'm guessing pretty close to the 0 mark.

    Stuart Young - is specifically for LKML and related email

    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:01    [W:0.025 / U:41.456 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site