EasyCap USB and mode / video source blocking
EasyCap USB and mode / video source blocking
I note in the software section that having the EasyCap dongle connected blocks certain video camera devices / encoder modes.
Indeed as I have the easycap built into my case and plugged in, I had to unplug it to make the rpi cam work.
Is this a bug or a feature ?
I could easily fix it in hw by adding a switch in series with the USB control lines to the easycap, but a FW fix would be more elegant.
Are there any plans to address this or should I simply fit a switch ?
73 Tim
Indeed as I have the easycap built into my case and plugged in, I had to unplug it to make the rpi cam work.
Is this a bug or a feature ?
I could easily fix it in hw by adding a switch in series with the USB control lines to the easycap, but a FW fix would be more elegant.
Are there any plans to address this or should I simply fit a switch ?
73 Tim
Re: EasyCap USB and mode / video source blocking
Hi Tim
I spent a good few hours on this problem last week. The issue is a lot more complex to solve with software than it seems at first, mainly due to the specialised nature of the Pi hardware relating to its camera and hardware H264 encoder.
I suspect that the final answer is going to be a software controlled relay that switches the USB lines in and out - much as you have suggested. I'm still looking for a totally software based solution, but I will give up in a week or 2. I need to finalise the hardware design of my own Portsdown then!
If you want to future-proof your Portsdown against too many future changes, I would suggest a relay to switch the EasyCap into circuit when energised (ie normally out of circuit). We'll work out how to drive it in a few weeks, but there should not be any need for a front panel switch.
Dave
I spent a good few hours on this problem last week. The issue is a lot more complex to solve with software than it seems at first, mainly due to the specialised nature of the Pi hardware relating to its camera and hardware H264 encoder.
I suspect that the final answer is going to be a software controlled relay that switches the USB lines in and out - much as you have suggested. I'm still looking for a totally software based solution, but I will give up in a week or 2. I need to finalise the hardware design of my own Portsdown then!
If you want to future-proof your Portsdown against too many future changes, I would suggest a relay to switch the EasyCap into circuit when energised (ie normally out of circuit). We'll work out how to drive it in a few weeks, but there should not be any need for a front panel switch.
Dave
Re: EasyCap USB and mode / video source blocking
Hi Dave,
thanks for the explanation. I didn't want to clutter up the front panel with a switch as it would defeat the idea of a touch screen.
So a relay controlled by a GPIO signal seems like the better option at this point.
73 Tim
thanks for the explanation. I didn't want to clutter up the front panel with a switch as it would defeat the idea of a touch screen.
So a relay controlled by a GPIO signal seems like the better option at this point.
73 Tim
Re: EasyCap USB and mode / video source blocking
Disable via UDEV maybe and reload the rules? I suppose you tried that as well as loading and unloading kernel modules.
Mike
Mike
Re: EasyCap USB and mode / video source blocking
Mike
I did not get into udev, but am keen to try if you could help.
What I need to achieve is that the EasyCap always loads as /dev/video1, even if the RPi Camera has not activated and taken /dev/video0. The solution needs to work even if the PiCam or the EasyCap is not present.
How might I load/unload kernel modules to make it work?
Thanks
Dave
I did not get into udev, but am keen to try if you could help.
What I need to achieve is that the EasyCap always loads as /dev/video1, even if the RPi Camera has not activated and taken /dev/video0. The solution needs to work even if the PiCam or the EasyCap is not present.
How might I load/unload kernel modules to make it work?
Thanks
Dave
Re: EasyCap USB and mode / video source blocking
Hi Dave,
Like Mike says that sounds like a job for Udev - it's a problem I had before with various USB devices being allocated differently.
I understand enough to do it for Ubuntu (it's actually quite easy), but not sure about RPI but I doubt it's much different.
Knowing me I could do it ok, but would likely break something else in the process !
Like Mike says that sounds like a job for Udev - it's a problem I had before with various USB devices being allocated differently.
I understand enough to do it for Ubuntu (it's actually quite easy), but not sure about RPI but I doubt it's much different.
Knowing me I could do it ok, but would likely break something else in the process !
Re: EasyCap USB and mode / video source blocking
Hi Dave,
I would need to do some investigation - we had the same problem with the UKUBE ground station, with several audio cards and serial adaptors it was important to make them load consistently. I recall latterly similar issues with DATV Express. UDEV is designed to do exactly this, so if you want it to load as /dev/video1 you can do this with UDEV. The following is in linux lingo so may not make sense to many sorry.
Firstly we need the vendor code. I don't know how consistent these are. Plugging in the capture device and running the dmesg command piped through grep usb to reduce the verbiage indicates in my case
pi@raspberrypi:~ $ dmesg |grep usb
....
[ 328.387835] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
[ 328.519572] usb 1-1.3: New USB device found, idVendor=534d, idProduct=0021
[ 328.519585] usb 1-1.3: New USB device strings: Mfr=1, Product=0, SerialNumber=0
[ 328.519594] usb 1-1.3: Manufacturer: MACROSIL
pi@raspberrypi:~ $ dmesg |grep video
....
[ 328.520649] uvcvideo: Found UVC 1.00 device <unnamed> (534d:0021)
[ 328.520888] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[ 328.521569] uvcvideo 1-1.3:1.0: Entity type for entity Processing 2 was not initialized!
[ 328.521590] uvcvideo 1-1.3:1.0: Entity type for entity Camera 1 was not initialized!
and just for the record lsusb
pi@raspberrypi:~ $ lsusb
Bus 001 Device 006: ID 534d:0021
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
And video for linux shows that the device has defaulted to /dev/video0
pi@raspberrypi:~ $ v4l2-ctl -d 0 --all
Driver Info (not using libv4l2):
Driver name : uvcvideo
Card type : UVC Camera (534d:0021)
Bus info : usb-3f980000.usb-1.3
Driver version: 4.9.24
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
Width/Height : 720/480
Pixel Format : 'YUYV'
Field : None
Bytes per Line: 1440
Size Image : 691200
Colorspace : Unknown (00000000)
Flags :
Crop Capability Video Capture:
Bounds : Left 0, Top 0, Width 720, Height 480
Default : Left 0, Top 0, Width 720, Height 480
Pixel Aspect: 1/1
Selection: crop_default, Left 0, Top 0, Width 720, Height 480
Selection: crop_bounds, Left 0, Top 0, Width 720, Height 480
Streaming Parameters Video Capture:
Capabilities : timeperframe
Frames per second: 30.000 (30/1)
Read buffers : 0
brightness (int) : min=0 max=255 step=1 default=-8193 value=32
contrast (int) : min=0 max=255 step=1 default=57343 value=128
saturation (int) : min=0 max=255 step=1 default=57343 value=128
hue (int) : min=0 max=127 step=1 default=-8193 value=0
gamma (int) : min=0 max=50 step=1 default=57343 value=25
brightness (int) : min=0 max=255 step=1 default=-8193 value=32
contrast (int) : min=0 max=255 step=1 default=57343 value=128
saturation (int) : min=0 max=255 step=1 default=57343 value=128
hue (int) : min=0 max=127 step=1 default=-8193 value=0
gamma (int) : min=0 max=50 step=1 default=57343 value=25
So we know the capture cards vendor and device ID idVendor=534d, idProduct=0021
I was going to write instructions but then recalled they are already there in this post http://www.batc.org.uk/forum/viewtopic. ... 744#p11292
and even better here http://www.djsadhu.com/software/linux-h ... dev-rules/
Now this will simply map video0, and video1 to the same name each time but might not solve the problem if the software is hardwired to /video0. I think there is a way to make the capture driver module go to video1 but it will need more research. IT seems the answer is via the module uvcvideo but I need to find the manual.
Mike
I would need to do some investigation - we had the same problem with the UKUBE ground station, with several audio cards and serial adaptors it was important to make them load consistently. I recall latterly similar issues with DATV Express. UDEV is designed to do exactly this, so if you want it to load as /dev/video1 you can do this with UDEV. The following is in linux lingo so may not make sense to many sorry.
Firstly we need the vendor code. I don't know how consistent these are. Plugging in the capture device and running the dmesg command piped through grep usb to reduce the verbiage indicates in my case
pi@raspberrypi:~ $ dmesg |grep usb
....
[ 328.387835] usb 1-1.3: new high-speed USB device number 6 using dwc_otg
[ 328.519572] usb 1-1.3: New USB device found, idVendor=534d, idProduct=0021
[ 328.519585] usb 1-1.3: New USB device strings: Mfr=1, Product=0, SerialNumber=0
[ 328.519594] usb 1-1.3: Manufacturer: MACROSIL
pi@raspberrypi:~ $ dmesg |grep video
....
[ 328.520649] uvcvideo: Found UVC 1.00 device <unnamed> (534d:0021)
[ 328.520888] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[ 328.521569] uvcvideo 1-1.3:1.0: Entity type for entity Processing 2 was not initialized!
[ 328.521590] uvcvideo 1-1.3:1.0: Entity type for entity Camera 1 was not initialized!
and just for the record lsusb
pi@raspberrypi:~ $ lsusb
Bus 001 Device 006: ID 534d:0021
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
And video for linux shows that the device has defaulted to /dev/video0
pi@raspberrypi:~ $ v4l2-ctl -d 0 --all
Driver Info (not using libv4l2):
Driver name : uvcvideo
Card type : UVC Camera (534d:0021)
Bus info : usb-3f980000.usb-1.3
Driver version: 4.9.24
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format
Priority: 2
Video input : 0 (Camera 1: ok)
Format Video Capture:
Width/Height : 720/480
Pixel Format : 'YUYV'
Field : None
Bytes per Line: 1440
Size Image : 691200
Colorspace : Unknown (00000000)
Flags :
Crop Capability Video Capture:
Bounds : Left 0, Top 0, Width 720, Height 480
Default : Left 0, Top 0, Width 720, Height 480
Pixel Aspect: 1/1
Selection: crop_default, Left 0, Top 0, Width 720, Height 480
Selection: crop_bounds, Left 0, Top 0, Width 720, Height 480
Streaming Parameters Video Capture:
Capabilities : timeperframe
Frames per second: 30.000 (30/1)
Read buffers : 0
brightness (int) : min=0 max=255 step=1 default=-8193 value=32
contrast (int) : min=0 max=255 step=1 default=57343 value=128
saturation (int) : min=0 max=255 step=1 default=57343 value=128
hue (int) : min=0 max=127 step=1 default=-8193 value=0
gamma (int) : min=0 max=50 step=1 default=57343 value=25
brightness (int) : min=0 max=255 step=1 default=-8193 value=32
contrast (int) : min=0 max=255 step=1 default=57343 value=128
saturation (int) : min=0 max=255 step=1 default=57343 value=128
hue (int) : min=0 max=127 step=1 default=-8193 value=0
gamma (int) : min=0 max=50 step=1 default=57343 value=25
So we know the capture cards vendor and device ID idVendor=534d, idProduct=0021
I was going to write instructions but then recalled they are already there in this post http://www.batc.org.uk/forum/viewtopic. ... 744#p11292
and even better here http://www.djsadhu.com/software/linux-h ... dev-rules/
Now this will simply map video0, and video1 to the same name each time but might not solve the problem if the software is hardwired to /video0. I think there is a way to make the capture driver module go to video1 but it will need more research. IT seems the answer is via the module uvcvideo but I need to find the manual.
Mike
Re: EasyCap USB and mode / video source blocking
Dave - to kill the capture module just use sudo modprobe -r uvcvideo - however, that's not very cleanG8GKQ wrote:Mike
I did not get into udev, but am keen to try if you could help.
What I need to achieve is that the EasyCap always loads as /dev/video1, even if the RPi Camera has not activated and taken /dev/video0. The solution needs to work even if the PiCam or the EasyCap is not present.
How might I load/unload kernel modules to make it work?
Thanks
Dave
Its put back with sudo modprobe uvcvideo
As per usual the driver documentation is absolutely woeful. Should be able to put options in /etc/modprobe.d/uvcvideo.conf but what these options are is a mystery.
Re: EasyCap USB and mode / video source blocking
Mike
Thanks very much for both of these posts. I had tried the former method and rejected it because if you force load the Pi Cam early in boot to make sure that it is /dev/video0, the Pi freezes if the camera is not present, and I could not see a way around this. So not robust enough for Portsdown.
The second post using sudo modprobe -r uvcvideo is a lot more interesting - I don't care if it is not too clean as long as it works and the rest of the Portsdown functionality is unaffected by its lack of subtlety. I'll put aside some time to work on this tomorrow.
Thanks again
Dave
Thanks very much for both of these posts. I had tried the former method and rejected it because if you force load the Pi Cam early in boot to make sure that it is /dev/video0, the Pi freezes if the camera is not present, and I could not see a way around this. So not robust enough for Portsdown.
The second post using sudo modprobe -r uvcvideo is a lot more interesting - I don't care if it is not too clean as long as it works and the rest of the Portsdown functionality is unaffected by its lack of subtlety. I'll put aside some time to work on this tomorrow.
Thanks again
Dave