Cannot access USB camera with gphoto2

[punkoffice]

I installed gphoto2 with apt-get but it does not pick up any cameras. I thought they might not be mounted. So I installed gphotofs.
When I run "sudo gphotofs mycameras" I get:

fuse: device not found, try 'modprobe fuse' first

when I run "sudo modprobe fuse" I get:
modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file '/lib/modules/3.4.0+/modules.dep.bin'

I checked my files and turns out the "modules" directory does not exist in the "lib" directory. Does anyone know how to get cameras connected via USB?

[aseering]

Thanks for reporting this!

I'm not a WSL dev, just a user. But my understanding is that WSL is not trying to provide hardware support yet. So it would not be able to load the driver to mount your webcam.

Also, it doesn't support FUSE yet, so gphotofs can't run to look for cameras.

I don't know what the priority is for adding either of those features; an actual WSL dev would have to comment on that. Probably not the response you were hoping for, I know...

[benhillis]

Thanks @aseering, you're correct our current focus is providing a useful command-line toolset for developers. FUSE is definitely on our backlog, but will be a significant amount of work. Hardware access is another area we will be investigating in the future.

I'd suggest starting a thread on our User Voice forum to help us prioritize our future work. Thanks for trying out WSL!

[punkoffice]

That's cool. It would've been a dream if it would be possible. I currently use VMware so I can use gphoto2 to control my cameras (and I have 82 cameras synched). Would've been great to be able to do this without VMware

[tycho]

Somewhat in the same vein as this: it would be nice to be able to support USB-based smartcard or OpenPGP devices (e.g. YubiKey). Or in lieu of that, some way to forward requests for the Linux version of gpg-agent to the host Windows version of gpg-agent.

[str4d]

There's a User Voice forum thread for libusb support here: https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/31920928-add-libusb-support-to-wsl

[iamajoe]

Anywone knows what is the status on this and if it will be solved in a near future?

[colinbowern]

I'm told that we also need to upvote a UserVoice issue for Yubikey support in particular since all of those issues are being closed and directed here. So take a moment to vote it up over here as well:

WSL > Support gpg2 smartcard integration (yubikey)

[sarim]

I upvoted the libusb uservoice linked above. But i'm curious about libusb. AFAIK libusb in windows works by having two layers. A backend [winusb, libusbk etc..] and a frontend. Is it not possible to find a way to connect windows backend to WSL libusb frontend? That way this feature could be implemented without significant work in NT kernel or in WSL core.

[therealkenc]

Is it not possible to find a way to connect windows backend to WSL libusb frontend?

Yep you could. Write a /lib/x86_64-linux-gnu/libusb-1.0.so.0 proxy replacement and write a service on the win32 side.

That way this feature could be implemented without significant work in NT kernel or in WSL core.

No "work" in the NT kernel or WSL core at all. Whether the amount of work to write a libusb api proxy is significant (or not) is kind of in the eye of the person writing it. I guess it depends on how fast you figure you can get your implementation up on github. Here is one guy who took a run at it.

[sarim]

Writing an api proxy for libusb doesn't seem like a significant work. But another concern was in my mind while writing previous comment, Is there any fast IPC mechanism available now between a WSL process and Windows process? Communicating over TCP doesn't seems like fast enough for something like libusb. I think this was an issue regarding another feature in WSL, GUI. A project was using ntfs filess to communicate and pull the fake framebuffer from WSL, which as expected, was slow.

[therealkenc]

Writing an api proxy for libusb doesn't seem like a significant work

I guess it depends on how fast you figure you can get your implementation up on github.

Communicating over TCP doesn't seems like fast enough for something like libusb

USB over IP hubs are a thing. GigE trumps USB2. Localhost is no contest. You'd be able to load a YubiKey fine.

A project was using ntfs filess to communicate and pull the fake framebuffer from WSL, which as expected, was slow.

Can't vouch for people's implementation choices. xrdp marshals framebuffers plenty fast. [Even my $40 Chromecast marshalls framebuffers over IP plenty fast too.]

[chiefjester]

Now that UserVoice was removed, what's the best way to upvote an issue? My main use case is for a Yubikey but looks like @therealkenc closed #2568 in favor of this issue.

[therealkenc]

#2195 is probably a better LZ. A bunch of libusb asks got duped down here (starting with #825), which set a precedent that became hard to undo. The OP ask here was really about FUSE, which is available in WSL2. For libusb (Yubikey yadda yadda), you want to upvote #2195.

[ReeZey]

just fix 😡

[therealkenc]

The OP here was a gphotofs error, for lack of fuse, which is available in WSL2. In turn gphotofs relies on libgphoto2, which requires libusb, which not supported as of this writing. Forward /dupe #2195.