Re: webcam fixes and changes in -current
> On Sep 23 20:55:45, h...@stare.cz wrote: > > On Aug 29 18:06:32, lau...@tratt.net wrote: > > > Lots of us have to use webcams more than we used to. There have been some > > > recent changes in OpenBSD support for webcams that some might find useful. > > > Most of the hard work was done by Marcus Glocker, with input from Ingo > > > Feinerer, sc.dying, and myself. > > > > Thanks to all! The uvideo on my old MacBook1,1 > > (dmesg below) is back, for instance. > > Ah. This is with a diff (below) I got on misc earlier. > Sorry for the confusion. Here is the same with UVIDEO_DEBUG, if it's of any help. I can donate the MacBook if anyone is interested. Jan $ video -q video device /dev/video: encodings: uyvy frame sizes (width x height, in pixels) and rates (in frames per second): 320x240: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30 352x288: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30 640x480: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30 controls: brightness, saturation, gamma, sharpness messages: Sep 24 09:58:29 mb32 /bsd: uvideo0: uvideo_open: sc=0xd580b000 Sep 24 09:58:29 mb32 /bsd: uvideo0: uvideo_find_ctrl: control not supported by device! Sep 24 09:58:29 mb32 last message repeated 4 times Sep 24 09:58:30 mb32 /bsd: uvideo0: uvideo_close: sc=0xd580b000 Sep 24 09:58:30 mb32 /bsd: uvideo0: uvideo_vs_free_isoc $ video -c video: VIDIOC_G_CTRL: Invalid argument brightness=63 saturation=5 gamma=100 sharpness=3 messages: Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_open: sc=0xd580b000 Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_find_ctrl: control not supported by device! Sep 24 09:58:35 mb32 last message repeated 4 times Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_s_fmt: requested width=640, height=480 Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_find_res: frame index 0: width=640, height=480 Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_find_res: frame index 1: width=352, height=288 Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_find_res: frame index 2: width=320, height=240 Sep 24 09:58:35 mb32 /bsd: uvideo0: SET probe request successfully Sep 24 09:58:35 mb32 /bsd: bmHint=0x01 Sep 24 09:58:35 mb32 /bsd: bFormatIndex=0x01 Sep 24 09:58:35 mb32 /bsd: bFrameIndex=0x01 Sep 24 09:58:35 mb32 /bsd: dwFrameInterval=33 (100ns units) Sep 24 09:58:35 mb32 /bsd: wKeyFrameRate=0 Sep 24 09:58:35 mb32 /bsd: wPFrameRate=0 Sep 24 09:58:35 mb32 /bsd: wCompQuality=0 Sep 24 09:58:35 mb32 /bsd: wCompWindowSize=0 Sep 24 09:58:35 mb32 /bsd: wDelay=0 (ms) Sep 24 09:58:35 mb32 /bsd: dwMaxVideoFrameSize=0 (bytes) Sep 24 09:58:35 mb32 /bsd: dwMaxPayloadTransferSize=0 (bytes) Sep 24 09:58:35 mb32 /bsd: uvideo0: GET probe request successfully Sep 24 09:58:35 mb32 /bsd: bmHint=0x00 Sep 24 09:58:35 mb32 /bsd: bFormatIndex=0x01 Sep 24 09:58:35 mb32 /bsd: bFrameIndex=0x01 Sep 24 09:58:35 mb32 /bsd: dwFrameInterval=33 (100ns units) Sep 24 09:58:35 mb32 /bsd: wKeyFrameRate=0 Sep 24 09:58:35 mb32 /bsd: wPFrameRate=0 Sep 24 09:58:35 mb32 /bsd: wCompQuality=0 Sep 24 09:58:35 mb32 /bsd: wCompWindowSize=0 Sep 24 09:58:35 mb32 /bsd: wDelay=33 (ms) Sep 24 09:58:35 mb32 /bsd: dwMaxVideoFrameSize=614400 (bytes) Sep 24 09:58:35 mb32 /bsd: dwMaxPayloadTransferSize=3072 (bytes) Sep 24 09:58:35 mb32 /bsd: fixed dwMaxVideoFrameSize=614400, width=640 height=480 bpp=16 Sep 24 09:58:35 mb32 /bsd: uvideo0: SET commit request successfully Sep 24 09:58:35 mb32 /bsd: uvideo0: uvideo_s_fmt: offered width=640, height=480 Sep 24 09:58:35 mb32 /bsd: uvideo0: SET probe request successfully Sep 24 09:58:35 mb32 /bsd: bmHint=0x01 Sep 24 09:58:35 mb32 /bsd: bFormatIndex=0x01 Sep 24 09:58:35 mb32 /bsd: bFrameIndex=0x01 Sep 24 09:58:35 mb32 /bsd: dwFrameInterval=33 (100ns units) Sep 24 09:58:35 mb32 /bsd: wKeyFrameRate=0 Sep 24 09:58:35 mb32 /bsd: wPFrameRate=0 Sep 24 09:58:35 mb32 /bsd: wCompQuality=0 Sep 24 09:58:35 mb32 /bsd: wCompWindowSize=0 Sep 24 09:58:35 mb32 /bsd: wDelay=0 (ms) Sep 24 09:58:35 mb32 /bsd: dwMaxVideoFrameSize=0 (bytes) Sep 24 09:58:35 mb32 /bsd: dwMaxPayloadTransferSize=0 (bytes) Sep 24 09:58:35 mb32 /bsd: uvideo0: GET probe request successfully Sep 24 09:58:35 mb32 /bsd: bmHint=0x00 Sep 24 09:58:35 mb32 /bsd: bFormatIndex=0x01 Sep 24 09:58:35 mb32 /bsd: bFrameIndex=0x01 Sep 24 09:58:35 mb32 /bsd: dwFrameInterval=33 (100ns units) Sep 24 09:58:35 mb32 /bsd: wKeyFrameRate=0 Sep 24 09:58:35 mb32 /bsd: wPFrameRate=0 Sep 24 09:58:35 mb32 /bsd: wCompQuality=0 Sep 24 09:58:35 mb32 /bsd: wCompWindowSize=0 Sep 24 09:58:35 mb32 /bsd: wDelay=33 (ms) Sep 24 09:58:35 mb32 /bsd: dwMaxVideoFrameSize=614400 (bytes) Sep 24 09:58:35 mb32 /bsd: dwMaxPayloadTransferSize=3072 (bytes) Sep 24 09:58:35 mb32 /bsd: fixed dwMaxVideoFrameSize=614400, width=640 height=480 bpp
Re: webcam fixes and changes in -current
On Aug 29 18:06:32, lau...@tratt.net wrote: > The first change is that MJPEG in cameras now works reliably. In essence, > most webcams can deliver uncompressed video at a low frame rate or > compressed (MJPEG) at a high frame rate. Testing with a MikrOkular HD by Bresser, a USB camera that plugs into a microscope tubus. > ffplay -f v4l2 -list_formats all -i /dev/video0 Compressed: mjpeg : MJPEG : 1280x720 640x480 There is no "Raw" stanza - it only emits a MJPEG stream. > $ video -q video: /dev/video has no usable YUV encodings. This seems to agree with ffmpeg's detection. > As that suggests, video(1) only easily supports YUY2/YUYV422. I am unsure about "easily" - is video(1) expected to support MJPEG at all? > The easiest > way to see higher frame rates I know of is to use ffmpeg. Most cameras can > sustain 30fps (or sometimes 60fps) at high resolutions as can be seen with: > > $ ffplay -f v4l2 -input_format mjpeg -video_size 1920x1080 -i /dev/video0 Works like a charm. > If you use video chat in a browser, you should find that it can now reliably > support higher resolutions without problems. I can't wait to stream yeast replication live, now that I can :-) > however, the settings are "sticky" so they effect > subsequent programs which use the webcam. Yes: ffplay -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video0 will make the next ffplay -f v4l2 -input_format mjpeg -i /dev/video0 also use 1280x720; same for 640x480. > Overall, I think this makes webcams much more usable under OpenBSD It's an obscure networking OS, everybody knows that. Thanks to all, Jan Sep 24 09:02:12 mb32 /bsd: uvideo1 at uhub0 port 1 configuration 1 interface 0 "Alcor Micro MikrOkularHD" rev 2.00/0.00 addr 3 Sep 24 09:02:12 mb32 /bsd: bLength=9 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x02 (UDESC_CONFIG) Sep 24 09:02:12 mb32 /bsd: | Sep 24 09:02:12 mb32 /bsd: bLength=9 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x02 Sep 24 09:02:12 mb32 /bsd: wTotalLength=311 Sep 24 09:02:12 mb32 /bsd: bNumInterface=0x02 Sep 24 09:02:12 mb32 /bsd: bConfigurationValue=0x01 Sep 24 09:02:12 mb32 /bsd: iConfiguration=0x00 Sep 24 09:02:12 mb32 /bsd: bmAttributes=0x80 Sep 24 09:02:12 mb32 /bsd: bMaxPower=0x64 Sep 24 09:02:12 mb32 /bsd: bMaxPower=0x64 Sep 24 09:02:12 mb32 /bsd: bLength=8 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x0b (UDESC_IFACE_ASSOC) Sep 24 09:02:12 mb32 /bsd: | Sep 24 09:02:12 mb32 /bsd: bLength=8 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x0b Sep 24 09:02:12 mb32 /bsd: bFirstInterface=0x00 Sep 24 09:02:12 mb32 /bsd: bInterfaceCount=2 Sep 24 09:02:12 mb32 /bsd: bFunctionClass=0x0e Sep 24 09:02:12 mb32 /bsd: bFunctionSubClass=0x03 Sep 24 09:02:12 mb32 /bsd: bFunctionProtocol=0x00 Sep 24 09:02:12 mb32 /bsd: iFunction=0x04 Sep 24 09:02:12 mb32 /bsd: iFunction=0x04 Sep 24 09:02:12 mb32 /bsd: bLength=9 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x04 (UDESC_INTERFACE) Sep 24 09:02:12 mb32 /bsd: | Sep 24 09:02:12 mb32 /bsd: bLength=9 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x04 Sep 24 09:02:12 mb32 /bsd: bInterfaceNumber=0x00 Sep 24 09:02:12 mb32 /bsd: bAlternateSetting=0x00 Sep 24 09:02:12 mb32 /bsd: bNumEndpoints=1 Sep 24 09:02:12 mb32 /bsd: bInterfaceClass=0x0e Sep 24 09:02:12 mb32 /bsd: bInterfaceSubClass=0x01 Sep 24 09:02:12 mb32 /bsd: bInterfaceProtocol=0x00 Sep 24 09:02:12 mb32 /bsd: iInterface=0x04 Sep 24 09:02:12 mb32 /bsd: iInterface=0x04 Sep 24 09:02:12 mb32 /bsd: bLength=13 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24 (CS_INTERFACE) Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x01 (UDESCSUB_VC_HEADER) Sep 24 09:02:12 mb32 /bsd: | Sep 24 09:02:12 mb32 /bsd: bLength=13 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24 Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x01 Sep 24 09:02:12 mb32 /bsd: bcdUVC=0x0100 Sep 24 09:02:12 mb32 /bsd: wTotalLength=79 Sep 24 09:02:12 mb32 /bsd: dwClockFrequency=3000 Sep 24 09:02:12 mb32 /bsd: bInCollection=0x01 Sep 24 09:02:12 mb32 /bsd: bInCollection=0x01 Sep 24 09:02:12 mb32 /bsd: bLength=28 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24 (CS_INTERFACE) Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x06 (UDESCSUB_VC_EXTENSION_UNIT) Sep 24 09:02:12 mb32 /bsd: | Sep 24 09:02:12 mb32 /bsd: bLength=28 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24 Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x06 Sep 24 09:02:12 mb32 /bsd: bUnitID=0x06 Sep 24 09:02:12 mb32 /bsd: guidExtensionCode=0xb0d0bb68a461834b90b7a6215f3c4f70 Sep 24 09:02:12 mb32 /bsd: bNumControls=0x18 Sep 24 09:02:12 mb32 /bsd: bNrInPins=0x01 Sep 24 09:02:12 mb32 /bsd: bNrInPins=0x01 Sep 24 09:02:12 mb32 /bsd: bLength=18 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24 (CS_INTERFACE) Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x02 (UDESCSUB_VC_INPUT_TERMINAL) Sep 24 09:02:12 mb32 /bsd: | Sep 24 09:02:12 mb32 /bsd: bLength=18 Sep 24 09:02:12 mb32 /bsd: bDescriptorType=0x24 Sep 24 09:02:12 mb32 /bsd: bDescriptorSubtype=0x02 Sep 24 09:02:12 mb32 /bsd: b
Re: webcam fixes and changes in -current
On Sep 23 20:55:45, h...@stare.cz wrote:
> On Aug 29 18:06:32, lau...@tratt.net wrote:
> > Lots of us have to use webcams more than we used to. There have been some
> > recent changes in OpenBSD support for webcams that some might find useful.
> > Most of the hard work was done by Marcus Glocker, with input from Ingo
> > Feinerer, sc.dying, and myself.
>
> Thanks to all! The uvideo on my old MacBook1,1
> (dmesg below) is back, for instance.
Ah. This is with a diff (below) I got on misc earlier.
Sorry for the confusion.
Without the diff, uvideo only attaches as bluetooth:
uvideo0 at uhub0 port 4 configuration 1 interface 0 "Apple Computer Bluetooth"
rev 2.00/0.0c addr 2
uvideo0: can't find video interface
dmesg below; this is with UVIDEO_DEBUG,
but there don't seem to be any messages,
presumably because uvideo is not even attached.
Anyway, the diff below makes uvideo attach on a macbook1,1
- i.e. reattach the bluetooth as uvideo.
Jan
> It attaches in a strange way on boot:
>
> uvideo0 at uhub0 port 4 configuration 1 interface 0 "Apple Computer
> Bluetooth" rev 2.00/0.0c addr 2
> uvideo0 detached
> uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight"
> rev 2.00/1.84 addr 2
> video0 at uvideo0
>
> Does the device attach as bluetooth first,
> and the kernel later decides it is a camera?
>
> This is how it used to work on these macbooks for me,
> and it got broken some weeks ago; now video(4) is back.
>
>
> $ video -q
> video device /dev/video:
> encodings: uyvy
> frame sizes (width x height, in pixels) and rates (in frames per second):
> 320x240: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
> 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
> 352x288: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
> 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
> 640x480: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
> 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
> controls: brightness, saturation, gamma, sharpness
>
> The repetition of the 30 (fps) seems strange
> - perhaps there is some quirk in getting the list
> of the camera's supported frame rates.
>
>
> $ video -c
> video: VIDIOC_G_CTRL: Invalid argument
> brightness=63
> saturation=5
> gamma=100
> sharpness=3
>
>
> Capturing doesn't work though:
>
> $ video -v
> video device /dev/video:
> encodings: uyvy
> frame sizes (width x height, in pixels) and rates (in frames per second):
> 320x240: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
> 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
> 352x288: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
> 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
> 640x480: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
> 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
> controls: brightness, saturation, gamma, sharpness
> Xv adaptor 0, Intel(R) Textured Video:
> encodings: yuy2, uyvy, yv12
> max size: 1280x800
> using uyvy encoding
> using frame size 640x480 (614400 bytes)
> using default frame rate
> video: VIDIOC_G_CTRL: Invalid argument
> video: ioctl VIDIOC_DQBUF: Invalid argument
>
>
> The first error shows immediately after start,
> the camera led lights up, and a black rectangle is shown;
> after a few seconds, video(1) emits the second message
> and exits with an exit value of 1.
>
> Jan
>
>
> OpenBSD 6.8-beta (GENERIC.MP) #0: Wed Sep 23 13:07:51 CEST 2020
> h...@mb32.stare.cz:/usr/src/sys/arch/i386/compile/GENERIC.MP
> real mem = 2113323008 (2015MB)
> avail mem = 2058436608 (1963MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: date 07/29/05, SMBIOS rev. 2.4 @ 0xe7490 (36 entries)
> bios0: vendor Apple Computer, Inc. version "MB11.88Z.0061.B03.0610121324"
> date 10/12/06
> bios0: Apple Computer, Inc. MacBook1,1
> acpi0 at bios0: ACPI 3.0
> acpi0: sleep states S0 S3 S4 S5
> acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT
> acpi0: wakeup devices ADP1(S3) LID0(S3) PXS1(S4) PXS2(S4) USB1(S3) USB2(S3)
> USB3(S3) USB4(S3) USB7(S3) EC__(S3)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Genuine Intel(R) CPU T2500 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz,
> 06-0e-08
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 166MHz
> cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: Genuine Intel(R) CPU T2500 @
Re: webcam fixes and changes in -current
On Aug 29 18:06:32, lau...@tratt.net wrote:
> Lots of us have to use webcams more than we used to. There have been some
> recent changes in OpenBSD support for webcams that some might find useful.
> Most of the hard work was done by Marcus Glocker, with input from Ingo
> Feinerer, sc.dying, and myself.
Thanks to all! The uvideo on my old MacBook1,1
(dmesg below) is back, for instance.
It attaches in a strange way on boot:
uvideo0 at uhub0 port 4 configuration 1 interface 0 "Apple Computer Bluetooth"
rev 2.00/0.0c addr 2
uvideo0 detached
uvideo0 at uhub0 port 4 configuration 1 interface 0 "Micron Built-in iSight"
rev 2.00/1.84 addr 2
video0 at uvideo0
Does the device attach as bluetooth first,
and the kernel later decides it is a camera?
This is how it used to work on these macbooks for me,
and it got broken some weeks ago; now video(4) is back.
$ video -q
video device /dev/video:
encodings: uyvy
frame sizes (width x height, in pixels) and rates (in frames per second):
320x240: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
352x288: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
640x480: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
controls: brightness, saturation, gamma, sharpness
The repetition of the 30 (fps) seems strange
- perhaps there is some quirk in getting the list
of the camera's supported frame rates.
$ video -c
video: VIDIOC_G_CTRL: Invalid argument
brightness=63
saturation=5
gamma=100
sharpness=3
Capturing doesn't work though:
$ video -v
video device /dev/video:
encodings: uyvy
frame sizes (width x height, in pixels) and rates (in frames per second):
320x240: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
352x288: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
640x480: 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30
controls: brightness, saturation, gamma, sharpness
Xv adaptor 0, Intel(R) Textured Video:
encodings: yuy2, uyvy, yv12
max size: 1280x800
using uyvy encoding
using frame size 640x480 (614400 bytes)
using default frame rate
video: VIDIOC_G_CTRL: Invalid argument
video: ioctl VIDIOC_DQBUF: Invalid argument
The first error shows immediately after start,
the camera led lights up, and a black rectangle is shown;
after a few seconds, video(1) emits the second message
and exits with an exit value of 1.
Jan
OpenBSD 6.8-beta (GENERIC.MP) #0: Wed Sep 23 13:07:51 CEST 2020
h...@mb32.stare.cz:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem = 2113323008 (2015MB)
avail mem = 2058436608 (1963MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 07/29/05, SMBIOS rev. 2.4 @ 0xe7490 (36 entries)
bios0: vendor Apple Computer, Inc. version "MB11.88Z.0061.B03.0610121324" date
10/12/06
bios0: Apple Computer, Inc. MacBook1,1
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT
acpi0: wakeup devices ADP1(S3) LID0(S3) PXS1(S4) PXS2(S4) USB1(S3) USB2(S3)
USB3(S3) USB4(S3) USB7(S3) EC__(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Genuine Intel(R) CPU T2500 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz,
06-0e-08
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Genuine Intel(R) CPU T2500 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz,
06-0e-08
cpu1:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,MWAIT,VMX,EST,TM2,xTPR,PDCM,NXE,PERF,SENSOR,MELTDOWN
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (PCIB)
acpisbs0 at acpi0: SBS0 model "ASMB016" serial 35580 type LION oem "DP"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
"APP0002" at acpi0 not configured
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
"PNP0A08" at acpi0 not configured
asmc0 at acpi0: SMC
Re: webcam fixes and changes in -current
Thank you very much, you made a difference in a teacher's life. Regards Laurence Tratt wrote: > Lots of us have to use webcams more than we used to. There have been > some recent changes in OpenBSD support for webcams that some might > find useful. Most of the hard work was done by Marcus Glocker, with > input from Ingo Feinerer, sc.dying, and myself. > > The first change is that MJPEG in cameras now works reliably. In > essence, most webcams can deliver uncompressed video at a low frame > rate or compressed (MJPEG) at a high frame rate. The latter tickled a > limitation in the USB stack, which led to the picture breaking up -- > and which is now fixed! If you want to know what your camera is > capable of, my suggestion is to install ffmpeg and then run: > > $ ffplay -f v4l2 -list_formats all -i /dev/video0 > > which will output lots of stuff, but at the end has the important > bits: > > [video4linux2,v4l2 @ 0x914fbbb6000] Raw : yuyv422 : > YUYV : 640x480 160x90 160x120 176x144 320x180 320x240 > 352x288 432x240 640x360 800x448 800x600 864x480 960x720 1024x576 > 1280x720 1600x896 1920x1080 2304x1296 2304x1536 [video4linux2,v4l2 @ > 0x914fbbb6000] Compressed: mjpeg :MJPEG : > 640x480 160x90 160x120 176x144 320x180 320x240 352x288 432x240 > 640x360 800x448 800x600 864x480 960x720 1024x576 1280x720 1600x896 > 1920x1080 > > This shows that my C920s webcam has a maximum MJPEG resolution of > 1920x1080. The "raw" options (yuyv422) might look tempting as they > have a max resolution of 2304x1536, but "video -q" shows they can > only achieve low frame rates: > > $ video -q > video device /dev/video: > encodings: yuy2 > frame sizes (width x height, in pixels) and rates (in frames per > second): 160x90: 30, 24, 20, 15, 10, 7, 5 > 160x120: 30, 24, 20, 15, 10, 7, 5 > 176x144: 30, 24, 20, 15, 10, 7, 5 > 320x180: 30, 24, 20, 15, 10, 7, 5 > 320x240: 30, 24, 20, 15, 10, 7, 5 > 352x288: 30, 24, 20, 15, 10, 7, 5 > 432x240: 30, 24, 20, 15, 10, 7, 5 > 640x360: 30, 24, 20, 15, 10, 7, 5 > 640x480: 30, 24, 20, 15, 10, 7, 5 > 800x448: 30, 24, 20, 15, 10, 7, 5 > 800x600: 24, 20, 15, 10, 7, 5 > 864x480: 24, 20, 15, 10, 7, 5 > 960x720: 15, 10, 7, 5 > 1024x576: 15, 10, 7, 5 > 1280x720: 10, 7, 5 > 1600x896: 7, 5 > 1920x1080: 5 > 2304x1296: 2 > 2304x1536: 2 > controls: brightness, contrast, saturation, gain, sharpness, > white_balance_temperature > > As that suggests, video(1) only easily supports YUY2/YUYV422. The > easiest way to see higher frame rates I know of is to use ffmpeg. > Most cameras can sustain 30fps (or sometimes 60fps) at high > resolutions as can be seen with: > > $ ffplay -f v4l2 -input_format mjpeg -video_size 1920x1080 -i > /dev/video0 > > If you use video chat in a browser, you should find that it can now > reliably support higher resolutions without problems. > > video(1) has also been extended to allow altering webcam controls > from the command-line. In order to do this, nothing else can be using > the webcam; however, the settings are "sticky" so they effect > subsequent programs which use the webcam. I can see the current > settings with: > > $ video -c > brightness=128 > contrast=128 > saturation=128 > gain=0 > sharpness=128 > white_balance_temperature=auto > > and I can reset things back to a known state with: > > $ video -d > > I can change e.g. brightness with: > > $ video brightness=200 > brightness: 128 -> 200 > > Some, though not all, controls have automatic adjustment. If your > webcam has the white_balance_temperature control, it probably > defaults to "auto", meaning that it tries to adjust based on how > yellow/white it thinks the light is. In my experience, the automatic > adjustment ends up making everything look like a Smurfs homage (i.e. > too blue). video(1) allows us to override the automatic setting and > specify a temperature manually (in Kelvin). During the day I might > use: > > $ video white_balance_temperature=5000 > white_balance_temperature: auto -> 5000 > > If you really want, you can use "auto" as a value for such controls > instead of a numeric value. Note further that if you're used to other > operating systems webcam support, you might expect there to be two > white balance temperature controls (one for the manual temperature > and a separate auto boolean): video(1) unifies them. > > You can specify multiple controls at once e.g.: > > $ video brightness=50 white_balance_temperature=3000 > brightness: 128 -> 50 > white_balance_temperature: auto -> 3000 > > Be aware that uvideo doesn't yet support the "camera terminal control > requests" part of the UVC spec so some controls (e.g. zoom, pan, and > exposure) cannot be altered. If and when uvideo gains such support, > the necessary changes to video(1) will be trivial. > > Overall, I think this makes webcams mu
webcam fixes and changes in -current
Lots of us have to use webcams more than we used to. There have been some recent changes in OpenBSD support for webcams that some might find useful. Most of the hard work was done by Marcus Glocker, with input from Ingo Feinerer, sc.dying, and myself. The first change is that MJPEG in cameras now works reliably. In essence, most webcams can deliver uncompressed video at a low frame rate or compressed (MJPEG) at a high frame rate. The latter tickled a limitation in the USB stack, which led to the picture breaking up -- and which is now fixed! If you want to know what your camera is capable of, my suggestion is to install ffmpeg and then run: $ ffplay -f v4l2 -list_formats all -i /dev/video0 which will output lots of stuff, but at the end has the important bits: [video4linux2,v4l2 @ 0x914fbbb6000] Raw : yuyv422 : YUYV : 640x480 160x90 160x120 176x144 320x180 320x240 352x288 432x240 640x360 800x448 800x600 864x480 960x720 1024x576 1280x720 1600x896 1920x1080 2304x1296 2304x1536 [video4linux2,v4l2 @ 0x914fbbb6000] Compressed: mjpeg : MJPEG : 640x480 160x90 160x120 176x144 320x180 320x240 352x288 432x240 640x360 800x448 800x600 864x480 960x720 1024x576 1280x720 1600x896 1920x1080 This shows that my C920s webcam has a maximum MJPEG resolution of 1920x1080. The "raw" options (yuyv422) might look tempting as they have a max resolution of 2304x1536, but "video -q" shows they can only achieve low frame rates: $ video -q video device /dev/video: encodings: yuy2 frame sizes (width x height, in pixels) and rates (in frames per second): 160x90: 30, 24, 20, 15, 10, 7, 5 160x120: 30, 24, 20, 15, 10, 7, 5 176x144: 30, 24, 20, 15, 10, 7, 5 320x180: 30, 24, 20, 15, 10, 7, 5 320x240: 30, 24, 20, 15, 10, 7, 5 352x288: 30, 24, 20, 15, 10, 7, 5 432x240: 30, 24, 20, 15, 10, 7, 5 640x360: 30, 24, 20, 15, 10, 7, 5 640x480: 30, 24, 20, 15, 10, 7, 5 800x448: 30, 24, 20, 15, 10, 7, 5 800x600: 24, 20, 15, 10, 7, 5 864x480: 24, 20, 15, 10, 7, 5 960x720: 15, 10, 7, 5 1024x576: 15, 10, 7, 5 1280x720: 10, 7, 5 1600x896: 7, 5 1920x1080: 5 2304x1296: 2 2304x1536: 2 controls: brightness, contrast, saturation, gain, sharpness, white_balance_temperature As that suggests, video(1) only easily supports YUY2/YUYV422. The easiest way to see higher frame rates I know of is to use ffmpeg. Most cameras can sustain 30fps (or sometimes 60fps) at high resolutions as can be seen with: $ ffplay -f v4l2 -input_format mjpeg -video_size 1920x1080 -i /dev/video0 If you use video chat in a browser, you should find that it can now reliably support higher resolutions without problems. video(1) has also been extended to allow altering webcam controls from the command-line. In order to do this, nothing else can be using the webcam; however, the settings are "sticky" so they effect subsequent programs which use the webcam. I can see the current settings with: $ video -c brightness=128 contrast=128 saturation=128 gain=0 sharpness=128 white_balance_temperature=auto and I can reset things back to a known state with: $ video -d I can change e.g. brightness with: $ video brightness=200 brightness: 128 -> 200 Some, though not all, controls have automatic adjustment. If your webcam has the white_balance_temperature control, it probably defaults to "auto", meaning that it tries to adjust based on how yellow/white it thinks the light is. In my experience, the automatic adjustment ends up making everything look like a Smurfs homage (i.e. too blue). video(1) allows us to override the automatic setting and specify a temperature manually (in Kelvin). During the day I might use: $ video white_balance_temperature=5000 white_balance_temperature: auto -> 5000 If you really want, you can use "auto" as a value for such controls instead of a numeric value. Note further that if you're used to other operating systems webcam support, you might expect there to be two white balance temperature controls (one for the manual temperature and a separate auto boolean): video(1) unifies them. You can specify multiple controls at once e.g.: $ video brightness=50 white_balance_temperature=3000 brightness: 128 -> 50 white_balance_temperature: auto -> 3000 Be aware that uvideo doesn't yet support the "camera terminal control requests" part of the UVC spec so some controls (e.g. zoom, pan, and exposure) cannot be altered. If and when uvideo gains such support, the necessary changes to video(1) will be trivial. Overall, I think this makes webcams much more usable under OpenBSD, and thanks again to Marcus, because none of this would have happened without him! Laurie
