Re: Necessity of multi-level error propogation
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 -> P=
ROGRAM
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 compu=
ter.
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 seq=
uence
repeatedly to the computer.
3. In the computer, receiving hardware+software logic BUFFERS it al=
l.
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.
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 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).
[...]
One rational way to do things could instead be
PHYSICAL EVENTS -> BUFFER -> DECODING -> AUTO-REPEATER -> P=
ROGRAM
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.
And finally, I'm not sure what the relationship here is with
regards to decoding; I don't see any problem with decoding at
the very last point in the chain, just before returning the
character to the application, and only if the application
requests it.
I'm also very unsure with regards to how modern Windows handles
this. The Java Swing KeyListener interface provides
notifications for keyPressed and keyReleased, as well as
keyTyped, so presumably, you can get this information from
Windows as well.
[...]
Except that you don't use the sequential stream interface
for GUI I/O. You use specific functions in the X or MS
Windows libraries.
No and yes. No, that backwards model is not only with
sequential stream interface, instead, it's embodied in the
hardware and OS but it seems to be associated with the stream
i/o point of view: to the degree that it makes any sense at
all, it wouldn't make sense without the stream i/o view.
The only really intensive stuff I've done with GUIs was in Java,
and for most of the stuff, we handled the low level keyboard
events ourselves---the auto-repeat, if there had been any, would
have been in the application. So the model isn't cast in stone
in the OS or hardware; you can do things however you want in the
application, if you want to go to the effort.
And yes, this is how it is via the OS API, although e.g.
Windows "on the side" provides a not quite reliable current
keyboard key state map (which is possible because a PC's
keyboard differentiates between between first actual key-down
event and later synthesized key-down events for auto-repeat;
it's unreliable because the generating logic is in the
physical keyboard, at the wrong end, and most keyboards aren't
able to handle the situation with 4 or more keys pressed).
In other words, you're saying that it is the keyboard hardware
which simulates a key released/key pressed event pair to
implement auto-repeat. That sounds a bit wierd. In the two
event model, I would expect auto-repeat to be implemented in the
OS. And I'd be very surprised if you couldn't turn it off (but
I'm often surprised by things on PC's).
And I suspect that there is a connection, that the hardware
has been adapted to what was easy to handle within that
less than practical i/o model.
I don't think there's a problem with the hardware.
Well, perhaps amend that conclusion after my clarifying
comments above? :-)
It's the hardware.
Then they've gone a step backwards. When I worked on keyboards,
this sort of thing was programmable.
And it's the OS interface to that hardware.
And how the OS programs the hardware?
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34