pinchartl: ah yes I had forgotten about v4l2_device_register_subdev_nodes(). Thanks for your reply! I found the patchset https://patchwork.kernel.org/cover/11463183/ . So, iiuc, with this, a subdevice could be exposed allowing subscribe_event, but not set_format, right?
koike: correct
what events does your subdev generate ?
is there a recommended way to build the media repo? I am having difficulties building for an existing kernel...
ezequielg: pong
dafna2: the v4l2_pix_format struct used to end at the priv field, but we needed to add more fields. It turned out that priv was rarely used in drivers (private driver-specific field).
I think we dropped support for priv in the few drivers that used it and added the new CAP and the magic value to indicate to userspace that the new fields are supported by the driver.
_mplane came later and didn't need this workaround.
hverkuil: would you have time to review "[PATCH v7 0/6] v4l2-dev/ioctl: Add V4L2_CAP_IO_MC" at some point ?
pinchartl: it's high on my list :-)
thanks :-)
pinchartl: patches 1-3 are unchanged compared to the v6 series? Just checking.
hverkuil: I'm not sure. neg ?
neg: it looks like only patch 4/6 was changed compared to v6.
hverkuil: Yes only 4/6 is changed to add support for the filter in VIDIOC_ENUM_FMT and patch 2/6 is new
Thanks!
hverkuil: hello there \o
v4l2-compliance currently skips V4L2_CID_MPEG_VIDEO_FWHT_PARAMS, there's a comment saying "Skip..." in control testing.
I believe a similar handling is needed for all the other codec controls.
There isn't really a test for them, I think, as drivers aren't providing any defaults.
I'm wondering if we should patch v4l2-compliance to skip those CID_xxx or, maybe just patch to skip all compound types?
or try something entirely different.
RE [PATCH v7 2/6] ivtv-ioctl.c: Do not initialize the reserved field of struct v4l2_fmtdesc : iirc the build bot also mentioned drivers/media//pci/cx18/cx18-ioctl.c
https://patchwork.kernel.org/patch/11446337/#23232213
neg, pinchartl: ^^^
Otherwise I am using "v4l2-dev/ioctl: Add V4L2_CAP_IO_MC" and "media: v4l2: Extend VIDIOC_ENUM_FMT to support MC-centric devices" starting from the v6 already. Should I add my "Tested-by:", or "Reviewed-by:" to these two patches (which one fits better)?
ezequielg: I'm not really sure why that control is skipped. What exactly fails if that control isn't skipped?
I don't think doing a g_ctrl/s_ctrl works for these controls.
the g_ctrl should only get you a zeroed structure.
so if there's any sanity check on the s_ctrl, it will fail.
oh, but std_validate_compound doesn't apply to FWHT_PARAMS...
hm.
andrey-konovalov: My bad I missed the issue for cx18 and only fixed it for ivtv
ezequielg: yeah, that needs to be fixed. There should be a proper default for this control and also a proper validation. I think those core features were added later.
I don't think we can come up with any sensible e.g. H264_SPS default.
since it doesn't represent the driver state in any way, but the bitstream.
ezequielg: it doesn't have to be sensible, it just has to be valid. It's like the default format you get with G_FMT: it's probably not what you want, but it is valid.
pinchartl: regarding events, rkisp1 generate V4L2_EVENT_FRAME_SYNC and I saw meditek isp doing the same
koike: yes, that's very useful
ezequielg: Are you able to help me with the stk1160 today?
MateusRodCosta: sorry, i'm busy now.
No problem
MateusRodCosta: do you have any indication that this is a software issue? I thought the conclusion was that the unit was defective.
Ping me if you have some free time today
you mentioned it wasn't working on Windows, and you mentioned other devices were working fine... so it's hard to think it's a software issue.
I didn't even managed to install the driver on Windows though
from the discussion on Sunday, it all pointed at some hw issue.
not sure what else I can do to help ^_^
Ok, I will check if I can replace it
Thanks