Return-Path: Message-ID: <4BE8C7CD.7030206@gmail.com> Date: Mon, 10 May 2010 19:58:21 -0700 From: "Justin P. Mattock" MIME-Version: 1.0 To: Michael Poole CC: Jiri Kosina , linux-bluetooth@vger.kernel.org, Linux Kernel Mailing List Subject: Re: magicmouse: claimed by neither input, hiddev nor hidraw References: <4BE8859E.3090305@gmail.com> <87mxw7i33j.fsf@troilus.org> In-Reply-To: <87mxw7i33j.fsf@troilus.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Sender: linux-bluetooth-owner@vger.kernel.org List-ID: 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