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: <38db03a4-6b22-c341-103c-ed0d4dcce856@xs4all.nl>
Date:   Mon, 8 Jun 2020 11:33:21 +0200
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Dafna Hirschfeld <dafna.hirschfeld@...labora.com>,
        Kaaira Gupta <kgupta@...iitr.ac.in>,
        linux-media@...r.kernel.org,
        Helen Koike <helen.koike@...labora.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        linux-kernel@...r.kernel.org, kieran.bingham@...asonboard.com,
        laurent.pinchart@...asonboard.com
Subject: Re: [RFC PATCH] vimc: Add colors' order over test image

On 08/06/2020 09:10, Dafna Hirschfeld wrote:
> Hi,
> 
> On 07.06.20 15:53, Kaaira Gupta wrote:
>> Currently there is no method to know if the test image generated by vimc
>> is correct (except for comparing it with a known 'correct' image). Add
>> text over the test image, representing the correct order of colors.
>>
>> I have sent it as an RFC because we can add the text as an optional
>> control, and maybe we can print some other useful information as well
>> (like vivid does).
> 
> Yes, it seems like a good idea to add it as a control of the sensor.
> 
>>
>> Signed-off-by: Kaaira Gupta <kgupta@...iitr.ac.in>
>> --->   drivers/media/test-drivers/vimc/Kconfig       | 2 ++
>>   drivers/media/test-drivers/vimc/vimc-core.c   | 9 +++++++++
>>   drivers/media/test-drivers/vimc/vimc-sensor.c | 8 ++++++++
>>   3 files changed, 19 insertions(+)
>>
>> diff --git a/drivers/media/test-drivers/vimc/Kconfig b/drivers/media/test-drivers/vimc/Kconfig
>> index 4068a67585f9..da4b2ad6e40c 100644
>> --- a/drivers/media/test-drivers/vimc/Kconfig
>> +++ b/drivers/media/test-drivers/vimc/Kconfig
>> @@ -2,6 +2,8 @@
>>   config VIDEO_VIMC
>>   	tristate "Virtual Media Controller Driver (VIMC)"
>>   	depends on VIDEO_DEV && VIDEO_V4L2
>> +	select FONT_SUPPORT
>> +	select FONT_8x16
>>   	select MEDIA_CONTROLLER
>>   	select VIDEO_V4L2_SUBDEV_API
>>   	select VIDEOBUF2_VMALLOC
>> diff --git a/drivers/media/test-drivers/vimc/vimc-core.c b/drivers/media/test-drivers/vimc/vimc-core.c
>> index 11210aaa2551..8142bfbcbd49 100644
>> --- a/drivers/media/test-drivers/vimc/vimc-core.c
>> +++ b/drivers/media/test-drivers/vimc/vimc-core.c
>> @@ -5,10 +5,12 @@
>>    * Copyright (C) 2015-2017 Helen Koike <helen.fornazier@...il.com>
>>    */
>>   
>> +#include <linux/font.h>
>>   #include <linux/init.h>
>>   #include <linux/module.h>
>>   #include <linux/platform_device.h>
>>   #include <media/media-device.h>
>> +#include <media/tpg/v4l2-tpg.h>
>>   #include <media/v4l2-device.h>
>>   
>>   #include "vimc-common.h"
>> @@ -265,7 +267,14 @@ static int vimc_probe(struct platform_device *pdev)
>>   {
>>   	struct vimc_device *vimc;
>>   	int ret;
>> +	const struct font_desc *font = find_font("VGA8x16");
>>   
>> +	if (font == NULL) {
>> +		pr_err("vimc: could not find font\n");
>> +		return -ENODEV;
>> +	}
>> +
>> +	tpg_set_font(font->data);
> 
> I think the code that set the format should move to the
> code that registers the sensor in vimc-sensor.c
> 
>>   	dev_dbg(&pdev->dev, "probe");
>>   
>>   	vimc = kzalloc(sizeof(*vimc), GFP_KERNEL);
>> diff --git a/drivers/media/test-drivers/vimc/vimc-sensor.c b/drivers/media/test-drivers/vimc/vimc-sensor.c
>> index a2f09ac9a360..4b13955c502a 100644
>> --- a/drivers/media/test-drivers/vimc/vimc-sensor.c
>> +++ b/drivers/media/test-drivers/vimc/vimc-sensor.c
>> @@ -185,10 +185,18 @@ static const struct v4l2_subdev_pad_ops vimc_sen_pad_ops = {
>>   static void *vimc_sen_process_frame(struct vimc_ent_device *ved,
>>   				    const void *sink_frame)
>>   {
>> +	u8 *basep[TPG_MAX_PLANES][2];
>> +	char str[100];
>>   	struct vimc_sen_device *vsen = container_of(ved, struct vimc_sen_device,
>>   						    ved);
>>   
>> +	tpg_calc_text_basep(&vsen->tpg, basep, 0, vsen->frame);
>>   	tpg_fill_plane_buffer(&vsen->tpg, 0, 0, vsen->frame);
>> +
>> +	snprintf(str, sizeof(str),
>> +		 "Order: white, yellow, cyan, green, magenta, red, blue, black");
> The colors are generated by the tpg, so I think it should be a feature of the tpg to print the colors.

I agree. The tpg knows where each color is and based on the width and height it can
print the text. A tpg_gen_pattern_text() function that does the work would be very
nice.

It also doesn't make sense for all patterns, so this is really a nice feature to
incorporate into the TPG itself and enable it via a vivid and vimc control.

Regards,

	Hans

> 
> For example, a function in v4l2-tpg-core.c that get the pattern as an argument and return
> this string, or maybe returns a const pointer to the array of colors, or something like that.
> Then maybe we can add a control in vivid for the same tpg feature.
> 
> Note also that the sensor has a control to change the pattern: vimc_sen_ctrl_test_pattern
> So the string depends on that pattern.
> 
> Thanks,
> Dafna
> 
> 
>> +	tpg_gen_text(&vsen->tpg, basep, 1, 1, str);
>> +
>>   	return vsen->frame;
>>   }
>>   
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ