I understood as much :-) The uClinux port caused considerable traffic on
linux-m68k...
>Beyond that, I'm really not sure what we need, especially since the serial
>input could range from a VT100 emulator to a Newton keyboard. All the
>possible devices will undoubtedly have very different notions about what
>sequences the non-ASCII characters send, and what degree of support for
>S/C/A/M is available. (Do we want an entire VT100 parser in the kernel
>just to turn VT100 input back into scancodes?)
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).
>Top that off with the desire to echo screen output back to the serial port
>(so that you don't need eensy-weensy eyes to read the itsy-bitsy print if
>you've got a terminal handy), and also be able to commandeer the serial
>port on request (e.g., so that a SLIP connection with a Linux box can be
>started after logging in) without _that_ data showing up on the screen.
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.
>I'm right out of ideas for how to implement this. I've sure it could be
>done with some hacks, but I'd love to see an elegant solution.
The 'elegant' gives me a headache. I'd prefer getting a prototype solution
for the multihead keyboard stuff first, and use that to test the simple
serial
keyboard. Nothing prevents you from going another way. It'll go along the
lines of 'keyboard line discipline' anyway I guess, that would even permit
hooking
the EvStack code in there once GGI gets ready for prime time. Comments?
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu