Graphics issues

[John Whitley whitley@cs.buffalo.edu]

John Carmack <9fans@cse.psu.edu> wrote:
>Events:
>
>Plan 9 should have a /dev/events device that combines the mouse,
>cons, and time devices.  There would be sizable efficiency,
>development ease, and user interface benefits from this.

Since the worm can of event handling has been opened, I'll toss a few
more ideas out.  It would be nice to have an elegant structure for
adding extension event streams.  E.g. spaceballs, touch screens, EM
field sensing devices (see CHI '95 proceedings, p. 280), and so forth.

Consider the following:

Create a special /dev/events/evstream that gives the proper event
interleaving for all event drivers in the current view of a
/dev/events directory tree.  This could include /dev/events/mouse,
/dev/events/cons, /dev/events/time, and possibly novel input event
drivers.  An application might then mask its event stream by modifying
its view of the /dev/events tree accordingly.

Assuming that the above is both feasible and sensible, it could also
provide a nice mechanism for integrating alternative event streams
into the event stream.

As opposed to the idea of using a control file for event selection, I
envision the evstream device as a sort of multiplexer that manages
streams from a set of input devices.  Event selection then gets left
to the file system layer, where evstream is only called on to manage
event streams from other drivers visible under /dev/events.  A
significant question remains: is an elegant implementation possible
that meets the reliability (no misses) and temporal ordering
constraints raised by John Carmack?

>I see this as a no-drawbacks, just-plain-right thing to do.

I have to agree with the issues that John raises.  Multimedia and
highly interactive applications are going to happen.  It is tantamount
that efficient and well-thought out support for these be integrated
into Plan 9 if it is to survive.  Wouldn't a VRML browser for Plan 9
be nice?

There are all sorts of applications that could be hindered by a lack
of proper multimedia support.

Now to turn the coin over, consider building a /dev/multimedia that
handles some of the ugly aspects of displaying synchronized video and
audio streams?  There is some question in my mind as to the format in
which to provide the raw streams to /dev/multimedia in such a manner
that it can synchronize them.  Might make a nice distributed solution,
too: audio and video streams from separate sources could arrive at a
an instance of /dev/multimedia to be synchronized and displayed at the
local machine.

-- John Whitley