| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | javier__ has quit IRC (Remote host closed the connection) | [00:02] |
| .......................................................................................... (idle for 7h29mn) | ||
| Renault has left | [07:31] | |
| .................. (idle for 1h29mn) | ||
| 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
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. 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 | [09:00] |
| hverkuil1 | kido: I haven't heard much from Pawel lately.
The big missing piece is the request API. The last post about this was "[RFC v2 0/21] Media request API" from Sakari on May 24th. And I still need to look at that :-( | [09:13] |
| kido: 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.
The reality is that someone needs to drive this development and push people to help with advice, pointers etc. | [09:23] | |
| kido | ok, I'll probably clean it and post a RFC | [09:24] |
| 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.
And if you want this to be a success you'll have to (politely! :-) ) prod us into action where needed. 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. | [09:26] |
| 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! | [09:28] |
| hverkuil1 | You'll need that anyway and it is time we put some more effort into it. | [09:28] |
| 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? | [09:33] |
| ..... (idle for 22mn) | ||
| hverkuil1 | kido: 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).
Don't you need that? or do you only every queue one buffer and wait until it is en/decoded? | [09:55] |
| kido | indeed, I just do it "manually" for now: setting an extended control, queuing, dequeuing, setting an extended control, queueing ... | [09:56] |
| hverkuil1 | I.e. there is only one buffer at a time in the queue for the HW codec. | [09:56] |
| kido | that's what I do for now, and probably the reason why I didn't understand the need for the request api | [09:56] |
| hverkuil1 | Yeah, that explains it.
Does the driver somehow ensure that only one buffer can be queued at a time? (it probably can be done in the queue_setup vb2 callback) | [09:57] |
| kido | no :) but now I totally see the problem | [09:58] |
| 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? | [10:03] | |
| hverkuil1 | kido: 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. | [10:04] |
| ....... (idle for 33mn) | ||
| sailus: reviewed your patch series. | [10:37] | |
| ................................ (idle for 2h39mn) | ||
| ribalda | hverkuil1: 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? | [13:16] |
| hverkuil1 | ribalda: [PATCH v2 1/5] media/v4l2-ctrls: volatiles should not generate CH_VALUE
So apparently not :-) | [13:18] |
| ribalda | I know the author of that patch, he is an idiot
:P | [13:19] |
| hverkuil1 | Oh, I don't know. He's an OK bloke. :-)
Seems to be an expert on potatoes. | [13:20] |
| ribalda | I ask because i a m revisiting the problem. The control is the lens apertrure
it can be changed by the user (manually), change of focal lenght.... 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 I am talking about a control that is both volatie and execute_on_write. i agree that volatiles should not generate events | [13:21] |
| hverkuil1 | Weird: 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."
that contradicts the code. | [13:26] |
| ribalda | Shall I prepare a patch?
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 | [13:27] |
| hverkuil1 | i think it makes no sense to get a CH_VALUE event for volatile controls. The value you get is meaningless.
Unless you think otherwise? So the doc should be updated and clarified. Use the docs-next branch for that with the new doc-rst sphinx documentation. | [13:34] |
| ribalda | This is my scenario: 2 guis accessing the camera at the same time
when one changes the apperture, the other wants to know that. Constant polling the aperture is too expensive (spi/ irqs....) | [13:34] |
| hverkuil1 | Why is the control volatile? | [13:36] |
| ribalda | because the user might change it manually
handling the lens iris (F number) | [13:36] |
| hverkuil1 | But if the user changes it, then neither GUI will know about it, right? | [13:37] |
| ribalda | The GUI has a button to get the value from the hw
we assume that if the operator handles the camera there will be a gui out of sync also it almost never hapens, as the machines are operated remotely 99.9% of time in execute on write, the event could mean: Ey, v4l2 is touching the hardware, in case anyone is interested | [13:38] |
| hverkuil1 | No, I don't think sending a CH_VALUE event will help. It just papers over the problem.
I think you have two options to do this cleanly: 1) poll periodically in the GUI 2) poll periodically in the driver In the case of 2) you can drop the volatile flag. | [13:44] |
| ribalda | ok,
I will send a patch with the fixed doc. Thanks for your help! | [13:45] |
| hverkuil1 | If the driver detects that is was manually changed, then it can change the control's value, triggering a CH_VALUE event.
my pleasure. | [13:45] |
| *** | benjiG has left | [13:58] |
| ........... (idle for 54mn) | ||
| mchehab | ribalda: please always test the document changes with:
make IGNORE_DOCBOOKS=1 htmldocs that would help noticing tag errors like: > + unless `V4L2_CTRL_FLAG_EXECUTE_ON_WRITE`` flag (see below) is also set. | [14:52] |
| ribalda | mchehab: ups, I fix it right away
sorry | [14:54] |
| mchehab | hverkuil1 pointed it already
I only noticed that you likely didn' t test it ;) | [14:54] |
| ribalda | The issue is that testing rst was not in my pre-send-to-the-list-and-avoid-humiliation.sh
:P It will not happen again | [14:55] |
| mchehab | :) | [14:57] |
| ribalda | mchehab: It passes my parser | [14:57] |
| mchehab | well, rst is new... it is not yet in flux ;)
it will build, but you need to check the generated html file to see what it generated unfortunately, the sphinx-build it not pedantic so, changes require manual eye inspection | [14:57] |
| ribalda | I see. because it did not through a warning http://pastebin.com/b1DuSZf6 | [14:59] |
| mchehab | ah, you should install sphinx themes: sphinx_rtd_theme'
on Fedora, this is installed automatically, but on Debian/Ubuntu, it requires a manual install for the themes the html output files will be at Documentation/output/html (by default) | [14:59] |
| ribalda | I got it, now it tools like it seems
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. https://postimg.org/image/l8qtnqkrl/ | [15:03] |
| mchehab | sounds better ;)
still, the "see below" is something that likely requires to be fixed | [15:07] |
| hverkuil1 | ribalda: you didn't fix all my comments: typo in 'contol | [15:08] |
| ribalda | you want a hyperlink | [15:08] |
| mchehab | yes | [15:08] |
| hverkuil1 | 'contol' and the emphasis around 'never'. | [15:08] |
| ribalda | hverkuil1: I just saw your mail. I already fixed it | [15:08] |
| hverkuil1 | :-) | [15:08] |
| ribalda | https://postimg.org/image/hpi97pn07/ | [15:09] |
| hverkuil1 | Nice. | [15:09] |
| mchehab | see kernel-documentation.rst for the markups accepted by kernel-doc
you may also use references with :ref: (for a rest reference) | [15:09] |
| 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). | [15:10] |
| mchehab | hverkuil1: yeah, agreed | [15:10] |
| hverkuil1 | It's the <code class="docutils literal"> that does it, that I know. | [15:11] |
| mchehab | you need to write something at Documentation/sphinx-static/theme_overrides.css
to change it | [15:12] |
| hverkuil1 | Got to go. I have vacation next week, so I will be (a lot?) less responsive.
mchehab: FYI: this pull request is still pending: https://patchwork.linuxtv.org/patch/35736/ It's all fixes that should go into 4.8. | [15:12] |
| mchehab | seems too big to merge that early
if they're just documentation or trivial stuff, I may still handle it | [15:14] |
| 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) | [15:15] |
| mchehab | I suspect that Linus will release 4.7 this weekend
it is too late to send things for -next before that happens | [15:16] |
| hverkuil1 | You know, let me split it into two pull requests, one for 4.8, one for 4.9. | [15:16] |
| mchehab | (and he usually takes a snapshot of the -next before a new release - to be aware if maintainers are well-behaving ;) )
hverkuil1: thanks! | [15:17] |
| ribalda | mchehab: hverkuil1: I need to run now, I will send the patch later today or tomorrow max
thanks for your help! (I am not struggling with the reference) see you | [15:24] |
| hverkuil1 | mchehab: posted v4 of my pull request. Now only containing fixes. Esp. the vb2 patch fixes a nasty bug. | [15:29] |
| mchehab | ok | [15:31] |
| hverkuil1 | https://patchwork.linuxtv.org/patch/35750/ | [15:31] |
| .................... (idle for 1h35mn) | ||
| *** | hverkuil1 has left | [17:06] |
| ........... (idle for 52mn) | ||
| headless | headless is going to try the new VIN driver, theold one didn't work with adv7612 driver | [17:58] |
| .......... (idle for 48mn) | ||
| *** | Renault has left | [18:46] |
| ...... (idle for 26mn) | ||
| headless | headless starts testing
not so fast, "compatible" prop not recognized | [19:12] |
| ..... (idle for 20mn) | ||
| "select timeout", hmm | [19:34] | |
| neg, ever saw this? | [19:39] | |
| ........ (idle for 37mn) | ||
| *** | awalls1 has left | [20:16] |
| headless | wow, captured smth! | [20:30] |
| ...... (idle for 27mn) | ||
| neg, could you 1st add rcar-gen2-vin and only then add gen3 support? :-)
I don't want to import all gen3 related patches just for that patch | [20:57] | |
| neg | headless: which patch are you refering to? Gen2 only support should be in media-next and patches on ML are to add Gen3 | [21:12] |
| headless | neg, the final patch in the gen3 series adds fallback strings is the last one in the gen3 series
I'm testing on 7792 and that bited me oops, tautlogical sentence | [21:15] |
| neg | ahh OK sure, so you want a separat patch for Gen2 fallback string? | [21:17] |
| headless | neg yes
, OTOH, I have this patch in the internal tree (minus chnagelog), so can post it too... I guess I could have taken that fial patch w/o the preceding series, that wouldn't be correct tho *final thanks for not being too drunk and replying this late on Friday :-) | [21:17] |
| neg | sure no problem, you post it. I'm just happy someone is looking at the series :-) | [21:20] |
| ................ (idle for 1h18mn) | ||
| headless | nuit | [22:38] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |