<!-- 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>
ribalda: <u>hverkuil</u>: Good moning/evening everyone
kbingham: Morning ribalda :)
ribalda: <u>hverkuil</u>: I have a core that is doing some per/pixel meassurement. I was implementing the readout of the meassurement using array controls
kbingham: <u>ribalda</u>: I was helping out some colleagues with some training last week - and he used your presention in his talks :)
ribalda: <u>kbingham</u>: hahaha, really? I am flattered! It was used as an example of how it should not be done?
hverkuil: <u>ribalda</u>: morning!
kbingham: <u>ribalda</u>: Not at all :) - it was definitely used in good light :)
ribalda: <u>hverkuil</u>: But then I realised that I cannot change the number of elements on the fly. Would you consider a patch to change that?
hverkuil: <u>FYI</u>: I'm about to go to lunch
ribalda: <u>hverkuil</u>: Enjoy your lunch, there is absolutely no rush
hverkuil: What do you mean exactly? You want to get a subset of the array?
ribalda: <u>hverkuil</u>: the array must be as big as the current image
<br> when the user changes the image via s_fmt the array size changes
<br> the user allways wants the whole array
<br> <u>kbingham</u>: This week we are preparing a webinar with amd/mentor: https://www.mentor.com/embedded-software/events/developing-an-industrial-machine-vision-application-using-mentor-embedded-linux-on-amd-r-series-soc-with-qtechnology-cameras?cmpid=11407&clp=1
kbingham: <u>ribalda</u>: " You have already registered for this event." :D
ribalda: <u>hverkuil</u>: As you know prop->dims[] is set during v4l2_ctrl_new, and AFAIK cannot be changed afterwards
<br> <u>kbingham</u>: Sorry for wasting your Thursday evening :)
mchehab: <u>hverkuil</u>: fixed the email send hook for media_tree... the problem was actually simple: there's a logic that prevents sending emails when pulling back from Linus tree, with basically checks the committer's email...
<br> as I changed my e-mail, it was ignoring the commits
hverkuil: <u>mchehab</u>: re rcar-vin patches: that's my fault. I swapped the order of the "Use correct pad number in try_fmt" and "pad-aware driver initialisation" patches when making the pull request.
<br> I tested the end result, but not the intermediate steps.
<br> You want a new pull request?
<br> (and I get commit mails again, thanks!)
mchehab: yes, please
<br> always check intermediate steps, or I'll reject the pull request
<br> (or part of it)
hverkuil: posted pull request
mchehab: btw, you'll se a few extra e-mails about v4l2-ctrl.h: fix comments...
<br> that's me testing some changes at the hook
hverkuil: ah, I wondered about that.
mchehab: added a few error handlings there
<br> and warnings, when emails were not sent due to a different commiter than the one listed
pinchartl: <u>hverkuil</u>: do you have a minute ?
***: neg has quit IRC (Read error: Connection reset by peer)
hverkuil: <u>pinchartl</u>: not right now, I'm in a debugging sessions.
pinchartl: <u>hverkuil</u>: no worries, let me know when you'll have time
kbingham: is he doing that on purpose ?
<br> sorry - wrong channel :)
pinchartl: <u>kbingham</u>: if you're talking about the paragliding video, no, he's not :-)
***: benjiG has left
hverkuil: <u>mchehab</u>: there are two more patches in my cec-topic tree: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=cec-topic
<br> the last is the rc-cec module. I forgot to add that to my original pull request because I mistakingly through you had already merged it into the cec topic branch.
mchehab: well, send another pull request
hverkuil: ok
mchehab: my script gets only the patches you point, and checks the diffstat to see if the pull request matches with what it was actually received
hverkuil: OK, I suspected that was the case. I just hadn't gotten around to updating my pull request.
<br> <u>mchehab</u>: posted the pull request for the final two patches.
mchehab: <u>hverkuil</u>: I think I'll change the owner of the mediatek git pull request to you, while they don't solve the firmware issues
hverkuil: I was planning to ping Tiffany about this.
<br> So that's OK.
mchehab: to remove it from my queue, as every time I update the pull requests, I need manually edit my quilt series to remove it
<br> ok, thanks
hverkuil: I plan on going through the currently undelegated patches on Friday to pick what's relevant for me and review them/make pull requests.
mchehab: thanks, that would be great
hverkuil: My TODO list finally shrunk enough that I have time for that at last.
mchehab: feel free to pick other patches too, if you feel comfortable
<br> there are too many things there
<br> I'll try to handle the older patches during this week too
hverkuil: I'll see how it goes.
<br> Can you take a look at this patch for rc-main some time this week: https://patchwork.linuxtv.org/patch/34824/
mchehab: yeah, I saw it when you sent
<br> looks ok on my eyes
hverkuil: OK. Found it while doing the gitrmmod script to unload all media modules in combination with a cec-enabled vivid driver.
mchehab: I also need to pull one patch from Tony related to RC (that one I didn't review)
<br> for the n900
hverkuil: I'm very pleased that CEC is in. It was 6 years ago that the first RFC was written, so it is cool that it paid off!
<br> Thank you for all your review work.
mchehab: anytime
<br> sorry for not doing it earlier... too busy over here
hverkuil: same here, so I completely understand.
<br> But this is good timing for us (Cisco).
pinchartl: 2/window 19
<br> oops
headless: <u>pinchartl</u>: https://twitter.com/ThePracticalDev/status/747843812219813888 :-)
<br> nuit
kbingham: is there something that limits the number of buffers for a capture (or in particular an m2m-capture) queue to 2? I'm requesting 4 from both output and capture queues but always getting 2 on the capture. I don't think it's anything in my driver that is restricting to 2 ?
<br> well that was odd - I swapped the ordering and requested the capture first, and now I get 4 of each queue :)
<br> yup - and if I swap the ordering back - I'm back to getting 4 output : 2 capture buffers
pinchartl: <u>kbingham</u>: try to enable debugging in vb2
<br> there's a debug module parameter
kbingham: <u>pinchartl</u>: On it.
<br> <u>pinchartl</u>: Ha - well that was simple.
<br> <u>pinchartl</u>: fe940000.fdp1: dma_alloc_coherent of size 5234688 failed - Just odd that it works if the captures are first. Even though all the buffers are the same size :)