Re: [Linux-fbdev-devel] Re: fbdv/fbcon pending problems

[Stuart Young]

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 
simple.

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 - sgy-lkml@xxxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/