Hi all,
You may recall I experienced problems with mouseemu on my Oct. 2005
AlBook. On initial boot, mouseemu eats all CPU and refuses to work.
Well, I looked a bit into the problem and found the cause. But let's
start with the problem:
Problem:
--------
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.
Does this seem OK?
If yes, I'll file a bug against mouseemu. Of course, one could also
start mouseemu after bluetooth. But 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.
Comments?
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]
