Hi !
> Obviously in all "demos" there are global "vis" (visual) variable-pointer, which is
>directely
> in connection with ggiOpen, but indirectely in connecttion with "command line
>arguments and
> environmental variables"?
Yes. Most demos call ggiOpen(NULL);. This will automatically choose the most
suitable target for the current execution environment.
However at time you will want to override this. Therefore GGI_DISPLAY will
allow to force a given target, as if ggiOpen(getenv("GGI_DISPLAY"),NULL);
was called.
Note, that you cannopt override explicitly given displays.
> So, obviously you open one default visual, and 6 memory-visuals. Obviously they have
>their
> memory - because shmget allocates it for them.
Yes.
> Tell me if I am wrong, they (processes that are attached to this visuals) think
>about
> memory-visual like it was (one default "global") or fbdev, x, or similar, meaning
>visual
> on real-target?
Yes. A visual is except for speed and availability of some advanced features
like DirectBuffers indistinguishible from another one.
> So always only one is visible, or "active on display"?
I do not quite get you here. If you mean: The subprocesses that display on
the cubes think, they are active on a "real" display, you are right.
> And, you activate appropriate "program[0-5]" from int spawn_bg(char *what) or better
>via
> execlp("/bin/sh","/bin/sh","-c",what, NULL);
Yes.
> (WHAT MEANS OPTION "-c", THERE IS NOTHING IN "man"?),
Huh ? My manpages say:
OPTIONS
In addition to the single-character shell options docu-
mented in the description of the set builtin command, bash
interprets the following flags when it is invoked:
-c string If the -c flag is present, then commands are
read from string. If there are arguments after
the string, they are assigned to the positional
parameters, starting with $0.
So -c allows to give a "mini script" to the shell for execution. the reason
for not just execlp()-ing the program is, that I can use shell-patterns and
stuff when using the other method.
> how "it"-program[x], knows what are parameters, since only "char* what" is
>transduced to it, and
> HOW IT KNOWS ABOUT HIS (ITS) SHM?
Its environment is set up appropriately. It is told to run on the
appropriate shm visual by having an environment of:
GGI_DEFMODE="320x240.V320x240.F1.D1x1.[P8/8]" # This one tells the
# resolution the program
# should run
GGI_DISPLAY=display-memory:-input:keyfile:142336:0:/dev/null
# this one tells the program to run on a "display-memory" visual.
# It also tells the memory visual to activate its input code (which also
# uses shmem to pipe events into the otherwise deaf memory visual) and
# to use the shared memory identified by "keyfile:<size>:<id>:<fname>"
# Read ftok() to find out more about keyfiles.
> You never "shmat" this "shmid[0-5]"?
This happens implicitly in the memory-visual code. The reason I extract the
value is only for demonstration purposes.
> Is "cube3d" some manager which decide what "program[0-5]" will be run in
> "vis" and others are running in "mem-vis[]"s?
All client programs run in mem-visuals. The cube program itself runs on a
real one (well you can also run the cube on a side of a cube on ... :-).
> Are the rest (which running in mem-vis[]s) visible?
No. They are running in memory. The cube program makes them visible by using
them as textures for drawing the cube.
> Are they acutaly running or they are sleeping
They are active as if they were on a "normal" visual. I.e. if they are
waiting for input, they will block as usual, otherwise they will run.
> (in some wait_queue or similar, waiting for "event" which is of course
> puting-them-infront"?
In that sense, they are sleeping (if waiting for events). Events are
transported using the very same shm that carries the picture to the
cube application.
> After that you ggInit (clear), vis = ggiOpen (clear), other BG/FG/Mode stuff (clear)
> and ggiFlush! I have read about ggiFlush but it is not quite bright to me:
> * is it called before every accel-related or ggi-related or what command (function)?
> or
> * is it called after some sequence of accel-related or ggi-related or what commands
>(functions)?
It is called after any chang you want to make sure is made visible within a
reasonable amount of time.
The reason for the flush() call are targets that are asynchronous in nature,
like X. That is, if you issue some drawing request, it may be delayed for
arbitrary amounts of time, if you do not explicitly request a flush(). This
is done for performance reasons.
> I have noticed this stuff about ASYNHRONIOS executing of accel commands,
This is a different story and we will need to add a few extra calls for
that.
> but I have seen (concretely in ggi-examples or related code) that ggiFlush is called
> without ggiSetFlags set ASYNC?
It can be called anytime, though in SYNC-Mode it is usually more or less a
NOP.
> // BEGIN in one process
> // in some process-function I have unsigned char* ptr = calloc (<some-calculations
>in otheer function based on bitmap-file>);
> // which is then loaded and passed to bitmap-pointer, and key is ftok-ed from path
>of bitmap-file and defined character
> ...
> int shmid = shmget(key, (int) sizeof(bitmap), IPC_CREAT|IPC_EXCL|0666);
> ...
> char *segptr = shmat(shmid, 0, 0);
> ...
> memcpy(segptr, bitmap, sizeof(bitmap));
> shmdt(segptr);
O.K. - picture is in SHM then. However you can use a LibGGI memvisual for
it, which saves you working with shm directly at the expense of some extra
overhead..
> ...
> // so another process can now (of course if I sinhronise it) "open" and "attach" and
>use this memory
> // so I can free bitmap??? Responsibility of the other procees is to REMOVE SHM?
Yes. For removing shm, there is a commonly used trick, which is to remove
the mem, when all attaches have been done. The memory will then be removed
at the last detach.
> About directbuffer... Well this part is interesting but I must admit "cube3d" is
>very layered, so I understood
> (as I can since I have "constrained" knoledge in 3-D domain) that you use
>"ggidirectbuffer" for achieving
> texture manipulations?
In that very example, yes. It is just a direct path to the framebuffer or
any other "buffer" (i.e. memory area) the graphics subsystem has.
> So, I suppose it used when you have to change pixel directely, without changing
>neighbouring one?
It is used, if you want to have a fast path to the graphics RAM when doing
pixel oriented stuff. It is most useful for doing many small changes that
cannot be reasonably accelerated as it saves calling overhead.
> Or lets say to change pixel from user process (like MMAP of pixels to user proces?)?
Yes. The directbuffers are usually mmaped directly from the hardware, if
possible. There are some exceptions, like the X target, where you only get
direct access to the shm-copy of the visual.
> In "cube3d" you use mode-setting with 2 direct-buffers...
It uses a 2-frame mode, if you mean that.
> maybe that is the problem why "cube3d" do not work at my Trio-accel
> machine under kgicon.o.
Might be. What happens ? Mode is rejected ? Try a low-resolution mode.
> (It works under x-server, but I am to stupid to use it-)))) I tryed it with:
> "cube3d -320x240 flying_ggis stars saver" and in quadrature I saw something like
>zoom-out og GGI-s and something above it,
> but after that PC-blocks, so I have to kill those processes.
Oh - well, what you see is right. Do a "man cube3d" to see how to control
the cube and the apps on it. The things should not block, though ...
> Anyway, "cube3d" do not work and use directbuffer, and "slimmy" (or simlar) works
> and use directbuffer too (only diference is in number of frames).
Sound like a frames realted problem.
> P.S. I admire to you people, you reply and want to help, no matter how
> maybe (surely) I am boring to you... THANKS
No problem. Questions are enlightening for us as well. They show where the
problems in understanding the concepts are. We don't see that, as we made up
the concepts. Your questions tell us where we need to update documentation.
This is why I CC the letter to the list. Maybe it helps others as well.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
