Re: [PATCH/RFC 0/2] Propert alpha channel support in pixel formats

[Hans Verkuil <hverkuil@xs4all.nl>]

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?

> 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.

Regards,

	Hans

> 
> Laurent Pinchart (2):
>   v4l: Add ARGB and XRGB pixel formats
>   DocBook: media: Document ALPHA_COMPONENT control usage on output
>     devices
> 
>  Documentation/DocBook/media/v4l/controls.xml       |  17 +-
>  .../DocBook/media/v4l/pixfmt-packed-rgb.xml        | 415 ++++++++++++++++++++-
>  include/uapi/linux/videodev2.h                     |   8 +
>  3 files changed, 413 insertions(+), 27 deletions(-)
>