linux-kernel - Re: [PATCH] vimc: debayer: Add support for ARGB format

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3cdd1740-d085-c04b-1861-a1a541d1ee56@collabora.com>
Date:   Mon, 1 Jun 2020 13:27:36 -0300
From:   Helen Koike <helen.koike@...labora.com>
To:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Kaaira Gupta <kgupta@...iitr.ac.in>
Cc:     Dafna Hirschfeld <dafna.hirschfeld@...labora.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        kieran.bingham@...asonboard.com,
        dafna Hirschfeld <dafna3@...il.com>,
        Lucas Magalhães <lucmaga@...il.com>
Subject: Re: [PATCH] vimc: debayer: Add support for ARGB format



On 6/1/20 9:37 AM, Laurent Pinchart wrote:
> On Mon, Jun 01, 2020 at 05:46:26PM +0530, Kaaira Gupta wrote:
>> On Fri, May 29, 2020 at 05:43:57PM +0200, Dafna Hirschfeld wrote:
>>> Hi,
>>> Thanks for the patch
>>>
>>> I don't know how real devices handle ARGB formats,
>>> I wonder if it should be the part of the debayer.
>>
>> Hi! qcam tries to support BA24 as it is one of the formats that vimc
>> lists as its supported formats wih --list-formats. Shouldn't BA24 be
>> possible to capture with vimc?
>>
>> If yes, which entity should support it, if not debayer? Should there be
>> a separate conversion entity, or should we keep the support in debayer
>> itself for efficiency issues?
> 
> At the hardware level, the de-bayering block usually produces RGB with 8
> or more bits per colour components (so 3xn, 24 bits for 8-bit depths).
> The conversion to 32-bit ARGB usually happens at the DMA engine level,
> in the formatter right in front of the DMA engine. Ideally the vimc
> pipeline should expose the same.
> 
> From a performance point of view, it makes little sense to process the
> image in vimc through multiple steps. I think it would be best to
> generate the final image directly at the output of the pipeline.

[+ Lucas Magalhães]

Lucas was working on a patch for that, he sent an RFC[1] some time ago.

[1] https://patchwork.linuxtv.org/patch/60445/

It would be nice to have this indeed.

Regards,
Helen

> 
>>> On 28.05.20 20:57, Kaaira Gupta wrote:
>>>> Running qcam for pixelformat 0x34324142 showed that vimc debayer does
>>>> not support it. Hence, add the support for Alpha (255).
>>>
>>> I would change the commit log to:
>>>
>>> Add support for V4L2_PIX_FMT_RGB24 format in the debayer
>>> and set the alpha channel to constant 255.
>>>
>>>> Signed-off-by: Kaaira Gupta <kgupta@...iitr.ac.in>
>>>> ---
>>>>   .../media/test-drivers/vimc/vimc-debayer.c    | 27 ++++++++++++-------
>>>>   1 file changed, 18 insertions(+), 9 deletions(-)
>>>>
>>>> diff --git a/drivers/media/test-drivers/vimc/vimc-debayer.c b/drivers/media/test-drivers/vimc/vimc-debayer.c
>>>> index c3f6fef34f68..f34148717a40 100644
>>>> --- a/drivers/media/test-drivers/vimc/vimc-debayer.c
>>>> +++ b/drivers/media/test-drivers/vimc/vimc-debayer.c
>>>> @@ -62,6 +62,7 @@ static const u32 vimc_deb_src_mbus_codes[] = {
>>>>   	MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
>>>>   	MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
>>>>   	MEDIA_BUS_FMT_RGB888_1X32_PADHI,
>>>> +	MEDIA_BUS_FMT_ARGB8888_1X32
>>>>   };
>>>>   static const struct vimc_deb_pix_map vimc_deb_pix_map_list[] = {
>>>> @@ -322,15 +323,23 @@ static void vimc_deb_process_rgb_frame(struct vimc_deb_device *vdeb,
>>>>   	unsigned int i, index;
>>>>   	vpix = vimc_pix_map_by_code(vdeb->src_code);
>>>> -	index = VIMC_FRAME_INDEX(lin, col, vdeb->sink_fmt.width, 3);
>>>> -	for (i = 0; i < 3; i++) {
>>>> -		switch (vpix->pixelformat) {
>>>> -		case V4L2_PIX_FMT_RGB24:
>>>> -			vdeb->src_frame[index + i] = rgb[i];
>>>> -			break;
>>>> -		case V4L2_PIX_FMT_BGR24:
>>>> -			vdeb->src_frame[index + i] = rgb[2 - i];
>>>> -			break;
>>>> +
>>>> +	if (vpix->pixelformat == V4L2_PIX_FMT_ARGB32) {
>>>> +		index =  VIMC_FRAME_INDEX(lin, col, vdeb->sink_fmt.width, 4);
>>>> +		vdeb->src_frame[index] = 255;
>>>> +		for (i = 0; i < 3; i++)
>>>> +			vdeb->src_frame[index + i + 1] = rgb[i];
>>>> +	} else {
>>>> +		index =  VIMC_FRAME_INDEX(lin, col, vdeb->sink_fmt.width, 3);
>>>> +		for (i = 0; i < 3; i++) {
>>>> +			switch (vpix->pixelformat) {
>>>> +			case V4L2_PIX_FMT_RGB24:
>>>> +				vdeb->src_frame[index + i] = rgb[i];
>>>> +				break;
>>>> +			case V4L2_PIX_FMT_BGR24:
>>>> +				vdeb->src_frame[index + i] = rgb[2 - i];
>>>> +				break;
>>>> +			}
>>>>   		}
>>>>   	}
>>>>   }
>