On 10/15/07, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> Luis Mondesi wrote:
[snip]
> > --- 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)
> >
> > (Note that this is the same fix for directfb 1.1.x)
>
> I made the change in the driver.

Thanks a bunch! This is very good news.

> Would reopening the device help? What about not using VTs at all,
> but use the Linux Input driver?

I thought about this since the /dev mount is moved from initramfs to
some other tree... perhaps reopening the device from the same mount
path once udev creates the devices might do the trick.

The trouble might be how do you know that the device is not working
(or has been modified). Perhaps the keyboardEventThread now reads
NULLs ?

Using the linux-input driver didn't fix this problem for us (and it
created other problems for some people). We actually compile Splashy
without this driver nowadays.

Thanks again for your help.

-- 
----)(-----
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) ------

_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev

Reply via email to