> Setting the palette in a deferred manner isn't good because the queue
> entries could be quite large. Also, some programs change the palette very
> often, like in a loop. So I would imagine the queue filling up almost
> immediately.

Keep in mind that you only need a queue that's one deep.  :-)

> The trouble is, the IIsi hardware is designed to work for Mac/OS. That is,
> the driver works with interrupts on, polling the location waiting for the
> ISR to update the value. I tried this under NetBSD by installing an
> interrupt handler that wrote a volatile location that the palette IOCTL
> would poll. The code simply waited forever. Did I do something wrong or are
> interrupts masked when entering IOCTLs?

I'd probably do it something like:

	video driver:
		1. disable/block video interrupts
		2. queue new palette
		3. enable/allow video interrupts
		4. possibly sleep until palette is loaded and possibly
		   redisable video interrupts (if you can turn them on
		   and off--not just block them).

	interrupt routine:
		1. mark interrupt as serviced
		2. check for new palette, if no new palette, go to 5.
		3. load new palette
		4. mark palette as loaded
		5. return from interrupt

Keep in mind that the video interrupts are running at least 30x, but
probably more like 60x / sec.

> I've debated which is better: writing docs or writing code.

It's always a trade-off.  At some point, it's great to have the docs
even for yourself, but code is always nice to have, too, of course, and
can be its own documentation.  :-)

-allen