Hi. I am attempting to write a directfb-based app that will be executed during the system boot process. Everything works perfectly well as long as the system stays in the same runlevel. Once the runlevel is changed, my application loses keyboard focus and seems to slow down dramatically. When the boot process is finished, the app exits, as it is supposed to, but I am left with a black screen and no way to switch to other virtual consoles.
I've been looking through the init.c code (from sysvinit-2.85) and was
able to track down the problem to the following snippet:
setsid();
if ((f = console_open(O_RDWR|O_NOCTTY)) >= 0) {
/* Take over controlling tty by force */
(void)ioctl(f, TIOCSCTTY, 1);
/* ... */
The whole situation can be simulated with the following simple program:
http://dev.gentoo.org/~spock/temp/dfb/tty-thief.c
with exactly the same effects.
I've tried starting the app with -vt-switch (got the results described
above) and with -no-vt-switch (the display freezes for a few seconds,
but the screen is not cleared, then the app exits with "Caught signal
1 (sent by the kernel)"). All tests were performed with DFB-0.9.20 and
the latest version from CVS.
Is there any way to solve this problem? I can't stop init from taking
over the tty, but maybe it would be possible to take the tty back?
If so, can it be done with DFB, in a clean way?
Live long and prosper.
--
Michal 'Spock' Januszewski Gentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [EMAIL PROTECTED] freenode: #gentoo-dev, #gentoo-pl
pgpelSxCYtIwI.pgp
Description: PGP signature
