<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   Kwiboo: I only runtime tested with correct SPS ctrl and pixelformat so I still need to verify the enforcing part :-)
   tfiga: <u>Kwiboo</u>: I think there are some nice bits there, but sadly the behavior isn't exactly V4L2-compliant
   <br> 1) controls always have some values, so even if the userspace doesn't set them, ENUM_FMT needs to obey their values
   <br> 2) and same for TRY_FMT
   <br> so basically, after opening, the context needs to have some valid_fmt assigned and both ioctls should just match to that
   <br> +/- some specific comments about the code, but possibly that should be posted directly on the lists
   <br> also AFAICT the hardware can support the CrCb variants of the formats
   <br> so there might be a need to allow selecting between the two
   <br> which makes me think that the lookup should be done in the format array
   pinchartl: <u>tfiga</u>: speaking of TRY_FMT, how is it supposed to work for M2M devices ?
   <br> does TRY_FMT on the capture side need to take into account the active format on the output side ?
   <br> the V4L2 spec says nothing about that
   <br> I suppose it should, but tha's very annoying
   <br> it would prevent querying alignment constraints on the capture side without modifying the output side
   <br> I have a use case where I want to know, for a given capture resolution, what bytesperline and sizeimage values will be generated
   <br> and the device may be running at that point, so I don't want to set the format on that output side in order to call TRY_FMT on the capture side
   Kwiboo: the stateless spec state the following for ENUM_FMT of CAPTURE: The driver will return only formats supported for the currently selected OUTPUT format and currently set controls
   <br> so that is what I try to implement, return any of the possible CAPTURE pixel formats for the currently selected OUTPUT format and currently set controls
   <br> the driver can only know the valid/possible CAPTURE format once the SPS control is set
   <br> <u>tfiga</u>: regarding CrCb I think there are flags for swap CbCr in both vpu/vop blocks, so technically there can be more than one valid CAPTURE format, but that is not something I plan to look into, just getting one of them working is good enough for me :-)
   ezequielg: <u>pinchartl</u>: when you say "for M2M devices", what do you mean?
   <br> (of course, I know what it means, but we have device-specific API specification, so what is exactly your use case?)
   <br> and can't you query the alignment constraints before the device is running/streaming?
   <br> <u>Kwiboo</u>: if you don't mind pasting that diff on the mailing list, it would be easier to give some feedback directly there.
   Kwiboo: <u>ezequielg</u>: sure, I will send a v2 including that diff once I have completed some more testing
   gnurou: <u>pinchartl</u>: you can always open the device a second time and perform the queries on that new context, but maybe that's a bit overkill
   tfiga: note that there is *a selected OUTPUT format* already after opening the video node
   <br> also note that ENUM_FRAMESIZES is there and it doesn't respect that
   <br> so I suppose that should be your way to know the alignments
   <br> because ENUM_FRAMESIZES doesn't operate on a specific queue, but rather on a fourcc
   <br> But of course it isn't perfect and v4l2 relies a lot of runtime negotiation, so things can't be always queried...
   <br> <u>Kwiboo</u>: not asking you to add those formats, but it would be generally a more scalable design if the formats weren't hardcoded in the if/else cases.
   ezequielg: <u>tfiga</u>: hverkuil: BTW, I'm working on a v2 for the uapi cleanup rfc. Right now, I'm still hesitant as it seems we might need more DPB entry flags. I want to make sure it's only flags we are missing, and not something else.
   <br> <u>tfiga</u>: gnurou: if you guys find some time to take a look at the uapi rfc series, i'd appreciate your input.
   ***: fling has quit IRC (Ping timeout: 240 seconds)
   tfiga: <u>ezequielg</u>: I have it on my list, but need to dig out of some other stuff...