Re: MEDIA_IOC_G_TOPOLOGY and pad indices

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Hans,

On Sunday, 4 February 2018 15:16:26 EET Hans Verkuil wrote:
> On 02/04/2018 02:13 PM, Laurent Pinchart wrote:
> > On Sunday, 4 February 2018 15:06:42 EET Hans Verkuil wrote:
> >> Hi Mauro,
> >> 
> >> I'm working on adding proper compliance tests for the MC but I think
> >> something is missing in the G_TOPOLOGY ioctl w.r.t. pads.
> >> 
> >> In several v4l-subdev ioctls you need to pass the pad. There the pad is
> >> an index for the corresponding entity. I.e. an entity has 3 pads, so the
> >> pad argument is [0-2].
> >> 
> >> The G_TOPOLOGY ioctl returns a pad ID, which is > 0x01000000. I can't use
> >> that in the v4l-subdev ioctls, so how do I translate that to a pad index
> >> in my application?
> >> 
> >> It seems to be a missing feature in the API. I assume this information is
> >> available in the core, so then I would add a field to struct media_v2_pad
> >> with the pad index for the entity.
> >> 
> >> Next time we add new public API features I want to see compliance tests
> >> before accepting it. It's much too easy to overlook something, either in
> >> the design or in a driver or in the documentation, so this is really,
> >> really needed IMHO.
> > 
> > I agree with you, and would even like to go one step beyond by requiring
> > an implementation in a real use case, not just in a compliance or test
> > tool.
> > 
> > On the topic of the G_TOPOLOGY API, it's pretty clear it was merged too
> > hastily. We could try to fix it, but given all the issues we haven't
> > solved yet, I believe a new version of the API would be better.
> 
> It's actually not too bad as an API speaking as an end-user. It's simple and
> efficient. But this pad issue is a real problem.

We have other issues such as connector support and entities function vs. types 
that we have never solved. The G_TOPOLOGY ioctl moves in the right direction 
but has clearly been merged too early. It might be possible to fix it, I 
haven't checked yet, but I really don't want to see this mistake being 
repeated in the future.

-- 
Regards,

Laurent Pinchart