Event rings
This is a new concept I am thinking of to enhance interface-consistency
for KGI. This is not yet implemented and we are not sure if it ever will
be. It is there for you to have a look at it and send me comments about
it.
We should think about changing the core-design to go toward something
like " Focus = ring of Event-Handlers".
I think it would unify and simplify many things.
Of course this is an issue to be addressed after the Linux Congress, as
you should "never change a running system" ...
The idea is about the following :
- Definition FOCUS :
A FOCUS is a logical group of physical DEVICES and associated helper programs
called PARSERS which make up on Input/Output unit as the user sees it.
- Definition DEVICE :
A DEVICE is a physical unit which is able to send or receive EVENTS.
DEVICES communicate with each other using EVENTS (they may bypass this,
if speed is very important and it is very improbable, that other DEVICES
or PARSERS are interested in the particular Event).
These EVENTS are associated with one FOCUS. To receive EVENTS, the DEVICES
attach a HANDLER to a FOCUS.
Any DEVICE can send to any FOKUS. (to allow for things like focus-change,
see below).
- Definition PARSER :
PARSER are virtual devices which translate events or forward them to parties
outside the Event Ring. An example of the latter mode of operation is giving
out keystrokes via /dev/tty[xx].
- Definition EVENT :
An EVENT is a structure which is used to transfer data from one DEVICE/PARSER
to another. It always contains the following fields
- LENGTH : The first field of any event structure holds its length. This
helps if you need to pass on unknown events to some other layer (IO-streams,
e.g. ).
- SOURCE : Each DEVICE/PARSER is assigned an unique ID which is used
to identify it and distinguish several devices of the same type. - DESTINATION
: Events are normally broadcast (DEST=0), but there are cases where you
want to sent to a specific device (setting Keyboard-LEDS e.g.).
- EVENTTYPE : What general kind of event we have KEY,POINTER,OUTPUT,
SYSTEM, POWERFAIL, ...
- SUBTYPE : a more specific description of the event (e.g. key- PRESS/RELEASE).
- EVENT_SEQUENCE# : It might be helpful, if you can refer to a specific
event when sending "replys". The event sequence number is automatically
set in the struct when sending it.
The common Linux-Console would be represented by a FOCUS to which the
following DEVICES/PARSERS are attached :
- DEVICES:
- GGI-Output-Device
- Keyboard
- Mouse
- maybe Joystick, Sketchpad, ...
- PARSER:
- LOADKEYS
translates KC_LINUX_RAW Events to KC_COOKED ASCII-Sequences, SAK events,
FOKUS-CHANGE, ...
- VT100
translates OUTPUT_COOKED Sequenzen (as send by ttyif) to OUTPUT_RAW as
understood by GGI
- TTYIF - gives out KC-COOKED sequences on /dev/tty sends output from
/dev/tty as OUTPUT_COOKED events
- SELECTION- catches MOUSE_EVENTS and send GGI-COMMANDS (for markup)
and KC_COOKED (for paste) as necessary
The Point about all this is that _everything_ works "the same way".
For example pressing a key will result in :
- The keyboard-driver sends e.g. KC_LINUX_RAW 30 (=a)
- LOADKEYS sees the event, checks shift-state and sends KC_COOKED 0x61
(ASCII-a)
- TTYIF stuffs this into its output-buffer. As echo-mode is on on /dev/tty,
it additionally sends OUTPUT_COOKED 0x61
- VT100 sees a plain letter (i.e. no ESC-sequence) arrive and sends OUTPUT_RAW
0x61 OUTPUT_ADVANCE_CURSOR
A nice effect of this scheme is, that you can simply switch /dev/tty[xx]
to "transparent-mode" and you will see everything that happens.
I.e. you can see Mouse-movement,Joystick button-press, ... all with only
one device.
On the other hand :
The XTERM Parser can use Mouse-Events itself and send the appropriate ESC-Sequences.
If you want to see "all and everything", you open /dev/tty
and set it to transparent mode.
FOKUS-CHANGE is a quite natural process, then :
The requester (which will be LOADKEYS in the normal case, but it could
be asked for by an ioctl to /dev/tty, too (chvt x)) sends NEW_FOKUS to
the corresponding FOKUS-Event-QUEUE.
All devices attached there will take appropriate action :
- The keyboard will probably only set a variable that says send further
Keypress-Events to FOCUS xx.
- GGI will unmap the current console and map the new one. ...
- most PARSERs would ignore such a change, as they do not mind, if they
are in fore- or background.
I think you can do a lot of funny-to-useful things with that scheme
:
- A Dual-Head Machine may have a "common-Fokus" which has both
displays and both keyboards registered. If you send a NEW_FOKUS to it,
both keyboards and displays are equally active and you have some kind of
"Application sharing". This way you can share about any device.
Eventually you will need some kind of "LOCK-DEVICE" to take care
no other user can "take away" a device you are using. But as
sharing does only make sense for devices which are in physical reach of
both users, they will probably be able to arbitrate access ;-)
- Another nice point is, that making up a "Remote-Control"
is easy : You simply set IO on both sides to transparent and "short-circuit"
the devices using a network-connection.
O.K. - so much to it ... please comment on it !
Send comments to : Andreas Beck, mailto:becka@sunserver1.rz.uni-duesseldorf.de