> At 10:21 AM +0000 2/26/98, Alan Cox wrote:
> >> As to the serial input/monitor output, that looks like the ugly hybrid of
> >> serial and console code I hoped to escape by supporting all ADB flavors
> >> for Mac :-) Could we make that a secondary goal?
> >
> >Its really needed for the palmpilot
>
> Well, you win :-) Would you prefer raw scancodes or events with all the S/C/A/M
> bits tagged on (still to be interpreted with a sort of keymap, just getting
> Shift etc. state from the key event directly)?
Let me chime in, as one of the Pilot folks: since it doesn't have any real
keyboard, the simplest way to get the Pilot up and running is with a
terminal hosting a serial console. Cool. But it would be nice to use the
screen for a console, with the keyboard still driven from the serial port.
(Other alternatives are conceivable, like a Grafitti clone, or an
on-screen keyboard, but a serial keyboard is best, and should always be
available.)
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?)
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.
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.
-- 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