hi all!
Heippa!
hi all
hello
anything to be discussed this week?
Started work on incorporating the changes for the request API. I hope to finish that tomorrow or Monday.
hverkuil: I read them; they seem reasonable enough.
The intended changes, that is.
They are minor changes. Updating the documentation with pinchartl's review will likely take the most time.
I'd like to remind still that we need to be very careful about allowing setting controls while requests are queued.
That's why there is a warning in the spec. If you want to reword the warning it to make it even stronger then you can propose an alternative text.
I think it is sufficient myself.
Ack.
I've been still reworking the fwnode changes; Jacopo tested them earlier with a parallel bus device.
I also spend time on making the vicodec FWHT codec reusable in v4l2-ctl and qvidcap: it's now working.
hverkuil, mchehab: Thanks for reviewing the IPU3 documentation btw.
wrt request API changes, yeah, your conclusions seem reasonable
I prefer if ou do all changes to be applied after v18 patchset
The current video streaming code uses run-length encoding which is obviously really bad for 'real' video (as opposed to test patterns). With the fwht codec you can now stream 'normal' video as well.
mchehab: yes, that's the plan.
I really don't want to spin a v19 :-)
and I really don't want to review a v19 :-D
I hope I can finish this request API work soon and continue with the MC properties API.
hi all
hverkuil: can't you spin a final v19 by squashing all the small changes you make on top once they all get acked ? that would be a single respin, and would give us a clean history
pinchartl: I can, but only if mchehab agrees. I expect to see only a few small correction patches, I don't think it is worth the effort.
I suppose it depends how big the effort is :-)
pinchartl: I remember that you were working on refactoring (redesigning?) the omap4 DSS code. What is the status of that?
if rebasing and squashing creates lots of conflicts it's annoying, otherwise it only takes a few minutes
there are about a hundred patches queued for v4.20
and more to come
it takes a full day to review a v19
we're (too slowly) reaching the target
mchehab: the idea isn't to review a new version. all changes need to be approved independently, and then squashed before being merged
pinchartl: OK, so it is still not in, but it might go into 4.20?
you can diff v18 + fixes on top and v19 to make sure nothing got mangled in the process
if a v19 will be issued, we'll need to review everything again
I'd favour squashing the new changes as well.
mchehab: No need to review the entire set. I'd think seeing the diff is nil compared to v18 + fixes should be enough.
hverkuil: I expect part in v4.20 and part in v4.21
I'd trust the submitter on squashing the fixes to the right patches.
sailus: no, all patches should be reviewed again, as they will be applied one by one without causing build breakages
pinchartl: reason I ask is that CEC for omap5 is one of the few outstanding CEC projects, but it is probably easier to resume work on this once your code is merged.
mchehab: Reviewed or tested?
both
mchehab: if the only concern is build breakages, just run git rebase -x make and have a cup of coffee and tea :-)
hverkuil: have you started working on it ?
mchehab: if your concern is functional breakages (as you mentioned testing), then patches *should* be squashed
otherwise we end up with functional breekages in bisection
We know the resulting code is the same, so I wouldn't worry overly much about a potential of a fix going to the wrong patch. It'd be in the wrong place otherwise anyway.
So this is between having more or less all the fixes in the right place vs. having them all in the wrong place.
pinchartl: I have old code that almost worked (irq issues)
so in any case, while I see good reasons to develop incremental fixes on top, I don't see a reason not to then squash them
hverkuil: are you familiar with drm_bridge ?
well, if I receive a v19, I'll postpone it to when I have a full day available for review
pinchartl: let's use a private channel for this, it's not relevant to the media-maint discussion
non-incremental changes require a lot more time for reviewing than incremental ones
mchehab: that's why Hans proposed, and Sakari and I agreed, to develop the changes on top, and only squash them once everything has been finalized and acked
I'm not going to make a v19. That takes me too much time for no benefit. No-one is using the request API, so I am not concerned about any 'breakage' during bisect.
yes, there are no functional breakages for something that is not used yet
We're talking about 3 patches (one for documentation, two that change error codes). Not exactly earth shattering.
Squashing three patches takes too much time?
the argument goes in both directions :-)
but in any case
if you point me after the "---" line to what patch they're touching, I may fold when pulling
those incremental changes have to be reviewed as such
(no promises)
so let's focus on that first, and get the code ready
btw, in the specific case of the error code change, I do prefer to have it on a separate patch, anyway
as this will keep the history about why we decided to use that particular approach
hverkuil: Well, feel free to proceed either way, I just wanted to point out the benefits of doing that tiny bit of extra work.
mchehab: regardless of whether the patches are squashed, error codes should be explained in the documentation, including the rationale for which code are used when that is important for applications and/or drivers
sure, but mailing dist (and IRC) discussions are easy to forget after a while... a summary of the discussions don't belong to the documentation, but it can be written on a patch description
You could always put it into the patch description why a particular error code was chosen and another was not.
Anyway, I think we're beginning to attempt splitting hair here.
yes, but this don't belong into a big non-incremental patch
agreed. Next item for discussions?
I can't think of anything. Things should pick up again once 4.19-rc1 is merged.
yep
Once 4.19-rc1 is merged, will you make a topic branch at the same time for reqv18?
That would be nice.
I'll likely be doing at the same week
but I'll start next week with a trip to the office on Monday...
with could place some new items on my TODO list with a high priority
of not, my plan is to merge 4.19-rc1, start handling fixes request and create the topic branch next week
(on that order)
as usual, I should be handling the topic branch after pull request from you with Req-v18 patchset
(plus the extra patches to fullfill the latest review requests)
ok
im having a really bad track record.   meeting slipped my mind again, i am sorry
but some good news:  i booked my edigburgh trip and hotel and conf reg .  i will definitely see you all there
AND i have a new driver that i am working on :-)
mkrufky: your patch-merging track is also not ideal :-) If you have time, please check DVB patches sent by others and send me pull requests...
hverkuil just posted a trivial one
no problem, ive been away for months
will get on that