<!-- 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>
***: Renault has left
kido: hi! I'm still working on a v4l2 m2m driver for allwinner's VPU and I'm now able to decode my first frames with a userspace c code that is largely a ugly proof of concept. just to remind the main problem of this VPU: it needs prior bitstream parsing which can't be done in kernel and isn't done anywhere in the video stack yet. since this problem also appears on rockchip's VPUs, hverkuil1 told me to contact pawel
<br> osciak for info about the "frame api" and his user space stack but I got no answer from him in two weeks so I still have no idea what I should do with the userspace in order to have a fully working stack.
<br> do you think it would be ok to implement a vdpau backend interfacing with my driver and implementing driver-specific frames parsing ? since there isn't really any good way of doing I can't think of anything better
hverkuil1: <u>kido</u>: I haven't heard much from Pawel lately.
<br> The big missing piece is the request API.
<br> The last post about this was "[RFC v2 0/21] Media request API" from Sakari on May 24th.
<br> And I still need to look at that :-(
<br> <u>kido</u>: I would post the early version of your driver to the linux-media mailinglist as RFC and ask for advice. Cc Sakari Ailus and Pawel Osciak.
<br> The reality is that someone needs to drive this development and push people to help with advice, pointers etc.
kido: ok, I'll probably clean it and post a RFC
hverkuil1: I don't know if you are paid to do this, or if it is a hobby. The problem with these things is that everyone is busy, so most of us don't have the time to do any coding, all we can do is point to possible solutions and look at proposals.
<br> And if you want this to be a success you'll have to (politely! :-) ) prod us into action where needed.
<br> I've marked the Media request API RFC patch series as something I should review, so when I have some time (hopefully the first week of August) I'll go through it.
kido: it's an internship, and of course I totally understand that you are busy and I am just asking for pointers if someone has a good idea of what to do. my sincere apologies if I appeared impolite!
hverkuil1: You'll need that anyway and it is time we put some more effort into it.
kido: talking about the request API, I watched the ELC presentation from pinchartl and for now I don't use it since my C code synchronizes an extended control containing the full frame header and buffer queueing/dequeueing. I don't see the need for an atomic pipeline configuration of subdevices (since there are no subdevices) but I'm probably missing something, have I misunderstood anything?
hverkuil1: <u>kido</u>: normally I would expect that each buffer that you queue would have its own specific frame header and other codec information associated with it. The request API allows you to associate controls with buffers (i.e. per-frame configuration).
<br> Don't you need that?
<br> or do you only every queue one buffer and wait until it is en/decoded?
kido: indeed, I just do it "manually" for now: setting an extended control, queuing, dequeuing, setting an extended control, queueing ...
hverkuil1: I.e. there is only one buffer at a time in the queue for the HW codec.
kido: that's what I do for now, and probably the reason why I didn't understand the need for the request api
hverkuil1: Yeah, that explains it.
<br> Does the driver somehow ensure that only one buffer can be queued at a time?
<br> (it probably can be done in the queue_setup vb2 callback)
kido: no :) but now I totally see the problem
<br> I have another question, my VPU needs pointers to previous and next frames for MPEG forward and backward prediction. for this reason, I will probably need a large queue and I suppose I can't dequeue buffers that will be used for predictions, right?
hverkuil1: <u>kido</u>: ah yes, an internship. Now I remember. And you were very polite :-) Occasionally we encounter some people who think that just because they ask, everyone else has to jump up and help them immediately. Not a good strategy if you want something from others.
<br> <u>sailus</u>: reviewed your patch series.
ribalda: <u>hverkuil1</u>: Hello!, do you remember what we agreed about V4L2_CTRL_FLAG_VOLATILE and V4L2_CTRL_FLAG_EXECUTE_ON_WRITE controls? Should they send an event or not on change?
hverkuil1: <u>ribalda</u>: [PATCH v2 1/5] media/v4l2-ctrls: volatiles should not generate CH_VALUE
<br> So apparently not :-)
ribalda: I know the author of that patch, he is an idiot
<br> :P
hverkuil1: Oh, I don't know. He's an OK bloke. :-)
<br> Seems to be an expert on potatoes.
ribalda: I ask because i a m revisiting the problem. The control is the lens apertrure
<br> it can be changed by the user (manually), change of focal lenght....
<br> We are building a GUI and it is not responsive to changes from outside applications, because the subsystem is filtering the event. I am trying to think under what circumstances a execute_on_write volatile should not generate ch-value
<br> I am talking about a control that is both volatie and execute_on_write. i agree that volatiles should not generate events
hverkuil1: <u>Weird</u>: from the spec: "Note that setting a new value for a volatile control will have no effect and no V4L2_EVENT_CTRL_CH_VALUE will be sent, unless the V4L2_CTRL_FLAG_EXECUTE_ON_WRITE flag (see below) is also set. Otherwise the new value will just be ignored."
<br> that contradicts the code.
ribalda: Shall I prepare a patch?
<br> On my scenario it makes more sense to send the event, but it is your call. I can either fix the doc or the code
hverkuil1: i think it makes no sense to get a CH_VALUE event for volatile controls. The value you get is meaningless.
<br> Unless you think otherwise?
<br> So the doc should be updated and clarified. Use the docs-next branch for that with the new doc-rst sphinx documentation.
ribalda: This is my scenario: 2 guis accessing the camera at the same time
<br> when one changes the apperture, the other wants to know that. Constant polling the aperture is too expensive
<br> (spi/ irqs....)
hverkuil1: Why is the control volatile?
ribalda: because the user might change it manually
<br> handling the lens iris
<br> (F number)
hverkuil1: But if the user changes it, then neither GUI will know about it, right?
ribalda: The GUI has a button to get the value from the hw
<br> we assume that if the operator handles the camera there will be a gui out of sync
<br> also it almost never hapens, as the machines are operated remotely 99.9% of time
<br> in execute on write, the event could mean: Ey, v4l2 is touching the hardware, in case anyone is interested
hverkuil1: No, I don't think sending a CH_VALUE event will help. It just papers over the problem.
<br> I think you have two options to do this cleanly:
<br> 1) poll periodically in the GUI
<br> 2) poll periodically in the driver
<br> In the case of 2) you can drop the volatile flag.
ribalda: ok,
<br> I will send a patch with the fixed doc.
<br> Thanks for your help!
hverkuil1: If the driver detects that is was manually changed, then it can change the control's value, triggering a CH_VALUE event.
<br> my pleasure.
***: benjiG has left
mchehab: <u>ribalda</u>: please always test the document changes with:
<br> make IGNORE_DOCBOOKS=1 htmldocs
<br> that would help noticing tag errors like:
<br> > + unless `V4L2_CTRL_FLAG_EXECUTE_ON_WRITE`` flag (see below) is also set.
ribalda: <u>mchehab</u>: ups, I fix it right away
<br> sorry
mchehab: hverkuil1 pointed it already
<br> I only noticed that you likely didn' t test it ;)
ribalda: The issue is that testing rst was not in my pre-send-to-the-list-and-avoid-humiliation.sh
<br> :P
<br> It will not happen again
mchehab: :)
ribalda: <u>mchehab</u>: It passes my parser
mchehab: well, rst is new... it is not yet in flux ;)
<br> it will build, but you need to check the generated html file to see what it generated
<br> unfortunately, the sphinx-build it not pedantic
<br> so, changes require manual eye inspection
ribalda: I see. because it did not through a warning http://pastebin.com/b1DuSZf6
mchehab: ah, you should install sphinx themes: sphinx_rtd_theme'
<br> on Fedora, this is installed automatically, but on Debian/Ubuntu, it requires a manual install
<br> for the themes
<br> the html output files will be at Documentation/output/html
<br> (by default)
ribalda: I got it, now it tools like it seems
<br> Setting a new value for a volatile control will be ignored unless V4L2_CTRL_FLAG_EXECUTE_ON_WRITE flag (see below) is also set. Setting a new value for a volatile contol will never trigger a V4L2_EVENT_CTRL_CH_VALUE event.
<br> https://postimg.org/image/l8qtnqkrl/
mchehab: sounds better ;)
<br> still, the "see below" is something that likely requires to be fixed
hverkuil1: <u>ribalda</u>: you didn't fix all my comments: typo in 'contol
ribalda: you want a hyperlink
mchehab: yes
hverkuil1: 'contol' and the emphasis around 'never'.
ribalda: <u>hverkuil1</u>: I just saw your mail. I already fixed it
hverkuil1: :-)
ribalda: https://postimg.org/image/hpi97pn07/
hverkuil1: Nice.
mchehab: see kernel-documentation.rst for the markups accepted by kernel-doc
<br> you may also use references with :ref: (for a rest reference)
hverkuil1: That padding around ``foo`` is still very ugly. But I don't speak enough html/css to know where to look. (I just tried, but this needs someone who knows what it going on).
mchehab: <u>hverkuil1</u>: yeah, agreed
hverkuil1: It's the <code class="docutils literal"> that does it, that I know.
mchehab: you need to write something at Documentation/sphinx-static/theme_overrides.css
<br> to change it
hverkuil1: Got to go. I have vacation next week, so I will be (a lot?) less responsive.
<br> <u>mchehab</u>: FYI: this pull request is still pending: https://patchwork.linuxtv.org/patch/35736/
<br> It's all fixes that should go into 4.8.
mchehab: seems too big to merge that early
<br> if they're just documentation or trivial stuff, I may still handle it
hverkuil1: Hmm, I could split it into two, some of these don't really need to go to 4.8 (e.g. deprecated create_singlethread_workqueue)
mchehab: I suspect that Linus will release 4.7 this weekend
<br> it is too late to send things for -next before that happens
hverkuil1: You know, let me split it into two pull requests, one for 4.8, one for 4.9.
mchehab: (and he usually takes a snapshot of the -next before a new release - to be aware if maintainers are well-behaving ;) )
<br> <u>hverkuil1</u>: thanks!
ribalda: <u>mchehab</u>: hverkuil1: I need to run now, I will send the patch later today or tomorrow max
<br> thanks for your help!
<br> (I am not struggling with the reference)
<br> see you
hverkuil1: <u>mchehab</u>: posted v4 of my pull request. Now only containing fixes. Esp. the vb2 patch fixes a nasty bug.
mchehab: ok
hverkuil1: https://patchwork.linuxtv.org/patch/35750/
***: hverkuil1 has left
-: headless is going to try the new VIN driver, theold one didn't work with adv7612 driver
***: Renault has left
-: headless starts testing
headless: not so fast, "compatible" prop not recognized
<br> "select timeout", hmm
<br> neg, ever saw this?
***: awalls1 has left
headless: wow, captured smth!
<br> neg, could you 1st add rcar-gen2-vin and only then add gen3 support? :-)
<br> I don't want to import all gen3 related patches just for that patch
neg: <u>headless</u>: which patch are you refering to? Gen2 only support should be in media-next and patches on ML are to add Gen3
headless: neg, the final patch in the gen3 series adds fallback strings is the last one in the gen3 series
<br> I'm testing on 7792 and that bited me
<br> oops, tautlogical sentence
neg: ahh OK sure, so you want a separat patch for Gen2 fallback string?
headless: neg yes
<br> ,
<br> OTOH, I have this patch in the internal tree (minus chnagelog), so can post it too...
<br> I guess I could have taken that fial patch w/o the preceding series, that wouldn't be correct tho
<br> *final
<br> thanks for not being too drunk and replying this late on Friday :-)
neg: sure no problem, you post it. I'm just happy someone is looking at the series :-)
headless: nuit