From: Lionel D. <lio...@ya...> - 2011-06-03 10:29:13
|
Hello, I'd like to raise again a matter brought forward on this ML in November 2007: http://sourceforge.net/mailarchive/message.php?msg_id=6268021 . What happens is that the USB controller / stack of the Nspire, the latest graphing calculator by Texas Instruments, doesn't like the reset commands sent through libusb, under Windows, by the libticables library used by the third-party linking software I'm maintaining nowadays, TILP. * TI's official linking software under Windows (and probably MacOS X as well, I haven't _checked_), and libusb under Linux, send only IOCTL_INTERNAL_USB_RESET_PORT. The Nspire is happy with that; * libusb under Windows unconditionally sends IOCTL_INTERNAL_USB_RESET_PORT + IOCTL_INTERNAL_USB_CYCLE_PORT, which makes the Nspire lose connection with the host. (and resetting the communication frequently is necessary for reliable communication, at least under Linux) Unless we patch libusb (libusb0.sys) the following way, as described by Romain (and we did so for a while): --- src/driver/reset_device.c.orig 2007-03-20 05:33:29.000000000 -0500 +++ src/driver/reset_device.c 2009-05-07 10:41:28.331560796 -0500 @@ -32,14 +32,14 @@ { DEBUG_ERROR("reset_device(): IOCTL_INTERNAL_USB_RESET_PORT failed: " "status: 0x%x", status); - } - status = call_usbd(dev, NULL, IOCTL_INTERNAL_USB_CYCLE_PORT, timeout); + status = call_usbd(dev, NULL, IOCTL_INTERNAL_USB_CYCLE_PORT, timeout); - if(!NT_SUCCESS(status)) - { - DEBUG_ERROR("reset_device(): IOCTL_INTERNAL_USB_CYCLE_PORT failed: " - "status: 0x%x", status); + if(!NT_SUCCESS(status)) + { + DEBUG_ERROR("reset_device(): IOCTL_INTERNAL_USB_CYCLE_PORT failed: " + "status: 0x%x", status); + } } return status; TILP's Nspire support under Windows is, well, unusable. With a pristine libusb, the normal flow for simple operations such as listing the calculator's contents, or receiving a dump of the screen, is to trigger them, watch them fail, close the error messages, and repeat until the operation eventually succeeds (with a sprinkling of unplugging and replugging the device)... None of that happens under Linux. I don't know whether devices which support USB_RESET_PORT but not a subsequent USB_CYCLE_PORT are to be considered buggy, I'm not very qualified at USB matters. But the question is, how do we handle such devices (preferably without having to patch libusb0.sys...), since these devices do exist in the wild ? Besides Nspire calculators, the patch reproduced above was reported to fix interaction with at least another device (by preventing BSODs): http://lists.fedoraproject.org/pipermail/mingw/2009-May/001338.html . (in the URLs contained in that message, one needs to remplace "viewcvs" by "viewvc", e.g. http://svn.tilp.info/cgi-bin/viewvc.cgi/*checkout*/libticables/trunk/src/win32/usb/libusb-win32.html?pathrev=4162 ) I'm in the process of upgrading the libusb-win32 version shipped with TILP, so that interested people can, through the filter driver, use TI's official software and TILP II side by side, without having to uninstall and reinstall the other program, and change the driver if that hasn't worked, each time they switch. If required, I can perform some testing and gather some information on virtualized (VirtualBox) Windows versions, less often on a native Seven x64 computer to which I have intermittent physical access. Thanks in advance, Lionel. |