Hi all,
Here are the links to my presentations and below that the raw text of the etherpad.
A more polished version will be posted to the mailinglist eventually, but that's probably going to be Monday at the earliest. Unless someone else wants to do this?
My presentations:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-compliance-workshop-2012.o... http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-cec.odp
The etherpad text:
V4L2 Ambiguities
* Split off controls
OK, split them from videodev2.h to v4l2-controls.h
* Driver-specific controls
Should driver-specific controls have a unique CID, or can the CIDs overlap ?
Having all driver-specific controls in a single header file would probably be overkill. We can instead reserve a range of CIDs for each driver, and define the range base CID only in a common header file. Driver-specific CIDs themselves would be defined in driver-specific headers.
* STREAMON/STREAMOFF
STREAMON/STREAMOFF should return success (0) if the stream is already started/stopped.
* Unsupported formats in TRY_FMT/S_FMT
TRY_FMT/S_FMT should never return an error when the requested format is not supported. Drivers should always return a valid format, preferably a format that is as widely supported by applications as possible.
TRY_FMT and S_FMT should have the same behaviour. Drivers should not return different formats when getting the same input parameters.
The format returned should be a driver default format if possible (stateless behaviour) but can be stateful if needed.
* bus_info
bus_info should never be empty. The spec should specify the syntax of the field contents for common busses.
* V4L2_BUF_TYPE_PRIVATE
Not used, should be deprecated.
* Buftype checks against node type
The V4L2 core should check that ioctls it receives match the device node type they're received on. This is currently not done if a driver supports for instance both video and vbi on two different nodes. The core accepts both ioctls on both nodes, and several drivers don't perform the check themselves.
We first need to check whether this could break applications.
* Remove experimental tag
Remove the MEDIA_TUNER_TEA5761 driver. Too soon for VIDEO_OMAP3, to be decided for VIDEO_NOON010PC30 (ask Sylwester). Remove the experimental tag from other listed drivers.
With regards to VIDEO_NOON010PC30, it was marked as experimental only because it used VIDEO_V4L2_SUBDEV_API, which in turn depends on EXPERIMENTAL. Otherwise it's pretty standard and simple sensor driver. Hence the experimental tag could probably just be removed.
Remove experimental tag from listed ioctls.
* Wrong timings API use for input
Return an error. EINVAL is not a good error code, ENODATA is a better possibility.
* New defines for DV timing API
Add defines for V4L2_IN_CAP_TIMINGS and V4L2_OUT_CAP_TIMINGS, turn V4L2_(IN| OUT)_CAP_CUSTOM_TIMINGS into aliases for V4L2_(IN|OUT)_CAP_TIMINGS and deprecate V4L2_(IN|OUT)_CAP_CUSTOM_TIMINGS.
* Sequence and timestamp for output
For capture and output, the behaviour is OK, the documentation should be clarified.
For mem2mem, we need to specify the behaviour. Timestamp are not needed, but we need a way to match buffers on both sides, as the codec can reorder them. An RFC should be sent to the list.
* Const arg for write-only ioctls
Yes.
* How to set the timestamp ?
We should use ktime_get_ts. Change the spec, and require all drivers to be fixed. A new driver capability flag is needed to tell applications that the driver uses the monotonic clock.
* Device specified clock
Reuse v4l2_timecode to pass the device clock timestamp to userspace (making it an anonymous union is an option, as it would allow different kind of timestamps later) and add a capability flag to inform applications.
* V4L2_CAP_VIDEO_CAPTURE
No and no.
* V4L2_CROPCAP
The ioctls should not be mandatory if the driver doesn't support crop or scale.
* Pixel aspect ratio
TBD on the mailing list.
* Tuner ownership
TBD on the mailing list (or later this week).
V4L2 Compliance
Automated tool to test whether a driver complies with the spec.
Requirements: * G/S_PRIORITY * Normal and extended controls * Control events * videobuf2 (or an own video buffers implementation that is spec-compliant, videobuf1 isn"t)
Passing v4l2-compliance tests will be compulsory for new drivers.
Require that new tests are added wheenver a new API appears.
The V4L2 streaming profile needs to be implemented to support complex MC drivers in v4l2-compliance.
ALSA+V4L2
a) Compressed audio (ivtv, pvrusb2)
Compressed audio format support for ALSA will be supported in 3.7. Patch to add support in driver: http://git.kernel.org/?p=linux/kernel/git/broonie/sound.git;a=commit;h=c514a... But no userspace ALSA library support yet. It is currently on a separate library. tinycompress: http://git.alsa-project.org/?p=tinycompress.git;a=summary Vinod Koul - vinod.koul@linux.intel.com - is working with the userspace library
Kernelspace: git.kernel.org, at linux/kernel/git/broonie/sound.git
Header for kernel API include/sounds/compress_params.h include/sounds/compress_offload.h
b) timestamps
Userspace needs to sync audio and video. V4L2 has timestamps already. PCM_STATUS: current position, system time. There is no device timestamp.
When capture starts the audio can start later than video. We can calculate this delay. Perhaps we can use this to set the initial timestamp of the start of the audio.
But when changing inputs the audio can cut off while the input change is in progress, so there need to be a way to resync the audio timestamp.
The compressed audio API has a timestamp already.
c) usage of media API by ALSA
There will be some discussions about that theme at LPC, on Wednesday 11:40, at Nautilus 2 room: http://summit.linuxplumbersconf.org/lpc-2012/meeting/80/lpc2012-audio-routin...
Preliminary ALSA RFC patches: http://comments.gmane.org/gmane.linux.alsa.devel/100537
SoC Vendor Feedback
TI: trying to get in touch with omap4/5 devs to see if we can help out. A poor design makes V4L2 impossible at the moment. Laurent will try to contact a few buffer.
Question about zero-copy pipelining. Can be done with dmabuf. See this patch series:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg50525.html
dmabuf documentation in the kernel:
Documentation/dma-buf-sharing.txt
Script to generate a large patch to update drivers/media from an older kernel to the latest code:
http://git.linuxtv.org/hverkuil/cisco_build.git/blob_plain/cobalt- mainline:/patch-kernel.sh
ST-Ericsson: Media Controller API: should be unified for V4L2 and ALSA. Did work on Media Controller connector entities.
V4L2/DVB issues from userspace perspective
Versioning: recommended method is to just copy videodev2.h.
libv4l: needs to be released more often: distros will not upgrade unless a new release is made. The current is very old.
Controls: which are relevant for userspace and which aren't? Profile driven?
libv4l2: doesn't support userptr.
Raise questions about this with the linux-media mailinglist and with a CC to Hans de Goede.
CEC
We need a new CEC bus (similar to I2C) with an in-kernel API and a userspace API exposed by the core (device or socket API ?)
MC Library
Media Device Discovery Library: work-in-progress. Enumerates media devices, then v4l2 etc.nodes. Uses libudev or sysfs as fallback.
Android V4L2 Cam Library
HAL library on top of V4L2. Preview, still images, capture works.
Regards,
Hans
Em 28-08-2012 21:15, Hans Verkuil escreveu:
Hi all,
Here are the links to my presentations and below that the raw text of the etherpad.
A more polished version will be posted to the mailinglist eventually, but that's probably going to be Monday at the earliest. Unless someone else wants to do this?
I'll be doing it. It helps a lot if everyone that did presentations there could send me a their presentations (or a link for them).
I'll be submitting later (likely today) it later today to the main KS/2012 ML, to this ML and to lwn.net (as they politely request for it, as, unfortunately, they couldn't be covering our track this year).
Btw, I did a summary covering the most controversial topics for today's presentation at KS/2012 mini-summit reports, at: http://linuxtv.org/downloads/presentations/media_ws_2012/ks_workshop_ks_summ...
My presentations:
http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-compliance-workshop-2012.o... http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-cec.odp
Uploaded them to http://linuxtv.org/downloads/presentations/media_ws_2012/.
I still need to make this tree visible there, and add some announcements with the results. I'll do that after finishing the event's summary.
Regards, Mauro
Em 28-08-2012 21:15, Hans Verkuil escreveu:
Hi all,
Here are the links to my presentations and below that the raw text of the etherpad.
A more polished version will be posted to the mailinglist eventually, but that's probably going to be Monday at the earliest. Unless someone else wants to do this?
I'm reviewing the etherpad stuff, hoping to be able to release it today.
Yet, with regards to this item:
V4L2_CAP_VIDEO_CAPTURE If a driver supports only formats with more than one plane, should V4L2_CAP_VIDEO_CAPTURE still be defined? And if a driver also supports single-plane formats in addition to >1 plane formats, should V4L2_CAP_VIDEO_CAPTURE be compulsary? The consensus seems to be 'No' and 'No'. The CAPs refer to whether the single and/or multiplanar API is implemented, not whether single and/or multiplanar formats are available.
The etherpad note said "No and No", but I think it should be saying, instead: "Flags should reflect what it is visible/usable by the userspace API."
I remember that, when those patches got merged, there was a discussion about having a kernel code that simulates a monoplane API. As it was a looong time ago, I'm not 100% sure anymore what happened with that code, but I think it ended by being merged at v4l-utils.
If so, that means that the s5p drivers should not return V4L2_CAP_VIDEO_CAPTURE flags, but the v4l-utils library should return it, due to the emulation logic there.
In other words, fixing the driver to do the right thing also means that the library should be patched to properly report that library clients can use both MPLANE an monoplane variations.
Regards, Mauro
-
Hans Verkuil -
Mauro Carvalho Chehab