Package: mouseemu
Version: 0.15-2
Problem:
--------
On my Powerbook5,8 (Oct. 2005 AlBook 15"), on intial boot, reliably, mouseemu
eats all
CPU and stays like that until stopped. A restart makes it work again (sometimes
needs
a second try to actually start).
Reason:
-------
Here are the files opened by mouseemu on intial boot, before Bluetooth
starts:
roo:~# lsof |grep mouseemu
[...]
mouseemu 3560 root 3r CHR 13,64 2525
/dev/input/event0
mouseemu 3560 root 4r CHR 13,65 2537
/dev/input/event1
mouseemu 3560 root 5r CHR 13,66 2549
/dev/input/event2
mouseemu 3560 root 6u CHR 10,223 8986
/dev/input/uinput
mouseemu 3560 root 7u CHR 10,223 8986
/dev/input/uinput
What these correspond to:
roo:~# for i in `ls -d /sys/class/input/input*`; do echo "$i: `cat $i/name`";
ls -d $i/event*; done
/sys/class/input/input0: HID 05ac:1000
/sys/class/input/input0/event0
/sys/class/input/input1: HID 05ac:1000
/sys/class/input/input1/event1
/sys/class/input/input2: Apple Computer Apple Internal Keyboard / Trackpad
/sys/class/input/input2/event2
In fact, event0 and event1 correspond to the internal Bluetooth dongle,
which is still configured as an HID device at this time.
However, as part of the Bluetooth startup, it is switched to HCI mode,
which produces this in dmesg:
usb 2-2: usbfs: USBDEVFS_CONTROL failed cmd hid2hci rqt 64 rq 0 len 0 ret -110
usb 2-2: USB disconnect, address 2
drivers/usb/input/hid-core.c: can't resubmit intr, 0001:10:15.0-2/input1,
status -19
usb 2-2: new full speed USB device using ohci_hcd and address 3
Judging by the working Bluetooth, the switch to HCI seems to work, but
there are some logs. Most notably, the USB device
disconnects/reconnects. This of course makes the two event files linked
to the HID personality of the Bluetooth dongle disappear. That in return
makes mouseemu eat the CPU, because it sits in a tight select loop, as
shown by this strace output:
select(6, [3 4 5], NULL, NULL, {1, 0}) = 2 (in [3 4], left {1, 0})
read(3, 0x7fe8d940, 16) = -1 ENODEV (No such device)
read(4, 0x7fe8d930, 16) = -1 ENODEV (No such device)
..
etc. ad infinitum
So obviously FD 3 and 4 no longer map to an existing device. Those were
(see lsof output above) event0 and event1.
Solution
--------
mouseemu needs to handle disappearing event devices gracefully.
I'm not sure what would happen if
for instance a Bluetooth mouse is added after starting mouseemu (would
it work?) or disconnected (would mouseemu produce the same problem), or
the same with a keyboard (since I think it's keyboards mouseemu is
interested in, to "catch" emulation button events).
So it seems to me that mouseemu needs to be tolerant to changing
devices, both in working as expected with new ones, and adapting to
removed existing ones.
Thanks, and cheers
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email [EMAIL PROTECTED] |
http://www.cpu.lu/~mlan | Learn Always. "
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
