Weird Idea

[evanlang@uss.lonestar.org (Evan Langlois)]

Last night I got a really weird idea.

Would it be possible to reduce GEM polling through the use of an Fselect()
call inside a trap #2 handler.  The trap handler would intercept evnt_multi()
calls.  The new evnt_multi() would call the old evnt_multi(), but with a
timeout of 0 - letting any pending events get taken care of, etc.  If this
returns with no events but a timeout, then call Fselect() waiting on a 
custom driver.  The Fselect() would use a timeout equal to the evnt_multi
timeout.   If the Fselect() times out, return a timer event.  If the Fselect
wakes up for data, then call the real evnt_multi() - allowing the AES to
do the rest.  There is a special case for keyboard events.

The device driver would just wait for mouse button and mouse movement
interrupts (the replacement evnt_multi may have to check for rectangle
events itself instead of letting the AES do it) - could probably use the
LineA vectors.  When an interrupt is recieved, unselect and wake up the
Fselect'ing processes or whatever, and then pass the interrupt through
the system (if you get it from the LineA vectors, pass through the original
vectors, etc).  Maybe delay passing through the vectors for 1 or 2 timer
ticks to make sure the replacement evnt_multi() has called the real
evnt_multi() by then.

Would this be possible?  I would guess that MultiTOS does something similar
but I don't have MultiTOS and there is no telling when the non-polling one
will be available.  If such a hack is feasible, then perhaps this would be
a good thing to work on.  Everyone says that MiNT is slow, and of course,
all background tasks suffer from GEM polling.  If that polling could be
minimized a bit, I think I'd use GEM more often :-)  And I think others
would use MiNT more often.