Hi Laurent, On 07/30/2012 09:06 PM, Laurent Pinchart wrote: >>>> - bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> >>>> + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with > no >>>> + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC >>>> formats. + </para></listitem> >>>> >>>> <listitem><para>The number of bits per pixel component. All > components >>>> are >>>> transferred on the same number of bits. Common values are 8, 10 and >>>> 12.</para> </listitem> >>> >>> I dicussed dummy vs. padding (zeros) with Laurent and we concluded we >>> should use zero padding instead. The difference is that when processing >>> the pixels no extra operations are necessary to get rid of the dummy data >>> when the dummy bits are actually zero --- which in practice always is the >>> case. >>> >>> I'm not aware of hardware that would assign padding bits (in this very >>> purpose) that are a part of writes the width of bus width something else >>> than zeros. It wouldn't make much sense either. >>> >>> So I suggest that dummy is replaced by padding which is defined to be >>> zero. >>> >>> The letter in the format name could be 'Z', for example. >>> >>> Hans: what do you think? >> >> Bad idea. First of all, some hardware or FPGA can insert different values >> there. It's something that Cisco uses in some cases: it makes it easier to >> identify the dummy values if they have a non-zero fixed value. >> >> Another reason for not doing this is when such formats are used to display >> video: you don't want to force the software to fill in the dummy values >> with a specific value for no good reason. That would only cost extra CPU >> cycles. > > On the other hand, when you process data that includes dummy bits stored in > memory, knowing that the dummy bits are zero can save a mask operation. > > I don't have a strong opinion whether we should use zero or dummy bits for > media bus formats. For memory formats I'd be inclined to use zero bits (at > least when capturing). Perhaps it would make sense to assume those dummy bits have undefined value and add some other API for retrieving/setting them where possible, e.g. a v4l2 control ? It just feels like an unnecessary API limitation to assume those dummy bits are always zero. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
