On 9/29/07, <b class="gmail_sendername">Tim Dijkstra</b> <<a href="mailto:newsuser@famdijkstra.org">newsuser@famdijkstra.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 28 Sep 2007 16:49:00 -0400<br>"Luis Mondesi" <<a href="mailto:lemsx1@gmail.com">lemsx1@gmail.com</a>> wrote:<br><br>> Elliot (from Rpath) made the patch they are using available to us. This is a
<br>> very simply 2 liner. I hope that this can help somebody out there get around<br>> this problem.<br>><br>> The other solution would be to switch to upstart ;-)<br><br>IIRC, does have an option to not allocate a new VT. Can't we first
<br>switch VT to 17 and then start libdirectfb?<br><br>Could you maybe try that Luis?</blockquote><div><br>Yep. We tried that before. The problem is that directfb does this:<br><br>1. opens /dev/tty0 (hard coded) (see dfb_vt_initialize() in
directfb-0.9.25.1/systems/fbdev/vt.c)<br>2. then it attempts to find a console available: n = ioctl( dfb_vt->fd0, VT_OPENQRY, &dfb_vt->num );<br>3. since we are launched from initramfs very early, tty2 is available and directfb attaches to that (I'd say even if you launch the process in a tty other than tty1, which seems to be the case now).
<br>4. when init moves on to the real filesystem, something happens to the console that triggers that race condition that's now documented on the Rpath linux page (<a href="https://issues.rpath.com/browse/RPL-1593">https://issues.rpath.com/browse/RPL-1593
</a>)<br></div><br></div><br>-- <br>----)(----- <br>Luis Mondesi<br>Maestro Debiano<br><br>----- START ENCRYPTED BLOCK (Triple-ROT13) ------<br>Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner jbeyq.
<br>----- END ENCRYPTED BLOCK (Triple-ROT13) ------