From: James Simmons <jsimmons@edgeglobal.com>
  To  : GGI mailing list <ggi-develop@eskimo.com>
  Date: Fri, 20 Aug 1999 21:05:30 -0400 (EDT)

Re: KGIcon multiheading

On Fri, 20 Aug 1999, Jon M. Taylor wrote:

> 	I tried to find a way to implement multiheading via /proc/kgi/[n],
> but I could not discover a clean way for the first loaded KGIcon module to
> create /proc/kgi and the rest of the modules to be able to hook into it.  So
> I decided to fall back to just creating /proc/gfx[n] instead.  I don't like
> this solution, but until we get devfs I don't see an alternative.  At least
> it is an aesthetic problem and not a functional one... the gc and kgicommand
> mapper files are now created in /proc/gfx[n] on a per-head basis as well, 
> BTW.  Everyone, please let me know if you see anything necessary for the 
> multiheading that I missed.

Well for 2.3.x this will be fixed, well at least for fbdev. I just
released my patch to the kernel community and once it applied true
multiheadedness will be availble for fbdev. Note fbcon is still broken
because it depends on the linux console code which is still broken :( 

  Well the patch will be fixed up over the next several days but now that
been done its time to focus on the developement of /dev/gfx :-> Kernel
hardware acceleration here I come. Well I have been looking for possible
solutions to the accel and framebuffer access problem. I have notice a
nice like function which has not been implemented yet for vm_ops.

unsigned long (*wppage)(struct vm_area_struct * area, unsigned long
address, unsigned long page);

>From linux/mm/memmory.c

/*
 * This routine handles present pages, when users try to write
 * to a shared page. It is done by copying the page to a new address
 * and decrementing the shared-page counter for the old page.
 *
 * Goto-purists beware: the only reason for goto's here is that it results
 * in better assembly code.. The "default" path will see no jumps at all.
 *
 * Note that this routine assumes that the protection checks have been
 * done by the caller (the low-level page fault routine in most cases).
 * Thus we can safely just mark it writable once we've done any necessary
 * COW.
 *
 * We also mark the page dirty at this point even though the page will
 * change only once the write actually happens. This avoids a few races,
 * and potentially makes it more efficient.
 *
 * We enter with the page table read-lock held, and need to exit without
 * it.
 */
 

Now this also works for non shared pages. In the case the page is not
shared then the protection is just changed to make it writable.