Hi Hans & others, Sorry, only today I had time to dig into the Barcelona's media summit report. I have a few comments for it below. Regards, Mauro Em Fri, 16 Nov 2012 13:58:54 +0100 Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > Hi all, > > This is the report of the Barcelona Media Summit on November 8. For those who > were in attendence: please correct any mistakes I may have made. > > My presentation for the 'Minimum Requirements for New Drivers' and the 'V4L2 > Ambiguities' can be found here: > > http://hverkuil.home.xs4all.nl/presentations/ambiguities2.odp > > I'd appreciate it if other presentations shown during the meeting can be made > available as well. > > Enjoy! > > Hans > > Merging Process > =============== > > The morning was spent discussing the merging process. Basically the number of > patch submissions increased from 200 a month two years ago to 700 a month this > year. Mauro is unable to keep up with that flood and a solution needed to be > found. > > Mauro explained the current merge process, and after that the floor was opened > for discussions. > > One of the problems is that it can be difficult to categorize patches since > often they are just prefixed with [PATCH]. Depending on who mailed it that > might mean an urgent regression fix, a patch that's ready to be merged or a > patch that needs review. There is no reliable way of knowing that without > actually looking at the mail. > > One thing that we want to improve is to make sure that the regular contributors > at least use well defined patch prefixes. That means that we need a standard > prefix for regression fixes that need to go into the current rcX kernel asap. > This will make it easy to recognize them. We also need a prefix for patches that > we want to have reviewed before a final git pull request is posted. > Laurent will look into extending patchwork to have such patches be marked as > 'Under Review' automatically. Actually, 'Under Review' patchwork tag is used just to indicate that a patch got delegated to someone's queue, not that such patch is more critical. What it was agreed, instead, is that: "Laurent will work into extending patchwork to delegate patches to sub-maintainers when they arrive there." By splitting the patch when it arrives to the sub-maintainers trees, the time from when it arrives to when it starts to be seen by the delegated people reduces a lot. > There is a distinction between RFC patches and patches you consider final (i.e. > ready for merging), but want people to look at. RFC patches will typically need > more work, but you want people to check it out and make sure you are going in > the right direction. Review patches are what you consider the final version, but > you want to give people a final chance to comment on them before posting the pull > request. > > We also want to improve the MAINTAINERS file: it must be complete (with the > exception of RC keymaps, and the RC/V4L2/DVB core > where that doesn't make sense). > When posting review > patches the reviewed-by/acked-by from the actual person mentioned in the > MAINTAINERS file is sufficient to get the patch merged. It is not a sufficient requirement: it should still follow the submission rules, use the right API, doesn't reinvent the wheel, doesn't create private APIs, etc. I think you meant to say, instead: "A patch reviewed-by/acked-by from the actual person mentioned in the MAINTAINERS file and that follows the submission rules can be considered with enough review for its merge." > Obviously, if someone > not responsible for the driver in question has good technical arguments why > it's wrong, then that should be taken into account. > > In addition, the current list of media driver maintainers in that file needs > to be validated: are all emails still current, and is everyone still willing > to maintain their driver? > > New drivers also must come with a MAINTAINERS entry. > > In other words, the MAINTAINERS file will become more important. > > The final decision we made was to appoint submaintainers of parts of the media > subsystem. Those submaintainers will take over Mauro's job for those parts > that they are responsible for, and make periodic pull requests to Mauro to > pull in the patches they have collected. I'll still be analyzing the patches, as a double-review doesn't hurt. > > The submaintainers will be: > > - Mike Krufky: frontends/tuners/demodulators > In addition he'll be the reviewer for DVB core patches. As I commented before: s/the reviewer/a reviewer/ > - Hans Verkuil: V4L2 drivers and video A/D and D/A subdev drivers (aka video > receivers and transmitters). In addition he'll be the reviewer for > V4L2 core patches. As I commented before: s/the reviewer/a reviewer/ On both cases, we do want more reviewers for the core. > - Laurent Pinchart: sensor subdev drivers > - Kamil Debski: codec (aka memory-to-memory) drivers > - Hans de Goede: non-UVC USB webcam drivers > - Guennadi Liakhovetski: soc-camera drivers > > In addition, certain SoC vendors will remain responsible for their own drivers > (Samsung, TI) and will keep sending them straight to Mauro. > > The first step is to get the MAINTAINERS file into shape and to improve > patchwork, after that we need to clearly document the new structure. > Only when that is done do the new submaintainers start their work. That's not a mandatory requirement. Btw, Michael already started sub-maintaining. We decided to postpone the switch over to Jan/Feb 2013 much more due to practical reasons: most people had lots of things to finish by the end of the year, and some would take vacations at the beginning of 2013. Also, patchwork/MAINTAINERS change helps to make sub-maintainers' life easier. I expect that it will take maybe 2-3 months before we have it fully working as we would like, after having the patchwork delegation fixed. > Requirements for New V4L2 Drivers > ================================= > > The next topic was to document the requirements for new drivers. > > For the staging tree we want drivers to compile at the time of submission. > That is all it should take to be accepted into staging. The wording "That is all" is very dangerous, as it doesn't allow any exception. I would say, instead: "Typically, that is all it should take to be accepted into staging." While this wasn't discussed there, "compile" also means no compilation warnings at the time of submission ;) Due to our recent experiences with one submission for staging, I'd say that a driver submitted for staging is a driver that are meant to be promoted one day as a main driver, and someone will actively work on them. So, drivers that can't be promoted to a main driver won't be merged at staging (e. g. drivers for already supported hardware, utterly bogus drivers, ...). In other words, (sub)maintainers should use their good sense and can/should reject drivers for staging according to their criteria. > For inclusion into the mainline kernel we require the following: It should say, instead: "For inclusion of pure V4L2 drivers into the mainline kernel we require the following:" > > - Use struct v4l2_device for bridge drivers, use struct v4l2_subdev for > sub-device drivers. > - Use the control framework for control handling. > - Use struct v4l2_fh if the driver supports events (implied by the use of > controls) or priority handling. > - Use videobuf2 for buffer handling. Mike Krufky will look into extending > vb2 to support DVB buffers. > - Must pass the v4l2-compliance tests. Please add: "The criteria for DVB and hybrid V4L2 and DVB drivers should be discussed further at the ML." > > This will be documented as well in Documentation/video4linux/SubmittingDrivers.txt. > > > V4L2 Ambiguities > ================ > > In San Diego we discussed a lot of V4L2 ambiguities and how to resolve them, > but we didn't have time to go through all of them. We finished it in Barcelona. > > - What to do if the colorspace is unknown? This happens with UVC webcams that > do not report this. The decision was to make a V4L2_COLORSPACE_UNKNOWN. If > that is reported, then no colorspace conversion should be attempted by the > application. > > - Pixel Aspect Ratio: currently this is only available from VIDIOC_CROPCAP, > which conflicts with the new selection API, and it doesn't really belong > there anyway. > > The decision was to implement the pixel aspect ratio as a control, which > implies adding a control type for fractions. This needs good documentation > and a code example. > > - Should we add a QUERYCAP ioctl for subdevice nodes? The conclusion was that > we should add a VIDIOC_SUBDEV_QUERYCAP ioctl. Initially that just needs a > version field and some reserved fields and it can be handled in v4l2-subdev.c. > > - Tuner ownership: how should the tuner ownership be handled? The proposal > I wrote for this was accepted, with the addition that the code to handle > tuner ownership should be shared between DVB and V4L2. I have my name > and Hans de Goede's name next to this topic, but I've forgotten what we > were supposed to do :-) > > > Transport Stream Muxer > ====================== > > ST discussed how to design a driver for a hardware Transport Stream Muxer: > this hardware contains a number of DMA engines allowing many transport streams > (up to 8192, which is the theoretical maximum) to be muxed into a single big > transport stream. > > Due to the large number of possible transport streams one cannot make a video > node for each of them. So the solution is to have one memory-to-memory device. > Every time it is opened you make a new context (filehandle specific) and after > setting up the PID (and possibly other (meta) data) you can write the TS to it. > There is only one output stream, though. Perhaps we need a new /dev/tsmuxX > device node for this, that's still to be decided. > > ST will make an RFC for this idea to discuss this further on the mailinglist. > > > DMABUF Testing > ============== > > Progress had been made on this: Laurent showed UVC using DMABUF passing the buffer > directly to the i915 GPU. > > > Asynchronous Loading for Device Tree > ==================================== > > The device tree patches posted by Guennadi were well received, but the part > dealing with async loading of devices led to a lot of discussion on the > mailinglist so we tried to come to a conclusion during the summit meeting. > > The current patch uses a field in the platform_data of a subdevice to detect > whether the bridge driver was present. A better solution is to check for the > presence of required resources (e.g. a clock) instead: if not present, then > defer probing. > > It was noted that the asynchronous behavior of the device tree will lead to > subdevices that are loaded in a random order. This might cause subtle problems > in the future if the order of device initialization matters for certain boards. > It shouldn't matter, but theory and reality are different things. There is > nothing that can be done about it at the moment. Should this become a problem, > then that should be discussed with the DT developers since this is a DT problem > and is not specific to V4L2. > > The 'group' idea in the async loading patches wasn't liked. Instead the suggestion > was to provide two different notification methods: a notification when the last > required subdev is loaded, and a notification for each loaded subdev. The latter > can be used when not all subdevs might be present. In that case the bridge driver > needs to be able to decide when sufficient subdevs were found in order to start up. > > > Conclusion > ========== > > We managed to get through all topics during this one-day summit, so it was very > productive. I'd like to thank all who were there, it's always a pleasure to meet > you all! > > Regards, > > Hans Verkuil > > _______________________________________________ > media-workshop mailing list > media-workshop@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/media-workshop -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
