On Wed, Nov 7, 2012 at 2:54 AM, Peter Stuge <peter@xxxxxxxx> wrote: >> - some devices bug out on libusb_open() > > Please send me a debug log from when this happens. Exact steps are at > http://libusb.org/wiki/debug I'll see what I can dig up. Mostly this has come from upstream, Alessio do you have something at hand for these color calibration crashes you've been seeing? >> I have added code like below to libmtp to instead inspect sysfs >> *before* starting any libusb-based business. > .. >> - Is this a good idea? > > It's a horrible hack and I don't think it's a very good idea. I > understand that you have some real broken devices to deal with, > but let's just make libusb work for you instead. Yeah I would prefer that ... currently I'm just adding to the udev blacklist, looking like this: # Some sensitive devices we surely don't wanna probe # Color instruments ATTR{idVendor}=="0670", GOTO="libmtp_rules_end" ATTR{idVendor}=="0765", GOTO="libmtp_rules_end" ATTR{idVendor}=="085c", GOTO="libmtp_rules_end" ATTR{idVendor}=="0971", GOTO="libmtp_rules_end" # Canon scanners that look like MTP devices (PID 0x22nn) ATTR{idVendor}=="04a9", ATTR{idProduct}=="22*", GOTO="libmtp_rules_end" # Canon digital camera (EOS 3D) that looks like MTP device (PID 0x3113) ATTR{idVendor}=="04a9", ATTR{idProduct}=="3113", GOTO="libmtp_rules_end" # Sensitive Atheros devices that look like MTP devices ATTR{idVendor}=="0cf3", GOTO="libmtp_rules_end" # Sensitive Atmel JTAG programmers ATTR{idVendor}=="03eb", GOTO="libmtp_rules_end" > Also, look into scanf() and friends, they are highly underrated! :) Yes... hm. >> - What is the scary business that libusb_open() does that makes >> a lot of substandard USB devices totally freak out? > > I can only confirm that opening does not talk to the device. > Enumeration can. But really, I need to see the debug log, and > usbmon output from when this happens would certainly also be nice. So we're not just doing this but also retieveing the descriptor, looping over configs, interfaces, and checking the number of endpoints. At this point if the endpoints != 3 we bail out. > Linus Walleij wrote: >> you cannot open a session to an MTP device in say a udev script, >> then close it and open another session later > > Maybe don't do that. Open the session in the udev-driven program, and > do not close it. Find a way to tell libmtp that a session is already > open, and only OpenSession when one isn't. It isn't pretty, but.. Yeah :-/ so the *proper* solution (which we have though about) is to do a pulseaudio-sized task by introducing an MTP hog daemon that will proxy all MTP traffic, then patch *all* programs using MTP to go through that daemon. That would also solve the issue of concurrency we have today. However I don't have cycles enough to take on this and I'm waiting for someone else to come along as it is today. Yours, Linus Walleij -- 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
