Re: keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko
On Fri, 10 Apr 2015, Christian Böhme wrote:
Alan Stern stern@... writes:
Given that hid_mouse_ignore_list[] actually contains the proper
(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ISO) pair
as far as I can make out and assuming a properly working compiler,
hid_match_one_id() returns FALSE only if the hdev's members in question
are not properly set up. And I wouldn't know where to look for /that/.
You ought to be able to figure out what's going on by adding a few
debugging statements in suitable places.
^^^
What are those ominous places?
The places where the code sets and tests the HID_TYPE_USBMOUSE flag,
and where it tests for a matching ID. Basically, the places that
affect the thing you want to accomplish.
On a side note, I'm a little surprised that the arguments to …
are not const-qualified, although none of their members are actually
mutated there …
That sort of thing happens all the time. People don't remember to add
const qualifications because it's not obvious when they _could_ be
added,
How can it not be obvious to the author(s) of their own code?
You seem to forget that the kernel was written by thousands of
different people. Even if somebody is familiar with his own code, he
isn't necessarily familiar with code written by someone else.
Does
the semantics of the language randomly change when nobody's watching?
That would make computer science a lot more intriguing! :-)
the compiler doesn't complain about it,
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-51)
$ gcc -Wall member.c -o member
member.c: In function ‘g’:
member.c:12: error: assignment of read-only location
$ cat member.c
struct A {
int x, y;
};
void f( struct A * a )
{
a-x = 1;
}
void g( const struct A * a )
{
a-y = 2;
}
int main( int argc, char * argv[] )
{
struct A a;
f(a);
g(a);
return 0;
}
This one does. And I'm positive all newer versions do, too.
Your example doesn't contradict what I said. Go back and reread my
comment, and then consider this example instead:
$ gcc -Wall const-test.c -o const-test
$ cat const-test.c
const char *y;
void a(char *x)
{
y = x;
}
int main(int argc, char **argv)
{
a(hello);
return 0;
}
The function a() makes no assignments through x. Therefore it could
and should have been defined as void a(const char *x) -- but the
compiler did not complain.
and it doesn't make much
difference anyway.
I disagree. It's precisely what aids in avoiding situations like the
current one where nobody seems to know what's going on anymore. That's
what const-qualifications where invented for (if there is such a thing).
Somewhere a member's value is changed where it shouldn't. How can that
not make a difference?
You might be able to find a few cases where the kernel code changes a
value that should have been declared const, but not many. Like I said
before, the real problem is that there's no penalty if you forget to
mark something as const when the code _doesn't_ change it.
If you want, you could submit a series of patches that do nothing but
add const declarations in the places where they are missing.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko
Jiri Slaby jirislaby@... writes: 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). # readlink /sys/bus/usb/devices/5-2:1.1/driver ../../../../../../bus/usb/drivers/usbhid # cat /sys/bus/usb/devices/5-2:1.1/bInterfaceProtocol 00 # readlink /sys/bus/usb/devices/5-2:1.2/driver ../../../../../../bus/usb/drivers/bcm5974 # cat /sys/bus/usb/devices/5-2:1.2/bInterfaceProtocol 02 Do you have MOUSE_BCM5974 enabled? $ grep MOUSE_BCM5974 /boot/config-3.16.0-4-amd64 CONFIG_MOUSE_BCM5974=m $ lsmod | grep bcm5974 bcm597416994 0 usbcore 195340 8 btusb,uhci_hcd,uvcvideo,usb_storage,ehci_hcd,ehci_pci,usbhid,bcm5974 So, what's going on? Cheers, Christian
Re: keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko
Alan Stern stern@... writes: 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. Well, if that is indeed the case, this leaves the only other reason for failure of the original test in hid_match_id() returning NULL. Given that hid_mouse_ignore_list[] actually contains the proper (USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ISO) pair as far as I can make out and assuming a properly working compiler, hid_match_one_id() returns FALSE only if the hdev's members in question are not properly set up. And I wouldn't know where to look for /that/. On a side note, I'm a little surprised that the arguments to hid_ignore(), hid_match_id(), and hid_match_one_id() are not const-qualified, although none of their members are actually mutated there … Cheers, Christian
Re: keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko
On Sun, 22 Mar 2015, Christian Böhme wrote: Alan Stern stern@... writes: 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. Well, if that is indeed the case, this leaves the only other reason for failure of the original test in hid_match_id() returning NULL. Given that hid_mouse_ignore_list[] actually contains the proper (USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING2_ISO) pair as far as I can make out and assuming a properly working compiler, hid_match_one_id() returns FALSE only if the hdev's members in question are not properly set up. And I wouldn't know where to look for /that/. You ought to be able to figure out what's going on by adding a few debugging statements in suitable places. On a side note, I'm a little surprised that the arguments to hid_ignore(), hid_match_id(), and hid_match_one_id() are not const-qualified, although none of their members are actually mutated there … That sort of thing happens all the time. People don't remember to add const qualifications because it's not obvious when they _could_ be added, the compiler doesn't complain about it, and it doesn't make much difference anyway. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko
Alan Stern stern@... writes: 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). OK. Let me know if there's anything else I can do to help fix this. Cheers, Christian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko
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_appleir12724 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). Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko
On Fri, 27 Feb 2015, Christian Böhme wrote: Hello all, this is a response to https://bugzilla.kernel.org/show_bug.cgi?id=14987#c6 whose main thread more or less merely rehashes what was already said in other (bug) reports before it elsewhere. I'd like for this to be a reminder that the issue never really was resolved but left lingering beginning with kernel version 2.6.28 (yes, that long ago). 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. Is there any chance for this problem to be fixed or am I really expected to downgrade that far just to have a working keyboard and trackpad? It should have been working all along if your kernel configuration was correct. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko
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_appleir12724 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) 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. 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. If I had to venture a guess here I'd say that that is never the case. Cheers, Christian
keyboard/trackpad combo unusable on MacBookPro4,1 with bcm5974.ko
Hello all, this is a response to https://bugzilla.kernel.org/show_bug.cgi?id=14987#c6 whose main thread more or less merely rehashes what was already said in other (bug) reports before it elsewhere. I'd like for this to be a reminder that the issue never really was resolved but left lingering beginning with kernel version 2.6.28 (yes, that long ago). 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? Is there any chance for this problem to be fixed or am I really expected to downgrade that far just to have a working keyboard and trackpad? Cheers, Christian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
