From: teunis <teunis@computersupportcentre.com>
  To  : andreas.beck@ggi-project.org
  Date: Fri, 18 Sep 1998 13:35:24 -0700 (MST)

Re: New target `display-tele' committed

On Fri, 18 Sep 1998 becka@rz.uni-duesseldorf.de wrote:

> Hi !
> 
> > Geez - you have no ambitions to replace XFree, don't you?
> 
> *grin* No - LibGGI is not designed to be run over the net. Except if you
> ignore the possibility of some functions failing.
> 
> FullASYNC mode (not yet implemented, though now might be a good time to
> start it, as it gets useful now) would help here.
> 
> FullASYNC means that LibGGI is free reorder drawing requests, and the
> failure is _not_ immediately reported. This allows for taking full
> advantage of queueing.
> 
> > A much easier way (IMHO) : draw to a normal memory target and give that
> > memory region to OpenGL for use as texture. 
> 
> Yes - this is a suitable implementation idea for the server. However
> 
> > That way you (1) are not constrained to cubes 
> *grin* - that is a historical joke :-).
> 
> > and (2) don't have the networking overhead.
> 
> The idea is to run unmodified GGI programs on each side, so they should
> run independently, thus demanding a communications mechanism. The net
> target is one possibility. A display-shmem might be a faster one ...
> Anyone ? Should be trivial.

The only real reason I don't have it working now is ... console
arbitration + this target :)

So the target / source need some details:
	Source needs to arbitrate devices [not target!]
		This way keyboard can switch consoles, as can mouse :)
	Source needs to switch consoles...

The first point is why I was waiting on EvStacks...  but I can't see why
it can't be done through pipes from the server to the client.  could make
it a bit tricky though.  (easier to build this way than encapsulating
everything in one stream like X does)

G'day, eh? :)
	- Teunis