Re: Necessity of multi-level error propogation
* James Kanze:
On Mar 16, 11:52 am, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Mar 16, 3:07 am, "Alf P. Steinbach" <al...@start.no> wrote:
* Alf P. Steinbach:
[...]
Here's the way Things Work on a typical PC or workstation:
PHYSICAL EVENTS -> AUTO-REPEATER -> BUFFER -> DECODING -> PROGRAM
1. Under the keys there's a matrix of some sort. A microcontroller in the
keyboard scans this matrix, detects key down and key up. On key down or
key up a series of bytes denoting the EVENT is sent to the computer.
2. When microcontroller detects that a key is held down for a while it
initiates a kind of REPEAT action, sending the same key down sequence
repeatedly to the computer.
3. In the computer, receiving hardware+software logic BUFFERS it all.
The problem isn't hardware. At the lowest level, there are
two possible modes: the OS receives an interrupt for each
key stroke, at which time it can read the scan code of the
key and the state of the "modifier" keys (shift, alt, etc.).
Or the OS receives an interrupt for each key down and key up
event (including those of the modifier keys), and manages
everything itself. In the second case, autorepeat is
handled by the OS.
No, autorepeat is independent of undecoded versus decoded.
On the PC, the keyboard is undecoded but with autorepeat in
the physical keyboard.
I didn't say anything about encoded or not. I don't think that
there's a machine around today where the hardware does the
encoding. The two possibilities here concern the generation of
events (interrupts): in the one case, the system gets an
interrupt (and only one) each key press (except for the mode
keys like shift), and auto-repeat is handled by the hardware
(since the software doesn't know how long the key was pressed);
in the other, there is absolutely no difference between the mode
keys and any other keys, and the system gets an interrupt both
for key down and key up---in this case, auto-repeat is handled
by the OS.
Description doesn't match reality. I'm not sure exactly what you mean, but it
isn't the way things work. Perhaps it's this "decoded" that's problematic. A
non-decoded keyboard produces event data identifying keys. A decoded one
produces characters, except of course for arrow keys etc (I'm sure you have at
one time been familiar with e.g. VT52 terminals; the VT52 as a whole implements
a decoded keyboard, producing normal characters and escape sequences for e.g.
arrow keys). That is, in the context of keyboard i/o "decoding" refers to the
mapping from keys to characters.
At least when I was working at that level (a very long time
ago---CP/M 86 was still relevant:-)), the actual hardware was
capable of being programmed for either mode, depending on what
the OS wanted.
The PC keyboard is in a sense configurable, yes, e.g. wrt. repeat rate (the
Atari ST keyboard could be actually programmed! :-) ), but I cannot recall any
distinct modes.
The BIOS that I knew for CP/M86 and MS-DOS
programmed it for a single interrupt per key press, but the
xmodmap features of X would probably be easier to implement with
the key up/key down model (which does require more handling in
the OS).
Anyways, in the paragraph above you're treating "single interrupt per key press"
and "key up / key down model" as mutually exclusive.
On the contrary, modern keyboards produce one event per keypress (plus,
unfortunately, a lot more!), and the events they produce are key up / key down
events.
It's not either/or, it's not two different kinds of keyboard modes or something.
[...]
One rational way to do things could instead be
PHYSICAL EVENTS -> BUFFER -> DECODING -> AUTO-REPEATER -> PROGRAM
I don't know any system that works that way, however. Though I
suspect that early machines at Xerox PARC did, because those
folks were very keen on having "non-decoded" keyboard events
and, in particular, having time-stamped events.
I'm not sure what difference this would make.
I'm not that bad at explaining things, am I?
Anyway, it makes a huge difference for all aspects of keyboard handling.
With auto-repeats being synthesized as necessary on demand,
instead of being buffered, they're not being buffered. All
problems associated with that (like "delayed delete all")
therefore gone. And the application then has a different
default model where e.g. it doesn't react to arrow key
characters but instead to arrow key state, whether an arrow
key is currently down or not.
I'm still not too sure where the interface hard/soft is in this
model. If auto-repeats are "synthesized" (by the OS), then
you'd have to adopt the two event model, so that the OS could
know whether the key was still being pressed or not.
And you'd still doubtlessly want a timer, to ensure that the
auto-repeat didn't act too fast.
All the time information needed for auto-repeat is the time-stamp of last
retrieval and current time.
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!