On 9/30/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 Sat, 29 Sep 2007 22:08:14 -0400<br>"Luis Mondesi" <<a href="mailto:lemsx1@gmail.com">lemsx1@gmail.com</a>> wrote:<br><br>><br>> We just need to yield the CPU from the keyboard even thread. That<br>
> fixes the CPU issue and the booting from initramfs issue.<br>><br>> The only problem is that the ESC key is not handled when booting from<br>> initramfs. I'll ask in the directfb-users list to see if i get an
<br>> answer.<br><br>So, to summarize:<br><br>If we start from initramfs<br> => it takes tty2<br> => directfb looses keyboard</blockquote><div><br>The keyboard gets "lost" when init starts (when the progressbar starts to grow in Splashy). If you hit ESC as soon as Splashy starts, the keyboard listening code is still working. We need to figure out why this is happening. My guess is that since Splashy was launched on a different environment (root tree), when the switch to a new root (real root tree) happens, the other files are marked as "deleted" (this is what lsof shows during boot). So directfb is trying to read from a console that is marked as deleted. Perhaps the real solution is to never close the listening device once directfb opens it; that way the kernel marks it as "deleted" but there is a process still "listening" from it. Again, this is just me taking wild guesses that match the behavior that I see.
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> => keyboard thread goes haywire</blockquote><div><br>yep. thread goes into a tight while loop that never ends.
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Solutions<br>1) Make keyboard thread shed some cycles.<br> => Drawback: we don't have keyoard
</blockquote><div><br>Well, this solution makes the CPU issue alleviate. We loose the keyboard regardless of what method we choose (use a different tty or patch directfb to shed some CPU cycles).<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) Make directfb use another tty.<br> -> Drawback: ?</blockquote><div><br>CPU still goes to 99% when you do this alone. And in fact, this is not needed since we skip execution of console-screen.sh until Splashy is finished. So, the boot process is never stopped (like it used to before that you had to go to TTY2 and hit ENTER to move on).
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Is this summary correct?<br><br>Why don't we do solution 2?</blockquote><div><br>
Yep. That's correct. But like I said before, solution 2 is not a solution for Debian (Sid). That solution works for RPath Linux and perhaps other distros. In Debian, all we need is to yield the CPU at the keyboard thread level.
<br></div></div><br>Regards,<br clear="all"><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) ------