Ubuntu 12.04, Kernel 3.19 - UVCIOC_CTRL_QUERY:UVC_SET_CUR error 5

[mremir]

I have a R200 Realsense camera attached to a Linux box running Ubuntu 12.04, however I have upgrade the kernel to 3.19.
I have built librealsense using the Video4Linux backend and the camera sometimes works however often it fails with the following error (or similar errors):
Realsense Error: UVCIOC_CTRL_QUERY:UVC_SET_CUR error 5, Input/output error

According to this thread teknotus/depthview#1 the issue arises because the ioclt commands do not match video4linux commands, however the solutions provided there do not work.

Can anybody help?
(It is not a possibility to upgrade the system from 12.04 and Linux 3.19 is as far as I can go on a 12.04)

[ddiakopoulos]

There are patches to the UVC driver that have been upstreamed in later versions of the kernel which is why we recommend upgrading. I suspect the absence of this patch is burning you: https://patchwork.linuxtv.org/patch/25668/

I recommend modifying our 3.19 uvcvideo script to apply this additional patch as well. Based on some anecdotal evidence, I think diff can still correctly apply it with the included pixel formats patch. Give it a go and let us know.

[ghost]

I have a similar issue with Ubuntu 14.04.4, running Linux 3.19.0-51-generic. I also tried an older kernel that was mentioned in issue #1 as tested by @ddiakopoulos, 3.19.0-33-generic. I applied the patch above as well as the patch in the librealsense scripts directory.

$ uname -r
3.19.0-33-generic
$ git show | grep commit
commit a6df77892550b8250341f5465c34094ae7071067
$ ./cpp-enumerate-devices 
RealSense error calling rs_create_context(api_version:4):
    UVCIOC_CTRL_QUERY:UVC_SET_CUR error 2, No such file or directory

I'm kinda stuck on this version of the kernel for my target application, unfortunately. Is there any chance that you, @mremir, have figured out what is going wrong?

[mremir]

@emulvaney-aevena Sorry but we have not been able to solve the problem.
It seems like there is huge problems with using the Realsense on 14.04 (or 12.04) with standard (3.19) kernels.
If we stop the software from using the camera we cannot connect to the camera again without re-plugging the camera.

[ghost]

Hmm, so you can use the camera at least once. I can't access it at all with the example programs. I get that error the first time I try any example.

[ddiakopoulos]

@emulvaney-aevena could you do the following:
sudo modprobe -r uvcvideo
dmesg | tail -n 30 => copy output into this issue
sudo modprobe uvcvideo
dmesg | tail -n 30 => copy output into this issue again

I would like to verify that the uvc driver has been correctly patched and loaded by the system.

[ghost]

$ sudo dmesg --clear
$ sudo rmmod uvcvideo
$ dmesg; sudo dmesg --clear
[70392.669428] usbcore: deregistering interface driver uvcvideo
$ sudo modprobe uvcvideo
$ dmesg
[70427.359334] uvcvideo: Found UVC 1.10 device Intel RealSense 3D Camera R200 (8086:0a80)
[70427.373128] uvcvideo: Found UVC 1.10 device Intel RealSense 3D Camera R200 (8086:0a80)
[70427.376494] uvcvideo: Unable to create debugfs 2-2 directory.
[70427.379490] uvcvideo: Found UVC 1.10 device Intel RealSense 3D Camera R200 (8086:0a80)
[70427.383554] uvcvideo: Unable to create debugfs 2-2 directory.
[70427.383674] input: Intel RealSense 3D Camera R200 as /devices/pci0000:00/0000:00:0c.0/usb2/2-1/2-1:1.4/input/input10
[70427.385783] usbcore: registered new interface driver uvcvideo
[70427.385787] USB Video Class driver (1.1.1)
$ 

[ghost]

@ddiakopoulos, is that enough to demonstrate that the kernel is patched correctly? I actually didn't try it without the patch, so I'm not sure what the output would have been.

Ubuntu doesn't provide the source for older patched kernels in the regular fashion. You can "apt-get source" for an older edition, but you'll always get the source for the latest patch. This is probably the safe way to go, but I wanted to reproduce your 3.19.0-33 experience. So I cloned their GitHub repository, git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git, where they have 3.19.0-33 tagged as Ubuntu-lts-3.19.0-33.38_14.04.1. I patched that and then followed their instructions to build new .debs and installed them, and selected the rebuilt kernel at startup.

I'm currently testing this on another machine running a variant of Linux 3.10.40, and I get the same error. Thanks again, Dimitri, for your help with this. I hope to get this camera working soon, so any random ideas would be appreciated.

[ddiakopoulos]

Yeah, it looks like the kernel is appropriately patched. I'm wondering about your hardware though (embedded system? if you're tied to a specific kernel). The USB host controller could be getting in the way.

I don't often recommend this, but maybe you should try with the libuvc/libusb backend (can configure it in the makefile with a flag). Although this backend isn't as stable as the V4L2, you might actually be able to stream some data.

[ghost]

Yeah, my main target is embedded, hence the restriction. But the system I've tried various 3.19 kernels on is just VirtualBox on a MacBook Air. Neither work, and they fail in the same way.

I'll give libuvc a go, but I can't do without V4L2 since I have other cameras dependant on it. If I recall correctly from your instructions, these are mutually exclusive, but I'll tinker with it, anyway.

Thanks for the tip, Dimitri.

[ddiakopoulos]

Hmm! I've tested in the past on Virtual Box and the USB 3.0 software translation layer is really buggy. It was a long time ago, but I believe I ran into the same issue. VMWare's hypervisor does at least work, but we still don't recommend it because of streaming timeouts after 30-60 seconds. Best bet is to try on the native hardware!

[ghost]

@ddiakopoulos, libuvc does work for me. And after some consideration, I don't think I'll need the uvcvideo module for my other USB camera: I can use libuvc for that, too. Maybe @mremir could try that, too.

Thanks for helping out.

[ddiakopoulos]

@mremir do you need any further assistance here, or can I close this issue?

[mremir]

I would really like for the camera to work on a Ubuntu 12.04 but it does not.
We can get it to work the first time we plug in the camera using the uvc backend, but then we need to replug the camera every time the software needs to be restartet.
But I guess you can close this issue...

[ddiakopoulos]

@mremir I will update this issue when we have a potential work around posted to the repository sometime in the next few weeks. There is rarely used software reset function which will cause the R200 to reset itself without the unplug/replug on the libuvc backend (known issue...)

[mremir]

@ddiakopoulos That is really good news! Are there any chance that we can fix this ourself if you point us in the right direction?!?
Btw. If you give us a fix for this soon and email me your mailing address I'll make sure some chocolate or similar will find its way to you :-)

[ddiakopoulos]

There's a half-complete branch in this repository called reconnect (the only other one besides Master that the moment). It introduces an entrypoint rs_reset_device(rs_device * device, rs_error ** error)

Slightly intuitively, you would call this right before your application exits. It's not clear to me how functional the branch is, but it boils down to calling this function: https://github.com/IntelRealSense/librealsense/blob/master/src/r200-private.cpp#L403 It basically causes the firmware to nuke itself and re-enumerate on the OS. Early in this project before the V4L2 backend existed, we would call the firmware_reset function in the destructor of the R200 device (!)

[ghost]

Yep, @mremir, adding r200::force_firmware_reset(get_device()) to ~r200_camera() fixes the restart issue with libUVC.