From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Thu, 17 Sep 1998 19:38:54 -0700 (PDT)

Re: Glide-target now works again

On Thu, 17 Sep 1998, Marcus Sundberg wrote:

> Jon M. Taylor wrote:
> > 
> > On Wed, 16 Sep 1998, Marcus Sundberg wrote:
> > 
> > > I've added event handling back to the glide target and it now uses
> > > the Linux_common files for keyboard and mouse support.
> > 
> >         Thanks a million.  I am still getting segfaults with everything,
> > though.  I even blew away my whole CVS tree and re-downloaded it to no avail.
> > Are you sure you committed everything?

	Nevermind.  I am having some wierd problem where 3dfx.o fails to
insmod sometimes and that was causing the problems.  Everything appears to
work fine now, except that I can relibaly hand my machine by running
dots.c with the Glide target.
 
> > > In addition
> > > to that it supports VT switching, which I don't know of any other
> > > glide app that does. ;)
> > 
> >         YEAH!  AAaaaaaahhh!!!! I wanna see this!
> 
> Yep, it's pretty nice. Now I _really_ need to get some more monitors
> to take advantage of all the nice features GGI has given me. ;-)

	If you get a y-splitter VGA cable you should be able to multihead
by running one into the Voodoo card and another directly into a monitor. 

> > > I've also removed the directbuffer hack
> > 
> >         What makes you call it a hack?  I agree that it was slow, but was
> > the only way I could see to do nonblocking display flushing since you
> > can't write to the hardware framebuffer without acquiring a lock through
> > Glide.
> 
> It's a hack because it emulates a DirectBuffer. This should never be
> done
> unless it gives a significant performance boast.

	OK I see.  I was copying from some other target, probably the 
AALib target.  My bad.
 
> > I took a quick look through all that new code you added but I
> > have to confess that I don't grok a lot of it.  What happens on a VT
> > switch?  Does the app sleep?
> 
> Yes, the vtswitch.inc code calls pause() on switchaway. So the app wakes
> up on switchback. But actually it doesn't have to do this, as the kernel
> aren't running any consoles on the 3DFX board we could very well keep
> on drawing after switchaway.

	But only on one visual.  If multiple programs open a Glide visual 
there needs to be some way to multiplex Glide between them, right?  That 
is why I used the DB hack.

> We have actually two alternatives:
> 1. Keep the app running on switchaway - only one glide app at a time.

	Three if we do some hackage to have them all draw to different
buffers on the card at the same time.  Maybe more if we play games with 
using the zbuffer as backing storage.

> 2. Call grGlideGetState() and pause on switchaway, unpause and call
>    grGlideSetState() on switchback - this should let us have several
>    glide apps running at the same time!

	Blocking IO is evil.  IMHO the apps should not have to sleep if
they don't have the focus.
 
> I suggest we allow both modes and let the user decide with an
> environment
> variable which one to use

	Good move.  I noticed today that grLfbWriteRegion() can blit 16
bit RLE encoded images into the LFB.  We could use that to dramatically
decrease the back storage memory overhead. 
 
> > How about using:
> > 
> >         grRenderBuffer(GR_BUFFER_FRONTBUFFER);
> >         grDrawPoint();
> > 
> > instead?
> 
> Ahh! Thanks, I'm new to glide and didn't notice that function.
> 
> > That should force all drawing to the front buffer.  That will cost
> > you your double/triple buffering capabilities but you said you don't want
> > those anyway.  *I* want (need) them eventually, but for now they can stay
> > out.
> 
> Not necessarily. I'll just add grRenderBuffer(<BUFFER>) to the
> ggiSetWriteFrame() function in the glide target. This will make
> libggi support double buffering on the glide target!

	Glide can do about a zillion different multiple-buffer 
techniques.  Supporting it all well will give the DirectBuffer system a 
good workout...
 
> > > Lastly I've added PS/2 mouse support to Linux_common/mouse.inc
> > > as I needed to test the mouse handling in the glide target. ;-)
> > 
> >         I've been wondering if the X_common and L_common code wouldn't be
> > better off as a helper library?
> 
> Not the X_common code. The only code that's really common is color.inc,
> and
> that's to little to put in a separate library. The other files are full
> of
> target specific #ifdefs.
> As for L_common I don't think it's worth the trouble to put it in a
> separate
> library.

	How much trouble would it be?  Turn the .INC files into normal .c 
files, wrap them into standard mode.c, visual.c, etc files and set them 
up to be used as a helper just like vgagl and mansync.  But this is not a 
very big issue, I agree.

Jon 

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed