magicmouse: claimed by neither input, hiddev nor hidraw
in [Kernel]
|
From: Justin P. Mattock on 10 May 2010 18:20 On 05/10/2010 02:52 PM, Jiri Kosina wrote: > On Mon, 10 May 2010, Justin Mattock wrote: > >>>> with the magicmouse connecting i.g. I've had my system setup to use >>>> the magicmouse with 2.6.33* with no issues now coming back after >>>> sometime seems everything is connecting,but then no movement: (and >>>> some thing in dmesg): >>>> [ 116.267993] magicmouse 0005:05AC:030D.0007: claimed by neither >>>> input, hiddev nor hidraw >>>> [ 116.268053] magicmouse 0005:05AC:030D.0007: magicmouse hw start failed >>>> using osx magicmouse connects fine. >>>> Using standard mightymouse everything connects. >>>> are there any reports of such things? >>> >>> Adding Michael Poole to CC. >>> >>> No, I haven't seen any such reports. First -- could you please provide >>> complete dmesg? >> >> everything seems to be working o.k. now, just had to enable HIDRAW=y >> maybe something changed to where I needed this(I remember never really >> using hidraw, just HIDDEV(but could be wrong)). > > 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. Justin P. Mattock -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michael Poole on 10 May 2010 22:30 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Justin P. Mattock on 10 May 2010 22:50 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 > > I'm using the latest HEAD, without any patches applied. (I'll send a post with dmesg after this post). Justin P. Mattock -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Justin P. Mattock on 10 May 2010 23:00 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Kosina on 11 May 2010 03:50 On Mon, 10 May 2010, Justin P. Mattock wrote: > 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/ Please include the dmesg directly in the mail next time. Anyway, I don't see the dmesg you provided containing neither the "claimed by neither input, hiddev nor hidraw" nor "hw start failed" messages. -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: [GIT PULL] RCU changes for 2.6.35 Next: [PATCH] perf: allow forcing use of cplus_demangle |