Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp4164119ybg; Mon, 8 Jun 2020 00:13:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwLzFfRn1f03NqfBBrhvP+UFz2skMOg5CUL4elPkGks44Lq3SiFf4t/w5H7r8y9YVssiDMi X-Received: by 2002:a50:9a81:: with SMTP id p1mr19108210edb.221.1591600427087; Mon, 08 Jun 2020 00:13:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591600427; cv=none; d=google.com; s=arc-20160816; b=K7eNNwLmtUHjmgVqxOD9Cz752IlK052kV3RTp/ossHA6gRi2qlW/J/dZTE5OTKf3oV 3yphDMBTsKl0ZjIIi0uW0Dt85Amxr/OWU3QLKyyUYH6r5QPbJWRk+B5tfccTtapRD5Q7 CURCS+nlSba0KwRUduHuEptHE8HLqeb3d231YrEMLVVs1fxK1rEA1dmaSuGQK3lWGh+Y MKyQPECWyyKscmA9WS28I4StjPZyDqN7hXeGS90X0GzyGJlwZak4oMzrq1CAGuPl6A4h j+WL1bZamLNKaSp8W1cHNEl0+o1wCe+Q3nEO7cBI7XIxBCNiXFx/s7pQhQP1b6JJQZlJ ntLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject; bh=gS7qH/qSis3wUhayiMoz65c+GogmaRj88UKx9CtlGEo=; b=jMm9ZMks7Kpe9Zsybd8shR0fhUqAonAA4BZ3rWYI4qSsZW+7CwgYLlN4nL3Tjo7ulj aSK3ZhF7zNx5vf4hzj2sbwg+5ajEqBhT5bLj5JzDub7UR8xqecLQopJjPTu9OL5wcP+g 7MC6ijKe09RjEWuESJzTF3pSivkQ9fOxyEYCGs5GaGn2NBSjI3vqaCnoduhhfjEd6E1g p5be8OuqMT7GZiUY8rEVbSarcqu7QHBhy8Y4pIFG+/4K8YtUbn7Fj7A3yGc4mH5V2MuS RKcvuzULvHmUu39ELfaLzohXzYmE0LGWAjWo44pGx+BdB6QRS8ZgMuYsf8TJSgaoFn4D 57pA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n16si8683783edt.7.2020.06.08.00.13.25; Mon, 08 Jun 2020 00:13:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729046AbgFHHKz (ORCPT + 99 others); Mon, 8 Jun 2020 03:10:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728953AbgFHHKy (ORCPT ); Mon, 8 Jun 2020 03:10:54 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD08CC08C5C3; Mon, 8 Jun 2020 00:10:54 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: dafna) with ESMTPSA id 4664B2A01BB Subject: Re: [RFC PATCH] vimc: Add colors' order over test image To: Kaaira Gupta , linux-media@vger.kernel.org, Helen Koike , Shuah Khan , Mauro Carvalho Chehab , linux-kernel@vger.kernel.org, kieran.bingham@ideasonboard.com, laurent.pinchart@ideasonboard.com References: <20200607135325.GA16838@kaaira-HP-Pavilion-Notebook> From: Dafna Hirschfeld Message-ID: <5866f6c9-36c7-ffe3-41b3-94f184cd9e5d@collabora.com> Date: Mon, 8 Jun 2020 09:10:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200607135325.GA16838@kaaira-HP-Pavilion-Notebook> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > ---> 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 > */ > > +#include > #include > #include > #include > #include > +#include > #include > > #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. 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; > } > >