Graphics issues

[dhog@plan9.cs.su.oz.au dhog@plan9.cs.su.oz.au]

John Whitley <whitley@cs.buffalo.edu> writes:
>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.

This is beginning to sound unpleasantly like X  :-)  I much prefer the
way that Plan 9 handles "events" already, that is, by using concurrency
to handle multiple inputs rather than adding some mechanism for
lumping them all together.  I consider the problem seen by John Carmack
with the mouse to be mainly a scheduling problem, rather than a failure
of the design.

Consider where the mouse and keyboard events originate from.  They are
two separate hardware devices, using two separate (usually) serial inputs
to pass information to the terminal.  Any "proper event interleaving" is an
illusion.  This illusion can either be created in the kernel (as you suggest)
or in user mode (eg by libevent, or explicit use of concurrency).  The only
advantage in doing it in the kernel is that the interleaving occurs at interrupt
time, and hence with greater accuracy.  The user mode solution has the
advantage of generality.  (Ok, so you have to rfork() some extra processes,
but they're cheap on Plan 9).  If you get the wrong interleaving this way,
then it's the scheduler's fault.  Note that, as Phil pointed out, Plan 9 makes
no provision for real time scheduling.  You can, however, give some processes
a better priority, which might help.  Try writing a message of the form "pri n"
to /proc/<pid>/ctl.  "n" should be between 0 and 19 inclusive.

It's probably not helping that /dev/mouse is state driven, rather than
event driven.  Ideally, from the point of view of game playing, you want
the raw data straight from the mouse (but in some standard format)
rather than what /dev/mouse gives you now.  Similarly, you want all
the key presses and releases.  This has already been discussed on
9fans.  These raw devices should be added to Plan 9 as a matter of
urgency, to increase its utility as a games OS  :-)