Cesar Crusius writes:
> Well people, here's the situation:
> * I have a gnuplot driver that works in X but fails when in console mode.
> * I hacked dvgt, so that now *I CAN SEE DVI FILES WITH GGI*. It works in X,
> but then again, IT DOESN'T WORK IN THE CONSOLE!!! And that, of course,
> is what I wanted the dvi viewer for.
UNIX has some ancient thing called "job control". Programs started as
_background_ processes (e.g. from a main program) are denied access to
the TTY (i.e. the VT), they can't write to it or get input. I suppose
the idea was, programs could be spawned and they shouldn't mess up the
main program's screen. It's a bit bizarre, involving "process groups",
"session leaders", "controlling TTYs", and the parent/child/sibling
relationships between processes (I don't remember the exact details).
So when you try running a LibGGI app in the background (e.g. spawned
from another program), things don't work properly. Frame buffer
devices are somewhat detached from VTs, so it is possible for LibGGI
to draw on the screen when run as a spawned process, but input can be
blocked due to the job control kicking in.
You said you couldn't switch consoles, here's my guess why: LibGII is
able to put the VT into "RAW" mode (giving full keyboard access), even
though it can't read the data. The Linux philosophy is to turn off
kernel-level console switching when in RAW mode (the application is
supposed to recognise the keys and do it itself), but since LibGII
can't see the keyboard input, it can't perform the console switching.
(There's a word for that Linux philosophy: BRAINDEAD, completely and
utterly dead in the head). And since the keyboard is in RAW mode,
stuff like CTRL-C to kill the main application doesn't work either.
And if the main program crashes, the kernel doesn't reset the keyboard
or reset the framebuffer videomode, so you are stuck sending garbage
key info to a shell you can't see. It wouldn't be so bad, if we had a
shell that could detect that the keyboard and/or framebuffer were in a
screwy state and reset them to normal. But that's hardly the UNIX way,
where allocated memory is freed, file descriptors are closed, etc...
by the kernel when a program exits or crashes.
Enough preaching :-), I think you said your structure was like this:
octave -> gnuplot -> LibGGI viewer
Is octave a full screen console app like midnight commander ? If it
is, then I think you're out of luck unless you make it switch to a new
VT (and that requires root privs to be done 100% reliably).
If it isn't, you may have more luck with a structure like this:
LibGGI viewer -> octave -> gnuplot
and making gnuplot output to a file in /tmp/ that the viewer then
displays. Yuck, but those two ways are the only ones I know that
could work using the Linux kernel VT semantics.
It's an interesting problem, and tends to convince me of something I
said before: the best system (under a UNIX-type OS) would be to have a
single server that has access to the screen & input devices, and which
implements the "virtual terminal" abstraction (including graphical
VTs, e.g. possibly containing an X window system). This server would
not be unlike an X server in many ways, but with GGI technology (and
putting X in a separate server that logically sits on top of it), it
would be orders of magnitude smaller (and 100% reliable).
\/ Andrew Apted <[EMAIL PROTECTED]>