> 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
