[Splashy-devel] Initramfs bug understood

[Luis Mondesi]

>> Yep. We tried that before. The problem is that  directfb does this:

> >
> > 1. opens /dev/tty0 (hard coded) (see dfb_vt_initialize() in
> > directfb-0.9.25.1/systems/fbdev/vt.c)
> > 2. then it attempts to find a console available:  n = ioctl(
> dfb_vt->fd0,
> > VT_OPENQRY, &dfb_vt->num );
>
> But wouldn't the option
>         [no-]vt-switch
>
>               By  default  DirectFB  allocates  a  new  virtual  terminal  and
>               switches to it.
>
> Keep it from doing this. If not then it's a bug in directfb IMHO.
>
> > 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).
>
> grts Tim



It turns out that the only patch we need is this:

only in patch2:
unchanged:
--- directfb-0.9.25.1.orig/inputdrivers/keyboard/keyboard.c
+++ directfb-0.9.25.1/inputdrivers/keyboard/keyboard.c
@@ -279,6 +279,8 @@

              keyboard_set_lights( data, evt.locks );
         }
+          if (readlen <= 0)
+                usleep(2000);
    }

    if (readlen <= 0 && errno != EINTR)

We just need to yield the CPU from the keyboard even thread. That
fixes the CPU issue and the booting from initramfs issue.

The only problem is that the ESC key is not handled when booting from
initramfs. I'll ask in the directfb-users list to see if i get an
answer.

-- 
----)(-----
Luis Mondesi
Maestro Debiano

----- START ENCRYPTED BLOCK (Triple-ROT13) ------
Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur fbsgjner
jbeyq.
----- END ENCRYPTED BLOCK (Triple-ROT13) ------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/splashy-devel/attachments/20070929/99c36880/attachment-0001.htm