<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
hverkuil: Now is a good time to merge this cec kernel config option/cec header cleanup.
pinchartl: <u>hverkuil</u>: you're supposed to be on holidays :-)
hverkuil: <u>pinchartl</u>: I know, but this was fun :-)
<br> also, now is the time to do this.
<br> <u>mchehab</u>: thanks!
mchehab: anytime
***: hverkuil has left
sailus: <u>mchehab</u>: Could you check my reply on "Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control"?
-: mchehab is looking into it
mchehab: <u>sailus</u>: answered
<br> in summary, FOCUS_ABSOLUTE is actually controlling voice coil motors already, since 2008
<br> the only difference from your proposal seems to be due to the ringing compensation, but, in such case, you should add together a control for it and be clear
<br> about when one should be used or the other at the specs
***: benjiG has left
ezequielg: hi folks! my employer started working on an analog HD card (aka HDcctv). i have to write the host driver, so i received some SDKs and some cards.
<br> the card is PCIe and to our surprise it has an SoC and runs linux
<br> so, i was wondering: why would a vendor do this? isn't it far more robust to have specific-purpose hardware?
<br> (just out of curiosity)
ndufresne: flexibility ?
<br> the needed a good scheduler
<br> ?
<br> ezequielg, they most likely also have specific purpose hw in their SoC
ezequielg: not so sure - it has a video decoder of course, and the SoC seems to be the bridge to PCIe
ndufresne: ezequielg, see this as a Linux based firmware, rather then some "unknown" closed source firmware running some OS
larsc: people do this all the time
<br> a ASIC is quite expensive
ezequielg: i'm fine with it. it's just as bad or good as closed firmware.
<br> <u>larsc</u>: right, that was my question. how usual is this.
<br> ok, so it's cheaper to write some slave drivers
larsc: is it a SoC or a FPGA+SoC?
<br> for low-volume products this is pretty much the norm these days I'd say
<br> a PCIe card is not that different from a standalone system anyway
ezequielg: not sure there is an FPGA
<br> so in order for an ASIC development to make sense, the product volume has to justify it.
<br> my fear is this: maybe once analog HD is the norm, another chip will come out, and I will have to write another driver.
larsc: well, tough luck
<br> I mean that also happens all the time
ezequielg: ok, cool. it is what it is then.
<br> ok, one more "is this expected" question :-) is it frequent to have to fight for sources?
larsc: depends of whom you work with I'd say
ezequielg: right - let's hope for the best
<br> <u>larsc</u>: no FPGA at sight - just a nice codec SoC
<br> so, i guess this is just as good as an ASIC. I've had a ton of headaches working around "oddities" in ASIC as well, so...
faLUCE: hello. I'm really getting crazy in setting the frames per second of my camera. struct v4l2_fract framerate; CLEAR(framerate); framerate.numerator = 1; framerate.denominator = 25; xioctl(mFd, VIDIOC_S_PARM, &framerate); <---- I obtain about 5 fps, regardless of denominator's value. If I don't execute the ioctl, the fps is about 25. Where's the error?
<br> pinchartl:
ezequielg: <u>faLUCE</u>: https://linuxtv.org/downloads/v4l-dvb-apis/uapi/v4l/vidioc-g-parm.html
<br> are you sure VIDIOC_S_PARM is expecting a struct v4l2_fract ?
faLUCE: <u>ezequielg</u>: do you mean that I have to pass v4l2_captureparam.timeperframe ?
<br> <u>ezequielg</u>: tried with struct v4l2_captureparm param;CLEAR(param);param.timeperframe.numerator = 1;param.timeperframe.denominator = 25;//xioctl(mFd, VIDIOC_S_PARM, &param) but in this case the ioctl returns an error
<br> <u>ezequielg</u>: sorry
<br> now I understood
<br> ezequielg and others. I tried with struct v4l2_streamparm param;CLEAR(param); param.parm.capture.timeperframe.numerator = 1; param.parm.capture.timeperframe.denominator = 25; xioctl(mFd, VIDIOC_S_PARM, &param) but the ioctl still returns an error
<br> solved. I forgot: param.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
ezequielg: <u>faLUCE</u>: ;-)
<br> docs are good
faLUCE: <u>ezequielg</u>: when they exists ;-)
<br> <u>ezequielg</u>: when they exist ;-)
pinchartl: <u>faLUCE</u>: the uvcvideo driver doesn't implement framerate control through VIDIOC_S_PARM
<br> the frame rate is controlled through exposure time
<br> in most cases cameras will use auto-exposure, so the frame rate will depend on the amount of ambient light
<br> most of them will let you disable auto-exposure and set the exposure time manually
<br> please also note that the USB bandwidth puts a cap on the frame rate
<br> if you try to capture uncompressed frames at high resolution, the device might restrict the frame rate
<br> (I assume you're using a UVC camera, other drivers can behave differently)
faLUCE: <u>pinchartl</u>: thanks. But what does it mean? faLUCE: the uvcvideo driver doesn't implement framerate control through VIDIOC_S_PARM ... I just used struct v4l2_captureparm param;CLEAR(param);param.timeperframe.numerator = 1;param.timeperframe.denominator = 15; xioctl(... VIDIOC_S_PARAM) and it set the framerate
pinchartl: I should have said "doesn't implement framerate control solely through VIDIOC_S_PARM", sorry
<br> the driver implements VIDIOC_S_PARM
<br> and that allows selecting the desired frame rate
<br> but auto-exposure can result in a lower frame-rate
<br> also, VIDIOC_S_PARM can return a different frame rate than the one you request
<br> you should priint param.timeperframe.numerator and param.timeperframe.denominator after the ioctl returns
faLUCE: <u>pinchartl</u>: I see. I'll rename framerate into wanted_framerate
<br> thanks
pinchartl: if the driver then returns the requested frame rate, that will be the target that the camera will try to reach. it shouldn't go over than, but could still reduce the frame rate depending on the ambient light
faLUCE: I have another question. It happens, for example when using a bad usb HUB, that the dequeued frame is corrupted and it has a size < than the raw size. How can I check that? ioctl(mFd, VIDIOC_DQBUF, &buf) doesn't return an error, as well as VIDIOC_QBUF
<br> they return a corrupted frame, with data
pinchartl: the uvcvideo driver should drop corrupted frames by default
<br> at least if you capture in an uncompressed format
faLUCE: <u>pinchartl</u>: yes, it's uncompressed
pinchartl: if you capture in MJPEG it can't detect if part of the frame is missing
faLUCE: but frames aren't drop
pinchartl: does the buffer returned by DQBUF have a bytesused < expected size ?
<br> you should also check the content of /sys/module/uvcvideo/parameters/nodrop
<br> if set to 0 the driver should drop frames that are too small
faLUCE: <u>pinchartl</u>: I miss expected size. I know only how to check byteused
pinchartl: if it doesn't, then there's likely a bug in the driver somewhere
<br> the expected size is the one returned by VIDIOC_S_FMT
<br> or VIDIOC_G_FMT after setting the format
faLUCE: <u>pinchartl</u>: nodrop is set to 0. Anyway I'll check the expected size
pinchartl: weird
faLUCE: <u>pinchartl</u>: if you want, I can do a test for you, with video capture example
<br> do you need a test?
<br> (just tell me)
pinchartl: I'm not chasing bugs, but if you run into one, please report it :-)
faLUCE: <u>pinchartl</u>: with these settings: http://paste.ubuntu.com/24415828/ and with a BAD hub, I obtain fmt.fmt.pix.sizeimage = 50688
<br> so, I can't find a way to compute the right image size
pinchartl: 50688 ? that makes no sense at all
<br> what's the ioctl sequence that lead to that value ?
faLUCE: <u>pinchartl</u>: the sequence is that of https://raw.githubusercontent.com/gjasny/v4l-utils/master/contrib/test/capture-example.c (the "famous" video-capture-example.c)
<br> <u>pinchartl</u>: I also tested that code, and the same error happens
pinchartl: where do you print fmt.fmt.pix.sizeimage in that code ?
faLUCE: <u>pinchartl</u>: http://paste.ubuntu.com/24415864/ <--- look at the line starting with "//ADDITION"
<br> (line 492)
pinchartl: that's very surprising
<br> can you remove lines 493 to 498 and rerun it ?
<br> VIDIOC_S_FMT will also return the sizeimage value
<br> I'd like to see if it matches the weird 50688 value
faLUCE: <u>pinchartl</u>: just done. I obtain 50688 as well
pinchartl: what the...
<br> can you show me the USB descriptors of your camera ?
<br> the output of
<br> lsusb -v -d VID:PID
<br> where VID and PID are the camera's vendor and product IDs
<br> (running as root if possible)
faLUCE: http://paste.ubuntu.com/24415880/
<br> pinchartl:
pinchartl: of course
<br> lines 210 to 243
<br> the only two resolutions supported in uncompressed YUV format are 160x120 and 176x144
<br> 50688 is 176*144*2
<br> that makes sense
<br> if you print the width and height values returned by VIDIOC_S_FMT or any subsequent VIDIOC_G_FMT, you will get 176 and 144
<br> you can also get that through the frame size enumeration ioctl
<br> you can't capture 640x480 in YUV with that camera
<br> I assume because it's connected to a USB 1.1 hub
faLUCE: <u>pinchartl</u>: I see, but it seems a bit confusing... I mean: I understand it for framerate, but for sizes it's a bit strange
<br> but maybe I'm wrong, and it's the right way
<br> <u>pinchartl</u>: anyway, thanks, I'll do a complete check
pinchartl: the hub reports that the link can only work in full speed (12 Mb/s, USB 1.1)
<br> the link is then configured to full speed by the kernel
<br> the camera knows that
<br> so it reports only low resolutions
<br> as it can't stream higher resolutions at such a low speed
faLUCE: <u>pinchartl</u>: yes, I see, but the ioctl should report an error.... IMHO
pinchartl: with a proper hub, configuring the link in high speed, the camera reports higher resolutions
<br> no, V4L2 format ioctls don't return an error when the requested resolution isn't supported
<br> they instead return the closest supported configuration
<br> that allows applications to negotiate resolutions with the driver
<br> otherwise you would get an error, and you wouldn't know what to try next
faLUCE: <u>pinchartl</u>: I see
<br> <u>pinchartl</u>: thanks
pinchartl: so you should always check the format and resolution returned by the VIDIOC_S_FMT ioctl
<br> if it doesn't match what you requested, you can either consider that as an error and bail out
faLUCE: yes, I have to check all the set values
pinchartl: of if the returned configuration can still be used by your application, then adjust your internal parameters to use it
faLUCE: yes, thanks
pinchartl: you're welcome
pbos: <u>pinchartl</u>: I think the last patch is pretty much verbatim what you suggested, except for additional_name instead of string, lmk if you want me to update that
pinchartl: <u>pbos</u>: how about "function" instead of "additional_name" ?
<br> the variable doesn't store a name
<br> "string" was indeed too generic
<br> or iFunction ?
pbos: <u>pinchartl</u>: it's kinda "function_or_interface" which seems a little lame
pinchartl: yes, it's a bit long :-)
pbos: <u>pinchartl</u>: description_string?
<br> desc_str? :p
pinchartl: :-)
pbos: interface_str ?
pinchartl: I'd go for function. what you want is the function, and you fall back to the interface name to describe the function when iFunction is not available
pbos: sure
pinchartl: function, func_string, func_str, function_string, just pick one
<br> I'd go for the first personally
pbos: I'll go with whatever you accept, the bikeshed can be red for all I care :)
pinchartl: I'll accept any of the above, and you know my preference :-)
pbos: <u>pinchartl</u>: Renamed + sent, assuming my regex isn't super broken it should be good to go
pinchartl: :-)
pbos: I'll do a build under 3.14, but I really don't see my s/additional_name/function/g breaking it
pinchartl: by the way, the indentation fix for the snprintf() call is out of scope if I wanted to be pedantic, but as it's related, I think it's better to keep it in the patch instead of splitting it to a separate patch
<br> that's why I haven't commented on that in v3
pbos: super, wasn't intended but I had that fixed in my local patchset before and it seemed like it could stay
<br> <u>pinchartl</u>: Builds fine under 3.14. Will you sanity check before merging?
pinchartl: sure
pbos: Thanks
pinchartl: you seem to dislike the ternary ? : operator :-)
<br> <u>pbos</u>: your latest patch doesn't extend the name field to 64 characters anymore. is that on purpose ?
pbos: <u>pinchartl</u>: It's cut somewhere between there and v4l-ctl and Chrome either way, so I don't think extending only that field is sufficient.
<br> So since it was only half fixed I didn't see value in expanding the field
pinchartl: the V4L2 API cuts the name to 32 characters
<br> you could make it longer in the kernel as it's also used to print kernel messages
<br> but that's probably overkill
pbos: I also found a ton of name fields that are [32] long, so I wouldn't be surprised if one of them mistakenly uses the sizeof the other, and my change would break those buggy usages.
pinchartl: I don't think there's a big risk, but as the userspace API is restricted to 32 characters anyway, it probably makes no sense to increase it
pbos: I thought that primarily, and expanding userspace is probably a separate change. The specific camera I'm testing fits within this length.
pinchartl: yes, that would be a separate change, as it's a standard API :-)
pbos: So I have no urgency to do that at least. :)
pinchartl: nitpicking a bit more, how about
<br> + if (intf->intf_assoc && intf->intf_assoc->iFunction != 0)
<br> + function = intf->intf_assoc->iFunction;
<br> + else
<br> + function = intf->cur_altsetting->desc.iInterface;
<br> that makes it clearer what the default case is in my opinion
<br> compared to
<br> + function = intf->cur_altsetting->desc.iInterface;
<br> + if (intf->intf_assoc && intf->intf_assoc->iFunction != 0)
<br> + function = intf->intf_assoc->iFunction;
<br> you don't have to resubmit, I can change that when applying
pbos: Yeah I'm fine with that
<br> I'm just used to fairly stupid compilers that can say that function may not be defined after that
<br> you can also do that as a ternary if you want to
<br> whatever boats your float
pinchartl: how can function not be defined after that ?
<br> it's a plain else, not an else if
pbos: <u>pinchartl</u>: Ask msvc :)
pinchartl: do you compile the linux kernel with msvc ? :-)
pbos: not sure if this exact one would, but a switch case that returns on all labels, including default, will result in a warning that the function doesn't always return a value (because the compiler thinks it might continue)
<br> nah, just work habit
pinchartl: :-)
<br> testing the patch now
faLUCE: is there a list of v4l2 supported usb devices with their respective pixel formats?
pinchartl: I don't think so
<br> you can find a list of supported UVC devices at http://ideasonboard.org/uvc/
<br> it's in no way exhaustive
<br> and it doesn't list formats
<br> <u>pbos</u>: still compiling
pbos: <u>pinchartl</u>: Churn Churn :)
faLUCE: here'ìs my problem: I wrote a library which encodes images from web cameras and it streams them through the web (http-mpegts). I'm testing it, but I only have three cameras (different models) and they all support YUYV + MJPEG. I don't know how to do further tests, because I don't know which are the common formats used by the new usb cameras... Obviously, I can't buy them only for testing...
<br> I'm not searching for encoded images. Maybe YUYV + MJPEG is enough, but I wonder which other "common" formats should I test
pinchartl: one of YUYV or MJPEG will likely be supported by any recent USB camera
<br> many of the newest ones also support H.264
<br> but that's not supported by the uvcvideo driver yet
faLUCE: <u>pinchartl</u>: and other than YUYV which could be a common raw fmt?
pinchartl: that's really the only two common ones, there are a bunch of other formats, but very few cameras support them
faLUCE: I see. pinchartl, with YUYV do you mean YUYV422 packed, right?
pinchartl: yes
faLUCE: ok
pinchartl: <u>pbos</u>: everything seems to work fine. my device doesn't have an iFunction or iInterface though :-/
<br> that being said, I'm off to bed
pbos: <u>pinchartl</u>: Thanks, sleep tight!
<br> <u>pinchartl</u>: Can you let me know when it's merged so I can downstream as landed?