Re: GGI extreme blues : NEED HELP
> 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 shouldn't be able to draw to the framebuffer if you are running detached from a VT. As stated above it was designed so it shouldn't mess up the main program's screen. Usually you detach from a console when you want to use the console you are on for something else. Thus drawing to it doesn't make sense. This is where fbdev is broken since it should test to see if a app that wants a graphics mode is on the local console. You don't want someone on another local terminal in a multiheaded setup starting to draw on your screen. Also fbdev doesn't test to see if a app is running remote. Thus someone can telnet in and start a X server. That shouldn't be :( I do have patches that fix these problems. Instead of the app being designed to spawn a libGGI app in the background why not have a libGGI app spawn non graphical apps. > 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. Working on the framebuffer part of this problem. Vojetch is working on the input part. The idea is to have a input queue device that sends events from input drivers to userland. While a program can still react to normal tty events. Thus it will be up to the program to take advantge of the input queue to get RAW keys and other events. If the app dies the event queue driver will not care. It will just keep sending events to other apps that are interested. I have patches that save the video mode before fbdev is opened and reset the video mode back to the orginal after fbdev is closed. Thus a crashed app will restore the vidoe mode. > 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). You would need a monster system to handle console switching with all the consoles in "graphics" mode. We found the best solution is to turn off the console output system and VT switching when a app explicitly open /dev/fbX. What you described above is screen except with more power. As for a app managing screen and input devices. Well IRIX handles it in a mixed way. The kernel for IRIX has a what is know as a rendering resource manager. Each app connects to it via what is known as a rendering node. The X server connects and sets itself up as the master node. So if a app misbehaves it can kill the process. Codito, ergo sum - "I code, therefore I am" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net
Re: GGI extreme blues : NEED HELP
* Andrew Apted ([EMAIL PROTECTED]) [000131 00:07]: > 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). > > ... skip ... Thanks a lot for the lesson. Strangely, it sort of works in octave, but fails to restore the text mode correctly. But here's the best part... I made dvgt work with GGI! We have a GGI DVI viewer!!! I'll work a little bit more on it and post it to everybody. Cheers, -- Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ Stanford University ,>/'_ ,>/'_ ,>/'_ ,>/'_ ,>/'_ e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) www.stanford.edu/~crusius HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER
Re: GGI extreme blues : NEED HELP
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). Cheers, __ \/ Andrew Apted <[EMAIL PROTECTED]>
Re: GGI extreme blues : NEED HELP
* Marcus Sundberg ([EMAIL PROTECTED]) [000130 02:03]: > > I believe the error comes from the error message (unable to open shared > > library genkgi.o) that is sent to the console and garbles everything. But I > > can't be sure. And I don't have time! > > That is not a problem. I should expect so, but that's the only visible difference between running in X and in the console. > > > Can any kind soul get the sources for dvgt I hacked and figure out how to > > make things work in the console? Every time I try to use it in the console > > the *computer hangs for good*, while in X it works flawlessly... > > Does other GGI applications work on the console? Yes (well, XGGI and peggy are the only ones I use right now). I tried ggv but it segfaults from the start... -- Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ Stanford University ,>/'_ ,>/'_ ,>/'_ ,>/'_ ,>/'_ e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) www.stanford.edu/~crusius HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER
Re: GGI extreme blues : NEED HELP
Send the source my way, I would love to use gnuplot via GGI, also I am looking at a GGI target for ghostscript. Also, it sounds as if you may simply have your console misconfigured, do other programs using GGI and the keyboard via GII work for you? -Adam Scislowicz([EMAIL PROTECTED]) > 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. > > HELP! > > I believe the error comes from the error message (unable to open shared > library genkgi.o) that is sent to the console and garbles everything. But I > can't be sure. And I don't have time! > > Can any kind soul get the sources for dvgt I hacked and figure out how to > make things work in the console? Every time I try to use it in the console > the *computer hangs for good*, while in X it works flawlessly... > > For someone proficient in GGI it should be a simple matter to either fix the > problem or declare it without solution (which would be REALLY bad for GGI). > > Having a dvi viewer would be a real plus! > > Anyone up to the task??? > > -- > Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ > Stanford University ,>/'_ ,>/'_ ,>/'_ ,>/'_ ,>/'_ > e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) > www.stanford.edu/~crusius > > HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE > LOSES BOTH AND DESERVES NEITHER > >
Re: GGI extreme blues : NEED HELP
Cesar Crusius <[EMAIL PROTECTED]> 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. > > HELP! > > I believe the error comes from the error message (unable to open shared > library genkgi.o) that is sent to the console and garbles everything. But I > can't be sure. And I don't have time! That is not a problem. > Can any kind soul get the sources for dvgt I hacked and figure out how to > make things work in the console? Every time I try to use it in the console > the *computer hangs for good*, while in X it works flawlessly... Does other GGI applications work on the console? //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
GGI extreme blues : NEED HELP
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. HELP! I believe the error comes from the error message (unable to open shared library genkgi.o) that is sent to the console and garbles everything. But I can't be sure. And I don't have time! Can any kind soul get the sources for dvgt I hacked and figure out how to make things work in the console? Every time I try to use it in the console the *computer hangs for good*, while in X it works flawlessly... For someone proficient in GGI it should be a simple matter to either fix the problem or declare it without solution (which would be REALLY bad for GGI). Having a dvi viewer would be a real plus! Anyone up to the task??? -- Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__ Stanford University ,>/'_ ,>/'_ ,>/'_ ,>/'_ ,>/'_ e-mail:[EMAIL PROTECTED](_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_) www.stanford.edu/~crusius HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE LOSES BOTH AND DESERVES NEITHER
