[lkml]   [2020]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/3] media: vimc: Add support for GBR and BGR formats on source pad of debayer

On Sun, Feb 09, 2020 at 02:09:17PM -0300, Ezequiel Garcia wrote:
> On Sun, 2 Feb 2020 at 12:50, Nícolas F. R. A. Prado
> <> wrote:
> >
> > The objective of this series is to add support for GBR and BGR media bus formats
> > for the source pad of debayer subdevices of the vimc driver.
> >
> Can you elaborate why is this needed, e.g. what use-case is this enabling,
> or what is this fixing?


At the moment, the only supported media bus format on the source pad of
the debayer subdevice is the RGB888_1X24.

The mbus format of the source pad of the debayer ultimately determines the
pixelformat that is streamed on /dev/video3, since:
* The mbus formats of the links on the topology have to match for the
streaming to be possible, and [1] shows that the source pad of the
debayer links to the sink of the scaler.
* The scaler uses the same mbus format on sink and source.
* The source pad of the scaler is linked to the /dev/video3 Capture.

That said, there isn't a GBR pixelformat, so it uses the RGB pixelformat.

So what this patch series enables:
* Setting debayer and scaler subdevices to use GBR and BGR mbus formats.
* Stream video using the BGR pixelformat from /dev/video3.

By enabling these, it makes it possible to use vimc to emulate hardware that
uses GBR or BGR mbus formats internally or that streams using the BGR



> Thanks,
> Ezequiel

 \ /
  Last update: 2020-02-09 19:26    [W:0.091 / U:2.588 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site