Date: Mon, 15 Jun 1998 20:21:36 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: vovik@ntu-kpi.kiev.ua (Vladimir A. Jakovenko) Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG Subject: Re: getty issue file Message-ID: <199806152021.NAA20336@usr02.primenet.com> In-Reply-To: <19980615221137.03151@NTU-KPI.Kiev.UA> from "Vladimir A. Jakovenko" at Jun 15, 98 10:11:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > This means you needs to ensure the terminal is in the base state before
> > doing the newline. This is relatively easy to do, and won't damage the
> > ability to download the sixel based character sets.
> >
> > You *will* have to deal with a number-of-characters-in-the-sixel-set
> > lines of CRLF, however...
>
> Hmm ... according to getty sources, it uses 512 bytes buffer not for each
> line, but for all issue file.
No. It calls getline repeatedly.
See line 328 of /usr/src/libexec/getty/main.c:
/* if this is the first time through this, and an
issue file has been given, then send it */
if (first_time && IF) {
int fd;
if ((fd = open(IF, O_RDONLY)) != -1) {
char * cp;
--->>> while ((cp = getline(fd)) != NULL) {
putf(cp);
}
close(fd);
}
}
first_time = 0;
The point is that getline() will fail is there is more than 512 bytes
before the EOL (LF).
> Terry, do you know any VT 240/420 terminals feature likes 'keymap' in
> the freebsd console code? With loadable fonts I can display russian,
> but sometimes I also need typing in russian, and at present I have only
> one solution -- run screen from ports and use the screen's feature
> 'bindkey'.
Probably the correct way to do it is to translate serial keyboard
events into key-up/key-down pairs, and map them in that way. The
best method would be to add a line discipline, and just use the
"kbdmap" utility to install the maps. This would be the most general
soloution, since if done right, it would work with all the existing map
files, magically.
For upper case characters, you'll have to do "shift-down", "key-down",
"key-up", "shift-up". For control characters, "ctrl-down" ... "ctrl-up",
and similar bracketing. It's probably not worthwhile supporting
function key translation, since that is too terminal specific. You would
need to add an additional line discipline (terminal specific) to handle
that. If you wanted to go that far, I would suggest modelling the
terminal state in the raw processing module, shared by all tty style
devices, ie: as an option in the TTYDISC or NTTYDISC. This would let
you transparent print when the automaton was at state 0, and also let
you access the status lines atomically, etc.. This is a real win,
which UNIX can't currently cope with, except using third party drivers,
like those available from Computone, etc.. You'd also be able to use
the VTXXX series "DEC mice", which send escape sequences on button down,
but don't send motion-notify events.
I'd be willing to help on *some* of this, since I've basically done this
code before for a commercial UNIX tty application vendor.
Alternately, you could buy Russian keyboards from DEC. 8-(. I don't
think there are any, since you are more than an NRCS away from US ASCII.
Alternately alternately, you could make "mapchan" work. This is an
inferior approach, though, since it means that you wouldn't be able to
leverage the keymaps in either direction.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806152021.NAA20336>