Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Sep 1996 12:39:45 +0400 (MSD)
From:      =?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?= (Andrey A. Chernov) <ache@nagual.ru>
To:        davidn@sdev.blaze.net.au (David Nugent)
Cc:        bde@zeta.org.au, craigs@os.com, jab@rock.anchorage.net, freebsd-hardware@FreeBSD.org, hackers@FreeBSD.org, sos@FreeBSD.org (Soren Schmidt)
Subject:   Re: (was Slow Etherlink) Syscons
Message-ID:  <199609180839.MAA00462@nagual.ru>
In-Reply-To: <Pine.BSF.3.95.960918173504.2777P-100000@sdev.blaze.net.au> from "David Nugent" at "Sep 18, 96 05:48:55 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
> One problem I do have with the syscons driver, however, is the
> cursor. I'm not one who things much of the blocky cursor, especially
> since porting Crisp as an editor with it's neat ability to change
> the cursor size over virtual/real spaces - it needs to have the
> hardware cursor enabled (e.g. vidcontrol -c destructive) so the
> cursor size can change. The problem is, the screen updates are
> affected by enabling that, such that when typing at the shell
> prompt, you often don't see characters that are typed until you
> hit enter.
> 
> Is this a known problem? I'm running 2.2-CURRENT if that is
> relevent, although I noticed the same when I ran 2.1.5-RELEASE as
> well. Right now I just have the editor enable the destructive
> cursor while editing, and switch it back off when exiting via the
> appropriate ANSI sequences. Unfortunately, while that's fine
> while within that vt (Crisp itself seems unaffected by this 'bug'
> - it seems only to happen with cooked stdio enabled, or maybe if
> termios echo enabled since it occurs with tcsh as well;  I
> haven't really experimented all that much) - but the destructive
> cursor is system wide, so switching to another vt while editing
> brings the destructive cursor with it. 

Yes, it is known bug, I already report Soren about this thing.
It was broken about month ago. The next manifistation of this bug
is that scrolling not always occurse when answering to 'rm -i'
response at the last line, but it is very hard to catch it.

-- 
Andrey A. Chernov
<ache@nagual.ru>
http://www.nagual.ru/~ache/



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609180839.MAA00462>