Re: GGI, EGCS/PGCC, Kernel source

Jason McMullan (jmcc@pepsi.visus.com)
26 Feb 1998 00:51:59 GMT


Alan Cox <alan@lxorguk.ukuu.org.uk> wrote with confidence:
> 1. If you only allow one user to have the frame buffer a time and keep
> context on switches.
>
> 2. If you dont pull MMU stunts to fault/block other tasks touching
> the memory during such events. Also note most operations take so
> few cycles a non scheduling spin is no big deal (SMP needs the mmu
> stunt always alas).

The current EvStack code works on these principles (most of which
were learned in the GGI 0.0.9 devel process). The implemention of
the /dev/graph is like this:

*) Only _one_ graphics app can open a VT at a time.
*) The currently active VT on a head can call mmap()
on card framebuffer and acceleration MMIO regions.
*) When a VT-switch is requested, SIGTSTP is sent to
the process and the VT is switched. Current mode
state is preserved, but NOT accel queues. If an
app tries to access the MMIO regions while switched
away, it gets a SIGBUS.
*) On VT activation (switch-to), the old mode is set,
SIGCONT and SIGWINCH are sent to the process. The
app can now use the old MMIO mappings, and re-draw
the screen.

Simple. Elegant. And it works.

-- 
Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc
NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix
isn't in the coffin... It's wondering what the heck is sealing 
itself into a wooden box 6 feet underground... 

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu