Javier Martinez Canillas <javierm@xxxxxxxxxx> writes: Hello Stanimir and Dikshita, > Jordan Crouse <jorcrous@xxxxxxxxxx> writes: > >> On Tue, Mar 07, 2023 at 05:20:18PM +0100, Enric Balletbo i Serra wrote: > > [...] > >>> > >>> > But regardless, I think that it would be better for a driver to >>> > not change the order of advertised VIDIOC_ENUM_FMT pixel formats. >>> > >>> > Because what happens now is that a decoding that was previously >>> > working by default is not working anymore due a combination of >>> > the default being changed and S_FMT not working as expected. >> >> For my part, I was using the gstreamer v4l2 decoder which for some reason tries >> to verify it can support whatever format it gets with G_FMT *before* >> trying a S_FMT. I can't confirm or deny if S_FMT currently works or not. >> >> That said, I entirely agree with Javier. While it might be more >> bandwidth efficient, QC08C is a obscure format. It is far more likely that the >> average open source user would rather use a well known output format and, as >> has been mentioned, once S_FMT is fixed those in the know can use the other >> formats if they are working with other Qualcomm hardware blocks. >> > > Agreed. The rule is that the kernel shouldn't regress user-space and the > patches that changed the default format certainly did that. So from that > point of view I think that this patch should land. > > There's also Enric's point that NV12 is a more common format and supported > by more user-space programs. That's why think that regardless of the S_FMT > situation, makes sense to revert to the previous default behaviour. > Any news on this patch? It would be great to fix this at least for v6.3. -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
