tp4: Does your camera list the requested format as supported+ ? sailus: you can switch to my reqv10 branch. It has a bunch of fixes and it will (hopefully) handle controls correctly. It needs more testing in v4l2-compliance, but for now it is good enough. gnurou: tfiga: ^^^^^ Main change that will probably affect you: request objects must have a cancel op. This is needed when a request is queued, but the buffers associated with that request are not yet queued to the driver. Normally the driver will complete objects in stop_streaming, but in this case the driver doesn't know about these buffers/requests. So vb2 will cancel any associated request, and that in turn will call the cancel op for each object. It was the main cause of the lifetime problems that I had. It also fixes bugs where objects could be bound twice (I didn't check the request status). I've frozen reqv10 and will continue with reqv11. 1) more testing and once that's done 2) clean up the patch series. hverkuil: what's the latest code that I should review ? v9, but ignore the control patches. You can peek in my v10 branch for the media_request and vb2 changes that are not in v9: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=reqv10 paulk-gagarine: ^ hverkuil: thanks mripard, thanks hverkuil, should I base my next version of the sunxi-cedrus vpu driver on v10 then? paulk-gagarine: yes. hverkuil, alright! thanks for your work :) I think the public API is in good shape, although there may be some changes w.r.t. error codes, it's something that needs to be specced a bit better. I see hverkuil: I'll focus on the public API first hverkuil: should I mark V4L2_PIX_FMT_JPGL: descr = "JPEG Lite" and V4L2_PIX_FMT_S5C_UYVY_JPG: descr = "S5C73MX interleaved UYVY/JPEG" as ordered as well? for now I just put down JPEG and MJPEG padovan, out of curiosity, I recall that the S5C73Mx also has info like autofocus status in the raw data IIRC, is that handled too? padovan: unordered compressed formats are FMT_MPEG - FMT_HEVC (in the switch in v4l2-ioctl.c), all others are ordered. I've taken the afternoon off, so I'm back on Monday. The plan is to continue improving the control request tests in v4l2-compliance. And if it all works, then start to clean up the patch series for posting to the ML. I hope I can do that before I leave for Wed-Fri next week. Note regarding the v10 control handling: it should handle the control value chaining correctly, but once a request is marked completed it will copy the current state and no longer depend on other requests. This can be optimized as well, but that's an optimization for later (it's really only needed for large compound and/or array controls). hverkuil: I'm scared of looking at the patches to be honest :-) paulk-gagarine: not sure I follow. Handled by what? padovan, by the current upstream driver padovan, IIRC if you get frames in the interleaved mode, there is also metadata in there, about autofocus and other things so I'm wondering if that info is parsed and reported to userspace I've no idea. I'm touching that driver really oh ok hverkuil: okay, I'll mark those as unordered pinchartl: I'm scared of you looking at the patches :-) But I think (hope!) it's what you were looking for. :-) Hey, so i noticed i can provoke a kernel panic by ctrl-c-ing while my m2m device does an interrupt to signify the frame is finished. e.g. vb2_buffer_done() seems to get a NULL pointer if a ctrl-c is done at the exact right moment am i supposed to check all vb2_buffer s are valid before i finish the jobs?