On 9/29/07, <b class="gmail_sendername">Luis Mondesi</b> <<a href="mailto:lemsx1@gmail.com">lemsx1@gmail.com</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;">
Hello Guillem,<br><br>We finally found a solution to Splashy's oldest standing bug [1] -- thanks to the guys from Rpath [2] of course. It looks like we were having the right way of thinking all alone, but our solution wasn't effective enough because of limitations in libdirectfb-dev (upstream). DirectFB doesn't provide with a way to configure to what terminal (tty) directfb will bind to once it launches. They seem to query the kernel using ioctl() and bind to whatever console is available.
<br><br>In short, when using Splashy from initramfs, directfb binds to tty2 right the way, blocking all other processes from using it. When init starts then, this creates a race condition on libdirectfb causing to loop forever. The solution is fairly simple. We need to tell libdirectfb to use tty8. I have included in this email the patch from rpath as well as a debdiff i did from the latest package in Sid.
<br><br>I was wondering if it was possible for you to include this patch in the Debian package for directfb. This patch should not create any problems that I can think of, for any application using directfb. Assuming, of course, that people will use one directfb application at a time. If we patch directfb this way, we can close that bug and allow Splashy to enter testing. Then enable initramfs by default and be done with it.
<br><br>The ideal solution, of course, would be to ask upstream to include a way so that people can create their framebuffers in whatever tty they choose (or at least to start at a minimum number with a given range to test).
<br><br>Let me know what you think.<br><br>Regards,<br><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) ------
<br><br>[1] <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383060" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383060</a><br>[2] <a href="https://issues.rpath.com/browse/RPL-1593" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://issues.rpath.com/browse/RPL-1593
</a></blockquote><div><br><br>I just wanted to add that in Debian Sid, the following patch is the only thing we need:<br><br><pre class="code">only in patch2:<br>unchanged:<br>--- directfb-0.9.25.1.orig/inputdrivers/keyboard/keyboard.c
<br>+++ directfb-0.9.25.1/inputdrivers/keyboard/keyboard.c<br>@@ -279,6 +279,8 @@<br> <br> keyboard_set_lights( data, evt.locks );<br> }<br>+ if (readlen <= 0)<br>+ usleep(2000);
<br> }<br><br> if (readlen <= 0 && errno != EINTR)</pre></div></div><br>Perhaps usleep() can have a lower number, like 500 or so. But that gave us a fast boot process and no stopping at boot (from initramfs).
<br><br>Please let me know what you think Guillem. I'd like to get these bugs closed in the upcoming release (Splashy 0.3.6).<br><br>Regards,<br><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) ------