lkml.org 
[lkml]   [2004]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Linux-fbdev-devel] Re: fbdv/fbcon pending problems
Date
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@amc.com.au 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site