[TiLP-devel] usb_reset on Windows makes some devices unhappy, no problem on Linux

[Lionel D. <lio...@ya...>]

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.