On 03/17/2015, 03:20 PM, Alan Stern wrote: > On Mon, 2 Mar 2015, Alan Stern wrote: > >> On Fri, 27 Feb 2015, Christian Böhme wrote: >> >>> Alan Stern <stern@...> writes: >>> >>>>> Specifically, HID_QUIRK_IGNORE_MOUSE existed in 2.6.27 >>>>> and was dealt with in drivers/hid/usbhid/hid-core.c:730, >>>>> thereby somehow "fixing things". But those lines (and >>>>> the symbol) disappeared after 2.6.27. Why were they >>>>> removed? >>>> >>>> They weren't removed. The symbol was changed to APPLE_IGNORE_MOUSE and >>>> the implementation was moved to drivers/hid/hid-apple.c. To get the >>>> benefit, you have to enable CONFIG_HID_APPLE. >>> … >>>> It should have been working all along if your kernel configuration was >>>> correct. >>> >>> $ uname -r >>> 3.16.0-4-amd64 >>> $ grep CONFIG_HID_APPLE /boot/config-3.16.0-4-amd64 >>> CONFIG_HID_APPLE=m >>> CONFIG_HID_APPLEIR=m >>> $ lsmod | grep hid_apple >>> hid_appleir 12724 0 >>> hid_apple 12596 0 >>> hid 102264 4 hid_generic,usbhid,hid_appleir,hid_apple >>> $ lsusb -d 05ac:0231 >>> Bus 005 Device 020: ID 05ac:0231 Apple, Inc. Internal Keyboard/Trackpad \ >>> (MacBook Pro 4,1) (ISO) >> >> Which matches the APPLE_WELLSPRING2_ISO entry in the device list. >> >>> Now, APPLE_IGNORE_MOUSE only appears in drivers/hid/hid-apple.c:28, where >>> it is #define'd but never referenced, making it hard for me to see the >>> connection. >> >> True enough. The hid-apple.c driver was separated out in commit >> 8c19a51591d0 (HID: move apple quirks), at which time the >> APPLE_IGNORE_MOUSE quirk was indeed used in the source code. >> >> However, the quirk was removed in commit b4d8e4736c94 (HID: fix >> hidbus/appletouch device binding regression). For some reason that >> commit failed to remove the APPLE_IGNORE_MOUSE #define, though. >> >>> However, while looking for uses of USB_DEVICE_ID_APPLE_WELLSPRING2_ISO, >>> I found hid_mouse_ignore_list defined in drivers/hid/hid-core.c:2358 and >>> referenced after the switch statement in drivers/hid/hid-core.c:2482 as an >>> argument to hid_match_id(), which is executed only if the device's type in >>> question is of HID_TYPE_USBMOUSE. >> >> Yes, that is the replacement code added by commit b4d8e4736c94. >> >>> If I had to venture a guess here I'd say >>> that that is never the case. >> >> I agree. The problem is that the HID core now tests for hdev->type == >> HID_TYPE_USBMOUSE, but it doesn't test for bInterfaceProtocol == >> USB_INTERFACE_PROTOCOL_MOUSE like the older code did. >> >> This issue should be reported to the author of that second commit >> (CC'ed). > > Has this been fixed yet? > > I came back to this old email today, and it turns out that > usbhid_probe() already includes the following lines: > > if (intf->cur_altsetting->desc.bInterfaceProtocol == > USB_INTERFACE_PROTOCOL_MOUSE) > hid->type = HID_TYPE_USBMOUSE; > > This happens before hid_add_device() is called, so it should already be > in effect when hid_ignore() runs. > > Maybe you can figure out what's wrong given these hints. Oh, I somehow missed the 1st e-mail. It would be helpful to see who is actually bound to the two interfaces of the device. What's the output of readlink /sys/bus/usb/devices/<device>:1.*/driver for the corresponding <device>? The mouse should be handled by bcm5974, the other by usbhid (and by hid-apple one layer below). Do you have MOUSE_BCM5974 enabled? regards, -- js -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
