Yep, but there was never any mention of routing all TTY lines into EvStack
by default (at least as I understood it), only those which serve as
keyboard
lines. And I was not advocating EvStack but another method to take input
from the serial driver, and feed it into the VC input layer (currently
handle_scancode but I'd rather use a separate function there). I admit I
have no
comprehensive understanding of the TTY layer but what I gathered points to a
new line discipline as the best way to achieve this.
> You should know better what that means; I can only guess ... Make that
> an 'if (tty->kbdidx ....' for me. Only the 'keyboard line' should be
> redirected elsewhere.
>
>I have no idea; tty_send_char() isn't in the standard Linux kernel. I
>assume it's from the part of drivers/char/*.c which gets heavily
>rototilled by the GGI patches.
Might be, I've no access to the source at work (lots of pesky Macs but no
Linux).
> No one suggested that :-) In fact, what would be the point of
> filtering kermit data through the keyboard map??
>
>Apparently so you could support serial terminals that emit PC keyboard
>codes..... (I didn't say it was a good reason, mind you!)
Let me try to put it this way: some machines (uClinux) have no keyboard,
others want additional keyboards (multihead graphics independent of GGI).
The serial lines seem to be a good choice. Specific serial lines are
designated as keyboard
input, and somewhere along the way from serial driver to the console code a
translation has to be performed. I'd prefer to do this in some analogue to
handle_scancode (yes, I'm aware that this means calling the tty code again,
like ttyS1 -> keycodes+state -> tty[0-5] instead of kbd -> handle_scancode
-> tty[0-5]). If there's another way (not involving EvStack) please let me
know.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu