<!-- 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>
svarbanov: hverkuil, can you please decipher what that means: "fail: v4l2-test-buffers.cpp(253): g_field() == V4L2_FIELD_ANY"
hverkuil: The 'field' value returned by DQBUF shall never be 'ANY'.
<br> For your driver it should probably be always set to FIELD_NONE, unless you support interlaced formats as well.
svarbanov: I don't see DQBUF in the logs yet (even STREAMON did not happen)
<br> maybe this is the first QBUF(OUTPUT)
hverkuil: it's not just DQBUF, it's any ioctl that uses struct v4l2_buffer.
svarbanov: it's weird I always set the field = NONE
hverkuil: You need to check the field value in venus_helper_vb2_buf_prepare.
<br> See e.g. how that's done in drivers/media/platform/vicodec/vicodec-core.c.
<br> vicodec_buf_prepare
svarbanov: ok, thanks for the hints
<br> hverkuil, phew it is better now ;)
<br> hverkuil, can I run v4l2-compliance in streaming mode only and without the other tests?
hverkuil: No, it always performs those tests. Why?
svarbanov: because I want to debug streaming tests first, but the console is flooded with debug messages from the other tests
<br> hverkuil, much better https://paste.ubuntu.com/p/mQ9wMxnHr3/
hverkuil: You can ignore the "the input file is smaller than 708608 bytes" message: it's harmless. It's something that should be fixed in v4l2-compliance, but it is a bit tricky. It doesn't affect the tests, though.
<br> The crop/compose fails should be easy: it seems you are missing checks for invalid type values used in v4l2_selection.
<br> hmm, weird. You don't support s_selection at all.
svarbanov: hverkuil, "fail: v4l2-test-buffers.cpp(1324): node->dqevent(ev)" is that means no event received?
hverkuil: correct.
<br> The problem with the selection fail is in vdec_g_selection: CROP is only support for type CAPTURE, and COMPOSE is only supported for type OUTPUT.
<br> Right now both CROP and COMPOSE are valid for either CAPTURE or OUTPUT.
<br> Ah wait, I misread.
<br> Never mind, forget about what I said.
svarbanov: I ignored crop/composing tests - they always fails ;)
hverkuil: It looks to be a bug in v4l2-compliance.
svarbanov: hverkuil, what is the idea behind changing the fd_flags |= O_NONBLOCK and then call dqevent ?
<br> dqevent should return error in this case if no event and zero if event is in queue
hverkuil: <u>svarbanov</u>: pushed fix for selection v4l2-compliance fail.
<br> lunch, I'll get back to you later.
svarbanov: ok, lunch for me too
hverkuil: Regarding the dqevent test:
<br> what happens is that output buffers are queued to the driver containing the compressed data, then streamon is called for both output and capture.
<br> The test expects that enough output data is queued for the decoder to parse the metadata and issue a SOURCE_CHANGE event to signal to the application that it can configure the capture queue.
<br> (sorry, I said above that streamon is called for both output and capture, that's wrong. It's just called for output.)
<br> The test switches to non-blocking mode to avoid the test blocking on an event that never arrives.
<br> However, there may be a race condition here if it takes the decoder longer to parse the metadata then it takes the test to call dqevent. I.e. if dqevent is called while the HW is still parsing, then it will fail.
<br> This might need to be changed to a select with a 1 second timeout.
svarbanov: hverkuil, yes, that definitely is a race or at least wrong decision could be made if the event doesn't come immediately
<br> which seems is happen in my case, because I see the event is sent from firmware but it hasn't been received in userspace
<br> infact according to the stateful spec you should keep qbuf/dqbuf(output) until event is received, no?
hverkuil: Can you add a sleep(1) before the dqevent line and see if that solves the problem?
<br> And yes, the spec says that you have to keep qbuf/dqbuf, but for the compliance test I assume that after filling in all requested output buffers enough data is there to be able to parse the metadata.
<br> But I was also too lazy to implement this :-)
<br> <u>mchehab</u>: note that linux-media seems to be dead: no new messages are arriving. Not sure if you have contacts with vger.kernel.org that you can ask to take a look at this.
<br> <u>mchehab</u>: hmm, it seems that other MLs on vger.kernel.org are also affected.
headless: <u>hverkuil</u>: affected by what? (netdev only had mails for yesterday)?
<br> well, linux-usb also seems silent
-: headless -> cafe
mchehab: <u>hverkuil</u>: yeah, vger stopped sending e-mails
<br> I suspect they're already aware
ezequielg: <u>hverkuil</u>: patches 1-4 from https://patchwork.linuxtv.org/project/linux-media/list/?series=91 should be ready.
<br> (if i didn't screw it)
mchehab: b-rad: thanks for the submission! patches applied
b-rad: :D my pleasure, now that the ice is broken i'll try not take so long
mchehab: good!
<br> except between -rc6 to -rc1 (and PTO periods), I usually handle pull requests at least once a week
<br> so, it should take less time for your stuff to be merged
b-rad: cheers
mchehab: cheers
b-rad: added another pcie device to my analog series, just gotta verify it works before i fix the issues and resend the series