sailus: God morgon :-)
Weird. My decoder claims to support video capture multiplanar and video output multiplanar: https://p.mort.coffee/5t4 - VIDIOC_QUERYCAP doesn't set V4L2_CAP_VIDEO_CAPTURE_MPLANE or V4L2_CAP_VIDEO_OUTPUT_MPLANE in the capabilities struct
mort_: it probably sets V4L2_CAP_VIDEO_M2M_MPLANE
you're right
pretty sure an older version of the driver advertised VIDEO_CAPTURE_MPLANE and VIDEO_OUTPUT_MPLANE though. Is it just a capability flags thing or is the interface for using the m2m API very different from using the capture_mplane/output_mplane API?
M2M devices have their own M2M capabilities, but old out-of-tree drivers sometimes set the capture and output caps instead. That's wrong.
this is the in-tree venus driver
What kernel version?
it used to advertise CAPTURE_MPLANE and OUTPUT_MPLANE in 4.9, it advertises only M2M_MPLANE in 5.7, not sure about versions inbetween
Ah, 4.9.
yeea
it's old
I take it enc/dec drivers don't use the capture/output API anymore and I have to rewrite a bunch of software to use m2m
venus driver didn't exist in 4.9. It arrived only in 4.13. And was properly using V4L2_CAP_VIDEO_M2M_MPLANE.
So: you have an out-of-tree driver in your 4.9 kernel.
huh, is that so
you're right, https://github.com/torvalds/linux/commit/af2c3834c8ca7cc65d15592ac671933df8848115 is the first commit with qcom/venus and that was in 2017, after 4.9
My guess is that your 4.9 kernel has an early version of the venus driver.
yeah
wait
all examples of the m2m interface also open two fds for the decoder device, configure one of them to be V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE and one to be V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE, and input frames via memory mapping to the output part and reads them via memory mapping from the input part
I assumed that the fact that the driver didn't have the capability VIDEO_OUTPUT_MPLANE and VIDEO_CAPTURE_MPLANE meant that you couldn't configure it to VIDEO_OUTPUT_MPLANE or VIDEO_CAPTURE_MPLANE
neg: Hejssan-svejssan!
sailus: I noticed your mail and I think we are on the right track? Thanks for rebasing
neg: Jag skulle skicka begäran för att dra om du är nöjd med lappan som ändrar namn för async notifier funktioner.
Var så god.
sailus: Jag är nöjd, tackar
Det låter jättebra! Tack, tack!
djrscally: does the driver for the back sensor of the sgo2 enable hflip by default ?
pinchartl: No; it's 0
He says, confidently...
Let me check but I'm pretty sure it's 0 
Oh wait
Hmm, the control could be 0 but the driver might set it on still
I only checked the value of the control - I'll check the driver's behaviour too. 
I really wonder why it would appeared flipped by default
If I'm honest I've not looked at it at all to figure out why 
House move on Friday; life is currently a misery of cardboard boxes in the evenings
v4l2 control val definitely 0, and I can't see that the driver is enabling the hflip bits at any point outside of the hflip control's dedicated function
one more mystery...
Wonder what the back camera on my Miix does
I'll check that in a bit
curiously, with this new kernel version, I enqueue all the buffers for the capture side, enqueue some buffers with some encoded frames for the output side, while polling on the fd in another thread, and the poll never tells me A) that it's done using the buffers for the output side or B) that it has some decoded frames ready for the capture side
sailus: It looks like one R-Car patch that was part of the PR from Hans where not carried over to yours, was that intentional? https://patchwork.linuxtv.org/project/linux-media/patch/20210722075727.806572-1-niklas.soderlund+renesas@ragnatech.se/
neg: I took the rcar-vin set but missed there was another patch in the PR.
I was going to review that actually. :-)
sailus, feels like I've started, so I should finish on that series ;-)
but if it's already got a PR ... perhaps it's not worth it.
kbingham: Fixes can be done as separate patches, too.
sailus: OK, I suspect it needs to be rebased on-top of the PR to address the notifier rename. If I do so today or tomorrow could you send a separate PR for that patch? It is the last one needed to enable capture on the new platform
so, https://p.mort.coffee/rCa - that's a mix of messages from the kernel (messages starting with '[...]') and from my test program. From what I can understand, my program is doing everything correctly, but the poll on the decoder's file descriptor just never returns anything - neither output buffers nor capture buffers can be dequeued according to
poll().
and essentially identical code works with the encoder device
maybe it's time to start debugging the driver and/or devicetree
is svarbanov anywhere? He used to be fairly active in #v4l on freenode
sailus: how would it look like, adding HiSPi support in the AR0521 driver and DT bindings, if we don't specify bus-type = <4> explicitly already ? will the implicit default create additional complexity in the driver to preserve backward-compatibility ?
pinchartl: That doesn't actually affect the driver apart from having to start parsing the endpoint properties of the default bus type (versus any).
Beyond that, I doubt HiSPi will ever be used (at least in mainline).
you never know... :-) but I agree
we previously discussed an API that would allow drivers to call the parse function once only. in that context, would having no explicit default in DT be a problem ? I suppose that API would allow drivers to specify the default when not set in DT ?
The drivers can specify the default even today.
I suppose you could implement an API that allowed doing this with a single call but I wonder how pretty it would be.
There's no problem currently though, and DT bindings shouldn't be designed around drivers (or kernel frameworks) anyway.
But yeah, I don't think there are strict rules whether you need such a property (i.e. bus-type) or not.
right, but DT bindings should also not be designed in a way that would make driver support more difficult for no reason :-)
pinchartl: Agreed.