Re: MADO and Graphics

From: David Jeske <jeske_at_nospam.org>
Date: Sat Oct 03 1998 - 12:45:26 PDT

On Sat, Oct 03, 1998 at 01:35:00AM -0400, Brett McCoy wrote:
> On Fri, 2 Oct 1998, David Jeske wrote:
>
> >I remember Dave Hudson saying something about having a prototype
> >bitblit almost working for VGA.
> >
> >However, I wouldn't be surprised if I'm wrong, or if he can't find it
> >anymore.
> >
> >Anyone up for porting X?
>
> You might want to take a look at GGI. It's way more flexible and useful
> than straight X, and there is an X server already ported to talk to GGI
> instead of native frame buffers.

GGI is definetly the way to go. Last time I paid attention to their
stuff, they had finished their 'proof of concept' and had mostly
started over from scratch to do the real implementation.

On VSTa, there would be a user level GGI server which would load ggi
drivers and handle the console issues. Programs would communicate with
GGI via VSTa IPC instead of kernel calls. There are a few cases where
the GGI server would want to setup a shared memory region to let the
client talk directly to the hardware (most often the framebuffer).

Andy: if a server setup a shared memory segment on 'physically mapped
pages', and then a client connects to it, is it currently possible for
the server to change the physical pages that shared memory segment
maps to after the fact?

I believe this would be required for GGI to work, because the server
needs to be able to switch the client mapping from the 'real
framebuffer' to a 'backing store' without the client knowing about it.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske_at_chat.net
Received on Sat Oct 3 08:40:17 1998

This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:44 PDT