From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue, 30 Sep 1997 11:44:06 -0700
From: Eric Dorman eld@jewel.ucsd.edu
Subject: [9fans] Plan9 commercial licenses
Topicbox-Message-UUID: 673c1422-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19970930184406.LsCoJe-hmLvl078hGYF7qt5zz4bGdxmMQlVqviwhOgg@z>

 
> 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