[9fans] Plan9 commercial licenses

[Eric Dorman eld@jewel.ucsd.edu]

 
> Date: Tue, 30 Sep 1997 14:20:47 EDT
> From: Scott Schwartz <schwartz@finch.cse.psu.edu>
> 
> eld@jewel.ucsd.edu (Eric Dorman) writes:
>  | sort of arrangement before.
> | Actually I have some of the 16b/32b color fixed: a compiling blit that
> | works for 16b/32b, hooks in devvga, etc.  Have to examine the other
> | parts of libgnot, cope with the colormap stuff, and steal my Matrox MGA
> | back :) .. probably integrate the softscreen and hardscreen somehow..
> 
> Speaking of that, has anyone thought about building chipset specific
> versions of /dev/bitblt?  (i.e. bind /dev/ark2000 /dev/bitblt)
> In a lot of cases you might be able to avoid software bitblt entirely, 
> and use the wizzy hardware instead.

Yes; that's my next thing on the long list of Things I'll Probably
Be Too Tired to Do :)   Another way of doing it (rather than redo
all of bitblt for every hw) would be to have brains in devvga that
knew about chipset features, then make gbitblt() into (*gbitblt)()
(and others for gbline(?), etc) so bitblt will drop into the hw-specific
code instead.

Of course, might be slicker to have bitblt code in a userprocess,
but would there a performance hit?  Might not matter that much.

I got wedged trying to scribble into the Matrox MGA from a user process
because I couldn't figure out how to wire a user page to a physical
address that was higher than KZERO (0x8000000).. the PCI bios tends to
wire my MGA framebuffer to 0xe800000 and segattach won't allow physaddrs 
that high.  I *could* change the MGAs framebuffer addr but I'd prefer
to let PCI bios set it up where it thinks is ok (as if pci bioses always
worked right, heh).

eric