On 11/14/2018 09:09 AM, Tomasz Figa wrote: > Hi Hans, > > On Fri, Aug 3, 2018 at 11:36 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >> >> From: Hans Verkuil <hans.verkuil@xxxxxxxxx> >> >> This RFC patch series implements properties for the media controller. >> >> This is not finished, but I wanted to post this so people can discuss >> this further. >> >> No documentation yet (too early for that). >> >> An updated v4l2-ctl and v4l2-compliance that can report properties >> is available here: >> >> https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=props >> >> There is one main missing piece: currently the properties are effectively >> laid out in random order. My plan is to change that so they are grouped >> by object type and object owner. So first all properties for each entity, >> then for each pad, etc. I started to work on that, but it's a bit more >> work than expected and I wanted to post this before the weekend. >> >> While it is possible to have nested properties, this is not currently >> implemented. Only properties for entities and pads are supported in this >> code, but that's easy to extend to interfaces and links. >> >> I'm not sure about the G_TOPOLOGY ioctl handling: I went with the quickest >> option by renaming the old ioctl and adding a new one with property support. >> >> I think this needs to change (at the very least the old and new should >> share the same ioctl NR), but that's something for the future. >> >> Currently I support u64, s64 and const char * property types. But it >> can be anything including binary data if needed. No array support (as we >> have for controls), but there are enough reserved fields in media_v2_prop >> to add this if needed. >> >> I added properties for entities and pads to vimc, so I could test this. > > I think I'm missing the background and the description doesn't mention > it either. What's the use case for those and why not controls? Properties provide additional information about graph objects: main initial use-case is to give camera information: back/front, upside down, and whatever else Sakari can come up with :-) Also we want to use this to describe all the functions that an entity supports (right now you can describe only one function, but there are multi-function devices out there). Other use-cases are for connectors (but these are not yet modeled by the MC): name and/or color on the backplane. I forgot what the pad properties where needed for, I would have to dig. It is something Mauro wanted to use for either DVB or TV capture drivers to provide additional information about the type of data flowing through a pad. This is all information that most likely will come from the device tree. All this is read-only information. And yes, these properties will all have to be documented since they are part of the ABI. Regards, Hans
