On 03/14/2016 11:28 AM, Mauro Carvalho Chehab wrote:

Em Mon, 14 Mar 2016 14:41:16 +0100 Hans Verkuil hverkuil@xs4all.nl escreveu:

...

I have these topics:

• Continue MC connector entity discussion

Although I'm not working on it, I think we should also discuss:

• support for dynamic removal/addition at the core and MC locking.
• properties API (assuming that Sakari would join us and/or has something ready for discussions).

...

• CEC status update (to be confirmed)
• A short demo of the qdisp utility I am working on

Laurent, would it make sense to discuss your work on the request API?

Another possible topic:

media-ctl vs mc_nextgen_test: having two utilities makes me very unhappy!

I think we have a fairly small group this time, so I am not sure if we need a full fledged agenda. If the group will be larger than expected, then please let me know and I will prepare a proper agenda.

Even with a small group of people, we need to have an agenda, as others might be interested. I suspect that we'll still have ~10 people there.

Please add

Fix media_device broken alloc/remove (devres and non-devres)

Kernel crashes when device is removed when media devnode is open and an ioctl is in progress. I submitted a selftest to reproduce the problem. I am working on a solution and would like to discuss it.

thanks, -- Shuah

---

media-workshop mailing list media-workshop@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop

Hi Mauro,

On Mon, Mar 14, 2016 at 02:28:51PM -0300, Mauro Carvalho Chehab wrote:

Em Mon, 14 Mar 2016 14:41:16 +0100 Hans Verkuil hverkuil@xs4all.nl escreveu:

...

I have these topics:

• Continue MC connector entity discussion

Although I'm not working on it, I think we should also discuss:

• support for dynamic removal/addition at the core and MC locking.
• properties API (assuming that Sakari would join us and/or has something ready for discussions).

As much as I would have liked to join, I think I won't be able to be there this time. I'll most likely be in ELC-E though.

Hi Mauro,

On 03/14/2016 06:28 PM, Mauro Carvalho Chehab wrote:

Em Mon, 14 Mar 2016 14:41:16 +0100 Hans Verkuil hverkuil@xs4all.nl escreveu:

...

I have these topics:

• Continue MC connector entity discussion

Although I'm not working on it, I think we should also discuss:

• support for dynamic removal/addition at the core and MC locking.

Are these two topics (dynamic removal/addition AND MC locking) or one (MC locking in the context of dynamic removal/addition)? I think it is one topic, right?

Regards,

Hans

• properties API (assuming that Sakari would join us and/or has something ready for discussions).

...

• CEC status update (to be confirmed)
• A short demo of the qdisp utility I am working on

Laurent, would it make sense to discuss your work on the request API?

Another possible topic:

media-ctl vs mc_nextgen_test: having two utilities makes me very unhappy!

I think we have a fairly small group this time, so I am not sure if we need a full fledged agenda. If the group will be larger than expected, then please let me know and I will prepare a proper agenda.

Even with a small group of people, we need to have an agenda, as others might be interested. I suspect that we'll still have ~10 people there.

Regards, Mauro

Hi Guennadi,

On Friday 18 March 2016 13:39:01 Guennadi Liakhovetski wrote:

On Mon, 14 Mar 2016, Hans Verkuil wrote:

...

I have these topics:

• Continue MC connector entity discussion
• CEC status update (to be confirmed)
• A short demo of the qdisp utility I am working on

Laurent, would it make sense to discuss your work on the request API?

Another possible topic:

media-ctl vs mc_nextgen_test: having two utilities makes me very unhappy!

As mentioned before, I'd also like to discuss stream multiplexing in V4L2 / MC context. I'll (most likely manage to) prepare a couple of slides to show ouw set up and the currently implemented solution and would like to hear opinions on whether that's the approach we'd like to use for this and similar configurations or whether we want something different.

I'm sure that Sakari will want to chime in on this. Could you submit your slides a few days before the meeting (ideally a week) to make sure he will have time to comment on them ?

...

I think we have a fairly small group this time, so I am not sure if we need a full fledged agenda. If the group will be larger than expected, then please let me know and I will prepare a proper agenda.

Em Tue, 22 Mar 2016 10:55:38 +0100 Hans Verkuil hverkuil@xs4all.nl escreveu:

On 03/22/16 10:47, Laurent Pinchart wrote:

...

Hi Hans,

Magnus, Morimoto-san and Niklas (CC'ed), all working on multimedia for Renesas, would like to attend the workshop on Thursday. Would that be possible ?

Fine by me, but Mauro is in charge of the room & invites. I just do the agenda (I plan to post the first draft Tuesday next week).

Added Mauro to this.

Sorry for taking so long to answer. This e-mail got missed on my inbox. Only noticed today, when I was reviewing the workshop-related threads.

It is fine to have them on the workshop.

Magnus, Morimoto-san and Niklas,

Be welcomed!

Regards, Mauro

On 03/28/2016 08:38 PM, Mauro Carvalho Chehab wrote:

Em Tue, 22 Mar 2016 10:55:38 +0100 Hans Verkuil hverkuil@xs4all.nl escreveu:

...

On 03/22/16 10:47, Laurent Pinchart wrote:

...

Hi Hans,

Magnus, Morimoto-san and Niklas (CC'ed), all working on multimedia for Renesas, would like to attend the workshop on Thursday. Would that be possible ?

Fine by me, but Mauro is in charge of the room & invites. I just do the agenda (I plan to post the first draft Tuesday next week).

Hans,

Do you have already an agenda?

I'll prepare & post the first draft tomorrow.

Regards,

Hans

Em Tue, 29 Mar 2016 10:07:24 +0200 Hans Verkuil hverkuil@xs4all.nl escreveu:

I am adding one more topic:

linux-media development process discussion

Yeah, we should discuss ways to improve the process. Actually, this is a topic that we try to discuss on every year during the media summits, as there are always space for improvements.

Tempers have been a bit frayed recently about the way patches are reviewed and processed. We should take the opportunity of being in the same room to discuss this and see how the process can be improved.

We've always been a highly professional group of core developers, so I think it is important to address the issues that cropped up recently.

In my analysis (feel free to disagree) the core problem is what to do when important patch series get little or no review due to lack of time on the side of reviewers. I don't have any easy solutions, but perhaps it could be a mix of requiring at least one non-author sign-off from core devs for such patches, and somehow identifying the crucial patches. A review isn't normally necessary for general churn that does not impact functionality, so a way of filtering those out when reviewing might be helpful. Or explicitly asking for reviews for specific patches.

While we always wanted to have reviewers at the community, this has been a long time issue.

That's, by the way, one of the goals by having sub-maintainers were to have at least two pairs of eyes reviewing patches.

What it was agreed when we set up such model is that sub-maintainers would be reviewing the drivers from their own area and that patches affecting the core would be reviewed by the group of sub-maintainers that have expertise on that part of the core.

The original goal were to have sub-maintainers for all parts of media subsystem, like: - V4L2 driver's code; - V4L2 codecs; - Media Controller; - Webcams; - Remote Controller (RC); - DVB.

However, we never found anyone that would willing to sub-maintain RC, and sub-maintainership didn't work well for DVB.

On V4L2 side, it worked well for a while, but nowadays I'm only receiving regular pull requests from you. So, I'm assuming that the other sub-maintainers are at the -EBUSY state.

I really want extra pairs of eyes on patches, specially on core ones, but it should be something that would work well, for the cases where reviewers are rare or don't have time.

In the case of the MC work being done recently the problem is that Laurent is in a permanent state of -ENOTIME, and I have had almost no time as well during the last 4-5 months. It looks like that will change for me, so I hope to have more time very soon.

A smaller practical issue I have has been the policy of avoiding posting large patch series due to concerns of flooding of the mailinglist. I found that that made my life as reviewer much harder.

There's actually some other concerns:

- The patchbomb script at the server is programmed to not handle pushes with more than a certain number of patches. I don't remember the exact amount that is set on each tree, but it is around 50 patches or so. This is to avoid patchbomb duplicated patches when we merge back from upstream.

- when there's a problem on a very long patch series and this gets rejected, the entire series may need to be rejected;

- In the case of such rejections, we'll have another huge patchbomb series;

- Doing reviews on a very long patch series is not fun; developers need to reserve a large amount of time to review the thing;

- It is specially depressing for reviewers when they need to dig on those large patch series for more than 2/3 interactions. However, those long series usually take 10+ reviews... because the probability of having (usually minor) troubles increase exponentially with the number of patches.

IMHO this is a mailinglist for developers and as such flooding is no issue for me. Ease of reviewing trumps that any time. It's not as if this happens every day.

It is not an issue to me, but it is an issue for non-developers. Even developers complain if you send a huge patch series (and then keep re-sending it periodically until make everyone happy).

Things are now worse than before, because now we're usually sending the patch series also to other ML and other people, due to check-maintainers script.

So, I can't think on a better alternative for that.

In any case, IMHO, this specific issue should be discussed via the ML, as any changes at the ML policies and/or the split of it into smaller MLs will affect everybody that subscribes it.