> 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.
However, I think we can simply skip the in-kernel VT100 parser, and if
an ASCII device is connected, just send the data through unchanged.
User-space programs can use termcap/terminfo to cope with the sequences,
as usual. There won't be any cool hotkeys, but we can live without that.
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
not.
> That's yet another can of worms. I don't know if the serial console
> patch supports these kinds of switches (and virtual consoles??) but I'd
> think better keep it stupid simple, just use sercons for both input and
> output to serial (that should be plain ASCII or VT100), use a getty on
> the serial line otherwise (login and PPP) and use the 'serial keyboard
> vaporware' if you want to have output to the builtin video. I know that
> doesn't even sound half cool but it's all I can offer to do right now,
> and you can always try to piece the parts together later.
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
window-dressing.
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.)
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. :-)
In any case, what we've got already (the serial console support implicit
in 2.0.33) works wonderfully, and I don't want anyone to feel obligated to
extend it on our account.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu