nanogui: Multiple Mwin Apps


Previous by date: 7 Sep 2000 16:55:05 -0000 A one button program, Alfredo Masias
Next by date: 7 Sep 2000 16:55:05 -0000 Re: A one button program, Marek Peca
Previous in thread: 7 Sep 2000 16:55:05 -0000 Re: Multiple Mwin Apps, Greg Haerr
Next in thread: 7 Sep 2000 16:55:05 -0000 Re: Multiple Mwin Apps, Lindsay Mathieson

Subject: RE: Multiple Mwin Apps
From: "Rob Taylor" ####@####.####
Date: 7 Sep 2000 16:55:05 -0000
Message-Id: <002201c018ec$a44aae00$b400a8c0@eventhorizon>

> : I hope you remember what my suggested solution to the problem was, waaaay
> : back... you have every program doing their own drawing to the screen (with
> some
> : sort of region manager process managing where processes have the
> right to draw
> : to), then you can have all the API calls executed entirely within that
> process,
> : no need for  mashalling at all. the only difficulty is whether a process has
> to
> : be root to write to the screen. (one really cool solution is to have the
> region
> : manager as a device the the programs use to write to the screen as well and
> you
> : have one secure and very fast system... !)
>
> Yes.  This is a cool solution.  Certainly the client apps need to
> open /dev/fb0 multiple times, which is a problem, but a bigger
> one remains:  having shared access to the clipping data
> structures that the "region manager" that you refer to maintains.
> Then, all src/engine/dev*.c draw routines would reside
> in a shared library, used by all processes, but having the data
> segment for dev*.c routines shared between all processes (
> or referenced thru a master psd) with complicated mutex
> access between them.

I don't quite see why the data segement needs to be shared.
devclip would work by only knowing it's own clipping region (asks the server)
devdraw doesnt need any shared information between processes (well, maybe
colourdepth. the current foreground, etc would be local to the process)
devfont, devimage, as per devdraw

devkbd, devmouse.. ah the difficult ones. basically you need the region server
to do the actual reading of the mouse/keyb and to stick events into pipes for
the processes to read out of. this is the really icky bit that requires some
though (as is recall the GGI project had a nice  solution, but I may be wrong)

devpal* bla, doesn't really have data attached.
devrgn* lives in region manager. on client side is an ipc interface to the
region manager.

Rob


Previous by date: 7 Sep 2000 16:55:05 -0000 A one button program, Alfredo Masias
Next by date: 7 Sep 2000 16:55:05 -0000 Re: A one button program, Marek Peca
Previous in thread: 7 Sep 2000 16:55:05 -0000 Re: Multiple Mwin Apps, Greg Haerr
Next in thread: 7 Sep 2000 16:55:05 -0000 Re: Multiple Mwin Apps, Lindsay Mathieson


Powered by ezmlm-browse 0.20.