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    [W:0.025 / U:0.068 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site