Date: Tue, 16 Jun 1998 22:44:51 +0300 From: "Vladimir A. Jakovenko" <vovik@ntu-kpi.kiev.ua> To: Terry Lambert <tlambert@primenet.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: getty issue file Message-ID: <19980616224451.65299@NTU-KPI.Kiev.UA> In-Reply-To: <199806152021.NAA20336@usr02.primenet.com>; from Terry Lambert on Mon, Jun 15, 1998 at 08:21:36PM %2B0000 References: <19980615221137.03151@NTU-KPI.Kiev.UA> <199806152021.NAA20336@usr02.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 15, 1998 at 08:21:36PM +0000, Terry Lambert wrote:
> > > 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).
>
I'll see, sorry for my mistake :-(
In previous posting you said:
* 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.
so if I still need to load sixel fonts in getty, I have to add code to check if
terminal in a base state, do newline, and send next data portion < 512,
check base state, do newline, send data, etc ....
Can you point me how I can check is a terminal in the base state?
>
> > 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.
>
It's quite interesting, but I haven't enough time now :-(
> 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.
>
As I said earlier to mr. Babkin, something similar has already exist (you can
find it via ftpsearch with keyword 'ttymap.22.tgz'). I'll look at it ....
>
> Terry Lambert
> terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
--
Regards,
Vladimir.
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?19980616224451.65299>