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]
Date:   Mon, 10 Dec 2018 18:13:41 +0100
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Helen Koike <helen.koike@...labora.com>,
        linux-media@...r.kernel.org
Cc:     mchehab@...nel.org, lkcamp@...ts.libreplanetbr.org,
        kernel@...labora.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: vimc: add configfs API to configure the topology

On 12/10/18 5:14 PM, Helen Koike wrote:
> Hi Hans,
> 
> On 12/10/18 9:31 AM, Hans Verkuil wrote:
>> On 12/7/18 7:22 PM, Helen Koike wrote:

<snip>

> 
>>
>> The previewer is effectively similar to a debayer block.
> 
> You mean the image it outputs?

Yes. It takes a bayer image and outputs a non-bayer format on the omap3.

> 
>>
>> AEWB, AF and histogram are for auto-whitebalance, autofocus and histogram statistics.
>> This isn't supported by vimc, and is a 'nice-to-have' for the future.
> 
> Right, I need to check how to include those. I am a bit confused as in
> the omap3 topology they are seems to be just configuration points (I
> mean, they are not really part of the image pipeline).

Typically the SoC analyzes the image and produces statistics of various kinds that
are given to userspace via devices like this. It is used as input to auto-whitebalance,
auto-focus and auto-gain algorithms running in userspace that feedback the results to
sensor config changes.

The format is usually very SoC-specific.

> 
> I was reading this
> https://linuxtv.org/downloads/v4l-dvb-apis-new/v4l-drivers/omap3isp.html?highlight=histogram#statistic-blocks-ioctls
> It says:
> "The statistics are dequeueable by the user from the statistics subdev
> nodes using private IOCTLs"
> 
> I suppose we should emulate those private IOCTLs in vimc? If you could
> provide me some pointers in where I can find docs on these private
> IOCTLs it would be great.

No, just ignore these statistics devices for now. And if we make them, we
can design a vimc-specific format.

> 
>>
>> The main missing bits in vimc are a CSI block and a splitter block. It should be simple
>> to add the CSI block since it really doesn't do anything in an emulated environment.
> 
> CSI would be just a dummy entity with one sink pad and one source pad right?

Right.

> 
>>
>> A splitter might be more complicated, I'm not sure.
> 
> splitter shouldn't that complicated in the current state of vimc, but
> when we start optimizing the pipeline then it is going to be more
> complicated.

Right.

Regards,

	Hans

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ