Re: GGI, EGCS/PGCC, Kernel source

Michael Schmitz (
Thu, 26 Feb 1998 22:41:26 -0800

At 11:14 PM -0500 2/26/98, Kenneth Albanowski wrote:
>On Thu, 26 Feb 1998, Michael Schmitz wrote:
>> That exactly is the problem. I'm sure no one wants a VT100 emulator in the
>> kernel, so whatever you hook up to the serial port needs to send key up/down
>> events, not ASCII characters (imagine having the cool hotkeys for console
>> switching, sysrq etc. available).
>Well, that depends. If I do have a Newton keyboard (or a Sun keyboard, or
>any other widget that acts like a serial keyboard) then scancodes should
>be feasible. OTOH, if I'm really using a terminal (or terminal emulator),
>then scan codes are out of the question.

If you're really using a serial terminal, everything beyond 8 bit ASCII is
out of the question. 8 bit ASCII can be mapped some way or other, that's an
issue separate from the current keyboard driver (m68k style, that's what I
happen to know). You lose any multi key combinations that way.

>All we need is some mechanism to load in a keyboard map (minding the fact
>that each serial keyboard probably will have a different data sequence)
>or shut off translation. Maybe some auto-recognition is feasible, maybe

I doubt there's a way to autoprobe the connected device. And I'd abuse the
regular keymap for the translation ...

>Actually, I must admit we (Jeff and I) don't _need_ any of this. Our
>purposes don't require a video console in any case, so that is just

Ok, I'll focus on 'multiple keyboards' first; serial ASCII is just another
special input driver that happens to use something other than
handle_scancode :-)

>Since we've already got an fbcon console running, I think the simplest
>approach would be to hack something in to the serial driver so that serial
>input gets routed to the console input handler, instead of the serial
>port's. Ideally, this is only done when the line mode is N_TTY, which
>should allow SLIP/PPP. (Rerouting console output back to the serial port
>sounds much more hairy.)

To leave you the option of login over the serial line, I'd suggest to either
tag the serial as 'keyboard' in the serial struct or register a new ldisc
for it (primitive, input only).

>Or that's my idea of how the hack version should work. I've not spent
>enought time figuring out just where I have to patch in (my last attempt
>ended with serial input being dumped directly to the screen -- perhaps the
>most complicated VT100 emulator ever invented. :-)

Try bypassing all SCAM state and up/down processing in the keyboard handler
for a start, and feed ASCII as 'scancode'. That should go some way (though
it's a bad hack).

I won't get to any of this before the weekend for sure, so point me in the
right direction if I got something wrong...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to