Messages in this thread | | | From | Michael Poole <> | Subject | Re: magicmouse: claimed by neither input, hiddev nor hidraw | Date | Mon, 10 May 2010 22:28:32 -0400 |
| |
Justin P. Mattock writes:
> On 05/10/2010 02:52 PM, Jiri Kosina wrote: [snip] >> This sounds a bit strange. >> >> hidraw shouldn't be making too much difference in the case you describe. >> hidraw is basically just a mean of relaying HID events to userspace so >> that any driver/application in userspace can access them. But magicmouse >> driver is written completely in kernelspace. >> >> Does anything on your system have /dev/hidraw* nodes open? (you could >> check by lsof). >> > > > right now I see > /dev/hidraw0,1,2,3 > > ./lsof | grep /dev > (showing bluetooth) > > bluetooth 2020 root 0u CHR 1,3 0t0 2551 > /dev/null > bluetooth 2020 root 1u CHR 1,3 0t0 2551 > /dev/null > bluetooth 2020 root 2u CHR 1,3 0t0 2551 > /dev/null > bluetooth 2020 root 14u CHR 10,62 0t0 3895 > /dev/rfkill > > I can try a bisect on this and see.
A list of which patches you have applied would also be helpful. The standard 2.6.33.* kernels predate the merge of the hid-magicmouse driver, but the dmesg entry you pasted makes it look like the driver was present.
Michael Poole
| |