Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.telstra.net!news-out.internetmci.com!newsfeed.internetmci.com!demos!news-out.communique.net!communique!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!rill.news.pipex.net!pipex!tank.news.pipex.net!pipex!news.utell.co.uk!usenet
From: brian@shift.lan.awfulhak.org (Brian Somers)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Secrets of the console
Date: 2 Apr 1997 13:47:27 GMT
Organization: Awfulhak Ltd.
Lines: 63
Message-ID: <5hto1f$jrm@ui-gate.utell.co.uk>
References: <01bc3b48$fe7d7450$232c3d9b@muna019>
Reply-To: brian@awfulhak.org, brian@utell.co.uk
NNTP-Posting-Host: shift.utell.net
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Newsreader: knews 0.9.8
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:38347
In article <01bc3b48$fe7d7450$232c3d9b@muna019>,
"Andreas Hinterleitner" <ahinterleitn@bangate.eur.compaq.com> writes:
> Anyone can tell me more about the coherence between keyboard, keyboard
> scancodes, termcap and the ability of the screen and applications to
> display color?
Thing work as follows under FreeBSD:
When I press a key, an interrupt occurs and the keyboard interrupt
routine reads the scancode from the keyboard device at io address 0x60.
In the case of syscons (the default console driver), that scancode
is looked up in a table to determine if what has been pressed was a
regular key or a shift key. For shift keys, the internal status is
changed, for other keys, the resulting keystroke is queued to the
current virtual console. Note, there are two "events" when you press
a key, the "down" and the "up". For shift keys, the current shift
status is set on the way down, and unset on the way up. The syscons
table can be changed using "kbdcontrol -l".
The "virtual console" then picks up the keystroke and decides whether
it's special according to your current stty settings. I won't go into
"when" it does this, but usually it will be pretty much immediate.
If it's special, it does the special thing (like sending a SIGINT
or setting an internal flag in the case of lnext). Otherwise, it
puts it in a queue so that a read() can get it.
The application is responsible for knowing what keyboard input
means what. To do this, it reads termcap by asking tcgetattr()
about each of the "capabilities" it's interrested in. For example,
if I want to give you a "help" screen when you press F1, I'd do
a tcgetattr("k0") to find out what key sequence means F1. Depending
on the setting of TERM, I'll be given a string ("^[[M" for syscons).
It's up to the app to notice when it read()s "^[[M" that it means
F1.
When things are going the other way and you write to the console
driver (the screen), it interprets certain sequences of keys -
normally beginning with ^[ (ESC) as being special and does things
such as change the current colour. Again, these capabilities are
held in the termcap database. The program is essentially using
the value of TERM to determine what character sequences will do
what.
If your TERM value is wrong, you'll get crap on the screen and
your keystrokes won't come up with what you pressed. There
are two variables: The terminal emulation software (syscons
in this case) and TERM - they must be consistent.
The TERM value you have is supplied in /etc/ttys for serial
devices, and network shell programs will pass your current
TERM value as part of their protocol.
The only thing I really disagree with is having default
"special characters". You can override them in /etc/gettydefs
(ttys points to an entry there), but you don't have to.
Does this make sense ?
--
Brian <brian@awfulhak.org> <brian@freebsd.org>
<http://www.awfulhak.demon.co.uk>
Don't _EVER_ lose your sense of humour !