lkml.org 
[lkml]   [2010]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: magicmouse: claimed by neither input, hiddev nor hidraw
On 05/10/2010 07:28 PM, Michael Poole wrote:
> 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
>
>
The only other thing that I remember
when adding hidraw was adding
BT_HCIUART_LL=m
(not sure if it matters or not).

here is dmesg:
http://fpaste.org/OiDf/

Justin P. Mattock



\
 
 \ /
  Last update: 2010-05-12 10:35    [from the cache]
©2003-2011 Jasper Spaans