Subject: Re: patch for wscons scrolling
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: tech-kern
Date: 06/16/2002 13:04:34
[ On Sunday, June 16, 2002 at 15:35:22 (+0200), David Ferlier wrote: ]
> Subject: Re: patch for wscons scrolling
>
> I finished doing it this way, this means that you can have something
> like this in your keyboard map :
> 
> keycode 208 = Cmd_ScrollDown Down

Very nice!  Thanks!

I presume the "Cmd_scrollDown" has to be explicitly cancelled by
pressing the ScrollLock key again and that until then the other selected
keys can do other scrolling operations (eg. "Up", "PgUp", etc.).

What is the behaviour of the screen when the "hold screen" mode is
turned off?  Does it revert to the most recent output as does FreeBSD?
(I think that's what it should do -- it seems it would be the most
predictable and un-surprising behaviour.)

> Another thing, i 'm quite sure of the answer, but i can still ask. Say
> we are in mode hold screen, all keys typed go in a buffer, and this
> buffer is drawn when going back when you hit hold screen again. Let's
> say the Cmd_ScrollUp command is put on the Prior key (Pgup on a
> keyboard who has it). Each time he hits the key activating the scroll
> command, do we want to prevent the keycode from going through the rest
> of the wskbd_translate function ?

Yes I think that would be best to block other keys while in the "hold
screen" mode.  For a sophisticated xterm user it can be surprising not
to be able to type when the screen is scrolled back (and of course there
are several user-selectable options to control xterm's behaviour in this
situation) (I've been surprised in this way several times when using
FreeBSD).  However on the console it seems prudent to only supply the
safest option -- it would be even more surprising if those keystrokes
contained (especially by accident) some destructive command and there
were no way to erase them from the buffer before you released the "hold
screen" mode!

(What's prevented me from getting frustrated on FreeBSD has always been
the glow of the little scroll-lock light to remind me why most keys are
not responding.  If that LED were not there or were not working then I
really would want Xterm's 'si' (scrollTtyOutput) and 'sk'(scrollKey)
options so I could choose my preferred behaviour -- i.e. make it match
the way I normally use xterm, which is of course "-si -sk".)


> ( if nobody understood, sorry but it's hard to explain something
> technical (or not ;-) in another language than french ;-)

I'm sure it is -- I have a hard enough time in my own native language
sometimes, and I'd be pretty much useless in any other language, even
French even after five years of high-school classes since that was all
too many years ago now with no real practice since.  You do very well
indeed in English!

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>