cameleon-rs/cameleon

Order-Dependent Driver Installation? Must install driver on non-working camera before other camera works

Closed this issue · 3 comments

Encountered a truly bizarre situation with a pair of Point Grey Grasshopper3 cameras.

Starting with a GS3-U3-120S6M, I followed the instructions for getting started on Windows. I'm on Windows 10, Rust v1.53.0. Running the stream example on the current main branch (as cargo run --example stream --features libusb) failed with "no camera found!". SpinView (Flir's viewer software) can see it, but now it refuses the capture from the camera because I'm not using their proprietary driver anymore. Fair enough, at least I can verify that the WinUSB driver is functional at some level.
2021-07-02 12_41_51-SpinView 2 4 0 144

Luckily, I also had a GS3-U3-28S4M around. Plugging that in, the WinUSB driver automatically recognized and associated itself with the new camera. I guess they're similar enough models? The camera showed up as "Grasshopper3 GS3-U3-28S4M" in Device Manager and Zadig, but still as "Grasshopper3 GS3-U3-120S6M" in SpinView (even after relaunching). Weird. But the stream example works, though! (After a detour to apriori@30683dc to solve parsing panic.)

Now that it was working, I wanted to make sure that I could make the setup process repeatable. In production, the software will be running an different computers, and users may also want to use SpinView. Can I turn off the generic driver, use the proprietary one, and then switch it back? The generic driver seems to have recategorized the camera, because Windows no longer considers the Flir driver as a valid option. Uninstalling the generic driver and un/re-plugging the camera caused it to be picked back up by the Flir driver, though, and then SpinView works again. So far, so good. Reinstalling the generic driver didn't work, however. Now the camera shows up only as "USB3 Vision Device" in Device Manager, Zadig, and SpinView. The stream example fails:

cargo run --example stream --features libusb
    Finished dev [unoptimized + debuginfo] target(s) in 0.26s
     Running `target\debug\examples\stream.exe`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: StreamError(Io(libusb error: operation not supported or unimplemented on this platform

Caused by:
    operation not supported or unimplemented on this platform))', cameleon\examples/stream.rs:21:19
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\debug\examples\stream.exe` (exit code: 101)

Trying the 120S6M, just for good measure, at least still fails with the same "no camera found!" it did before.

At this point, I am thoroughly baffled. It was just working a second ago! What happened? I searched around for info on the libusb error and couldn't find anything relevant, except that it seemed likely to be an app-level error/concern rather than a driver-level one. I uninstalled Flir and Point Grey software, reinstalling the generic driver at every combination with no success. I even reset my PC to a restore point before all the driver shenanigans. Still no success.

Finally, I remembered that I had first installed the generic driver on the 120S6M, which didn't work, before plugging in the 28S4M, which did work and didn't require reinstalling the driver. There's no way that could be what's happening, I thought. Turns out, that's exactly what was happening. I repeated those steps exactly, and now the 28S4M works and the 120S6M still doesn't (but neither cause cameleon to panic), just like my previous imperfect-but-best-so-far setup.

IT GETS WEIRDER. I happened to have another 28S4M, and I decided to test it. If it's a model number thing, another camera of the same module should also work, I figure. It doesn't even turn on when I plug it in. Hmm, ok, maybe it's dead. I plug it into a different computer, it does turn on, and it can capture images (with SpinView, but still). I plug it into a different USB port, it turns on and the stream example works. Ok, that's strange, but I'm glad it works!

But then, today, IT GETS EVEN MORE WEIRDER. I was retracing my steps while writing this issue, making sure that everything still happens the way I remember it. Everything checked out until suddenly none of my cameras were working, regardless of which one I installed the driver on first! All of them appeared as "USB Vision Device" and all of them panicked. Ok, I'm rather worried now. I thought, strange as things were, that I had a reliable work-around for the present. Now I'm dead in the water. UNTIL I PLUGGED THE 120S6M INTO THE ORIGINAL USB PORT (the one that the second 28S4M refused to turn on with). Now I can recreate the work-around just fine.

The deeper I get into this, the more I suspect it goes deeper than cameleon or libusb; maybe something's goofed up my USB ports and I need to reset at the controller or root hub level? Unfortunately, I'm a little out of my depth here.

Meta

  • Which manufacturer's camera did you use?
    Point Grey (now Flir (now Teledyne))
  • What is the model name of the camera?
    Grasshopper 3
    • GS3-U3-120S6M
    • GS3-U3-28S4M
  • Which Cameleon version are you using?
    0.1.4 (apriori@30683dc)

Ok, this might be relevant. I did some more poking around in Device Manager, enabling "View>show hidden devices" and switching to "View>Devices by connection". It becomes apparent that the 28S4Ms are composite devices. The 120S6M doesn't, and maybe that's why "no camera found!"?
Screenshot_070221_055629_PM

Ok, I uninstalled everything WinUSB related and started over. I noticed that the 120S6M showed up as "Grasshopper3 GS3-U3-120S6M" (even with no driver installed), but it was inside a composite device. Installing the driver to that generically named USB Composite Device (carefully checking the hardware id to make sure I get the right one) worked.

I am now able to install the driver to each camera independently of the others. The dependency effect is gone.

I must confess to being an idiot. I must have missed/misread the "NOTE: Make sure to install a driver to a composite device not to its child devices". I probably clicked off into the Zadig instructions and followed those, breezing past that note when I came back.

Soooo, careless enough to miss the warning but clever and stubborn enough to eventually recreate the solution independently? Is that enough for partial credit? 😅
Thanks for standing in for my rubber duck. I hope to stick around and make some actually useful contributions to this project!

Y-Nak commented

💯 for your cleverness and perseverance!