Mathieu Bouchard <boum01@UQAH.UQuebec.CA> a écrit:
> Etienne Lorrain a écrit:
> > - You can know/set the keyboard language, the font, the
> > screen size (to any value) and save/protect them in NV RAM.
> none are the responsibility of /dev/keyboard, which is more low-level.
Language is an interresting information about the keyboard, i.e.
Linux should be informed once (at boot) of the keyboard language
used and then be able to report to each application the status
(for X and vgalib...). Same for autorepeat parameters and for which
function key are present (application saying "press F13 to
continue" !).
Just do it by writing a command (set of bytes) to /dev/keyboard and
read the answer from /dev/keyboard (an escaped set of bytes).
Then, the name of /dev/keyboard is more /dev/tty, and because
you have a protocol to ask some information, make the protocol
nice enought to ask a lot of things concerning /dev/tty, and
compatible enought to work with the standard VT. Also it
would be nice to have the same system for a linux console
and a Xterm window in X, or even a VT terminal on the other
side of the world.
> > - You can set a special mode where every modifier key (shift,
> > control, alternate, compose) send a complete and concise
> > status when pressed and released.
> what do you mean, complete and concise? /dev/keyboard will notify reader
> about every key on the keyboard, for every press and every release.
If you have a real serial line, reporting a lot of thing
can increase a lot the number of bytes to be send.
Moreover, the reader of /dev/keyboard may just want to treat
ALT-something or CTRL-something without tring to remap for
each language the letters and manage autorepeat.
So a two level managment (on the first level, only event
press/release of special key - on the second, event press/release
for all key) will greately simplify softwares like
Midnight Commander or git, or editors like wpe (borland like),
and even Emacs users will be able to remap "Ctrl Alt Compose F1".
> > - You can set all keys in RAW mode (like for previous
> > modifier keys) sending coordinate when pressed/released
> this is the main goal of /dev/keyboard.
The system using /dev/tty can also work on a distant terminal
after a rlogin... you do not know even if /dev/keyboard exists.
> > - You can have multiple screen/keyboard (still ONE serial
> > line or device) with complete state saved independantly
> this is adressed in my version 0.1 of the protocol.
It is also defined in the kernel (Alt Fn) and in the "screen"
package and the "split" utility. You really want to add another
standard ? It is already so complex that nobody wants to dive
into it !
> > - They have added a nice mouse control in VT1200, where
> > you say when to notify (send me a report when mouse leaves
> > the area defined)
> this is nice, but is the responsibility of X or similar, and X needs all
> intermediate info for notifying apps about cursor moves. It's true that
> most of the time this feature is not used...
Midnight Commander uses the mouse, and a lot of editors could
also if there was one simple system, available in text and graphic
mode (transparently). The VT1200 system is simple enought to
manage text-mode menus with mouse on a 9600 baud line.
> > - you can reach and configure a printer (same serial line)
> this is doable with v0.1 of this protocol, though the bandwidth is lower
> than 1/4 of normal (1/2 in the newer one)
Yes, but you reach the printer which is "attached", i.e. near the
user keyboard, even with a 3 level rlogin through a Vax.
> > - you can localy cut and paste, or between session...
> what do you mean? as i understand it, this is not strictly
> keyboard-related, and this should be handled by a filter on top of
> /dev/keyboard, under /dev/tty, or something. this is not to be handled by
> /dev/keyboard.
So many things are linked together here: to be able to cut&paste,
you need to stop the display, and pasting is "make as if those keys
have been typed". You get which character to paste by reading the
display and what should be send as key pressed/release ? Which
time interval between keypressed and keyreleased ?
Also adding another layer (as gpm do) do not simplify the work
of application programmer.
> > - you can switch serial protocol on the fly
> from what to what protocol? which protocol layer, like switching from
> VT1200 to VT100? still not related... though now that i think of it, this
> general protocol could be used to send info about partially interpreted
> keys, after mapping of scancode, say, #16 (0x10) to the letter 'Q' or
> 'q'...
That was just to say that my solution (using the complete DEC VT
protocol) is possible and can be backward compatible with software
using differences between Linux console and VT100 standard. There
is still legal problems.
It is indeed not related to your proposed system.
> > - The ESC problem has never really existed (flames waited)
> i could flame if understood what you mean. What is sent when you press
> escape on that kind of keyboard?
The problem is that there was no ESC key on those keyboards, ESC
was a serial protocol matter - used to transmit function keys like
"F1" or "Exit" (multi char code beginning with '\033') on a serial
line. For instance, pressing F1 send "\033[21~" on the serial line.
Adding ESC to the PC keyboard was one of the first war between PC
and mainframe. It still exists because descriptions of serial
terminal (termcap/terminfo) are still 7 bit character(*), and
"curses" is still using them to talk to serial terminal, like the
Linux console in text mode or every Xterm...
Curses is able to adapt to thousands of terminal - most of them
have completely disapeared from earth - but curses is used by
"man", "more", "less" ... and some serial terminal are still there
(and do nicely their job as main console, at least to log Oops)
A so old story, I didn't see the very first beginning, but so much
cleanning has to be done there - years of work, just to be able to
cleanly manage the ESC key of PCs !
So for me, when you say "let's add another layer", I become quite
nervous.
(*) It cannot be changed because some terminal include the char '\0'
as code sended when you press one function key (xterm defaults),
and because '\0' is the string terminator in C, it is coded
in these terminal description database as '\200'.
All real DEC compatible terminal is able to start function-key
coding using another 8 bit char as introducer (DCS, '\x9B')
instead of ESC, but see previous sentence.
> matju
Sorry to be so long,
more info available on request,
Etienne.
Note: I did not received any linux-kernel E-mail for two days...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu