Hi Hans, On Tuesday 27 May 2014 09:18:23 Hans Verkuil wrote: > On 05/27/2014 12:17 AM, Laurent Pinchart wrote: > > Hello, > > > > This RFC patch series attempts to clean up the current ARGB format mess. > > > > The core issue is that the existing ARGB formats are ill-defined. The V4L2 > > specification doesn't clearly document how the alpha bits should behave. > > Drivers have thus used the same formats in different, incompatible ways, > > and applications now rely on the driver-specific behaviours. In a word, > > that's a mess. > > > > I've discussed the issue in the #v4l channel a couple of days ago and we > > came up to the conclusion that the best (or least painful) way to fix the > > problem is to define new clean XRGB and ARGB formats, and consider the > > existing formats as deprecated (meaning that no new driver should use > > them, they won't disappear in a couple of months, as that would break > > userspace). > > > > The first patch adds the new XRGB and ARGB formats and documents them. > > Question: should we add all XRGB and ARGB formats even if drivers do not use > them? Or just those that are actually used? The VSP1 driver is going to use them all, so we need them all. > > It purposely includes no core code to handle backward compatibility for > > existing drivers that may wish to move to the new formats. The reason is > > that I would first like to get feedback on the proposal before working on > > compat code, and I believe we should first implement the compat code in a > > couple of drivers and then see how the approach could be generalized, if > > possible at all. > > > > The second patch allows using the ALPHA_COMPONENT control on output > > devices to support an ARGB use case documented in the first patch. One > > possible shortcoming of reusing the existing control is that a mem-to-mem > > driver that exposes an output and a capture queue on a single video node > > through the same file handle wouldn't be able to set different alpha > > component values on the two queues. I'm not sure whether that use case is > > real though, it seems weird to me to set a fixed alpha value on one side > > to request a different fixed alpha value on the other side. > > I prefer a CAP_ALPHA_COMPONENT control. It's easy to add a capture-specific > control now, it's much harder to change it in the future. What bothers me with this approach is the duplication of otherwise identical controls. As we'll likely need per-pad controls at some point in the future, wouldn't it better to implement a similar way to distinguish between capture and output controls ? -- Regards, Laurent Pinchart -- 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
