Garmin USB driver grmnusb not compatible with chrome USB API on Windows

644 views Asked by At

Here's the text of a help ticket I opened with Garmin; I am wondering if anyone here might have ideas for a workaround / can verify that you see the same behavior? (I'll post any updates from them here; for now, they just say that they cannot guarantee what the engineering department will do, if anything)

The zadig / WinUSB workaround is less than ideal for this app, due to the user interaction required; we'd like to find a solution or workaround that will just work out of the box.


On Windows Vista 32 home basic, the chrome USB API will not open a usb connection to a Garmin 60CSx which is using the latest grmnusb driver (v2.3.1).

This can be seen with the 'USB Device Info' chrome app: https://chrome.google.com/webstore/detail/igkmggljimacfdfalpeelenjeicmfnll

However, if you change that device to use the WinUSB driver instead, then reboot, it can be opened by that chrome app, and by other apps that use the chrome USB API.

I used the program 'zadig' to make that driver change, as suggested in this thread: https://code.google.com/p/chromium/issues/detail?id=249908

And, if I then use the device manager to 'Roll Back Driver' so that grmnusb is again the only driver for the 60CSx, then as expected it fails to open in the chrome app again.

So, I think the issue has been isolated to the fact that grmnusb is not compatible with the chrome USB API. I believe this is a bug in grmnusb. Can it be modified to work with the chrome USB API? Thanks


UPDATE 6-23-15: no real news, but, confirmation from other app developers that it is in fact just the way Windows drivers work: the grmnusb driver "owns" that USB device and nothing else can talk to that device via USB. But, it turns out I did completely miss the section of the Garmin interface doc where they say that you have to use the Win32 API calls to talk to the driver. All of that definitely clarifies things: the issue is now one of finding the most seamless way for the browser to talk with the driver; it looks like the most seamless way may be to have a native Windows app running the Win32API calls, and doing the native messaging with a Chrome extension to transfer the data to/from the web page. Any new input would still be appreciated!

0

There are 0 answers