> > Well, you should notice a process called mouseemu if you installed the
> > daemon :-)
>
> No, it's not there
Didn't work in 2.6.14 - uinput device open was broken. The following patch
fixes it:
diff --git a/drivers/input/misc/uinput.c b/drivers/input/misc/uinput.c
index 948c1cc..201a572 100644
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -199,10 +199,9 @@ static int uinput_open(struct inode *ino
spin_lock_init(&newdev->requests_lock);
init_waitqueue_head(&newdev->requests_waitq);
- newinput = kmalloc(sizeof(struct input_dev), GFP_KERNEL);
+ newinput = input_allocate_device();
if (!newinput)
goto cleanup;
- memset(newinput, 0, sizeof(struct input_dev));
newdev->dev = newinput;
(plus a matching patch to uinput_close, otherwise your kernel crashes hard
on device close - yikes. I'll post the full diff as soon as my powerbook
has recovered...).
> > Matthias mentioned a problem with udev and event device creation taking
> > too much time so pbbuttonsd gives up on them (if I understood his mail
> > right). Can you make the necessary devices up front with udev?
>
> restarting pbbuttonsd doesn't help tho
Had the same problem on a fresh 2.6.14 now - and it turns out the evdev
module doesn't get loaded automagially. Load the module and all is fine
(wish it was ever as easy as that).
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
