On 10/21/19 11:48 AM, Tomasz Figa wrote:
> On Mon, Oct 21, 2019 at 6:38 PM Hans Verkuil wrote:
>>
>> On 10/21/19 11:26 AM, Tomasz Figa wrote:
>>> On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
On 10/8/19 11:11 AM, Boris Brezillon wrote:
> This is part of the multiplanar and sin
On Mon, Oct 21, 2019 at 6:38 PM Hans Verkuil wrote:
>
> On 10/21/19 11:26 AM, Tomasz Figa wrote:
> > On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
> >>
> >> On 10/8/19 11:11 AM, Boris Brezillon wrote:
> >>> This is part of the multiplanar and singleplanar unification process.
> >>> v4l2_ext
On 10/21/19 11:26 AM, Tomasz Figa wrote:
> On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
>>
>> On 10/8/19 11:11 AM, Boris Brezillon wrote:
>>> This is part of the multiplanar and singleplanar unification process.
>>> v4l2_ext_pix_format is supposed to work for both cases.
>>>
>>> We also add
On Mon, Oct 21, 2019 at 5:41 PM Hans Verkuil wrote:
>
> On 10/8/19 11:11 AM, Boris Brezillon wrote:
> > This is part of the multiplanar and singleplanar unification process.
> > v4l2_ext_pix_format is supposed to work for both cases.
> >
> > We also add the concept of modifiers already employed in
On 10/8/19 11:11 AM, Boris Brezillon wrote:
> This is part of the multiplanar and singleplanar unification process.
> v4l2_ext_pix_format is supposed to work for both cases.
>
> We also add the concept of modifiers already employed in DRM to expose
> HW-specific formats (like tiled or compressed f
Hi Niklas,
Thank you for the patch.
On Mon, Oct 14, 2019 at 02:07:50AM +0200, Niklas Söderlund wrote:
> If a pixel format is not supported by the hardware NULL is returned by
> rvin_format_from_pixel() for that fourcc. Verify that the pixel format
> is supported using this or skip it when enumera
If a pixel format is not supported by the hardware NULL is returned by
rvin_format_from_pixel() for that fourcc. Verify that the pixel format
is supported using this or skip it when enumerating.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-v4l2.c | 20 +++-
This is part of the multiplanar and singleplanar unification process.
v4l2_ext_pix_format is supposed to work for both cases.
We also add the concept of modifiers already employed in DRM to expose
HW-specific formats (like tiled or compressed formats) and allow
exchanging this information with the
Hi Niklas,
Thank you for the patch.
On Fri, Sep 06, 2019 at 04:35:00PM +0200, Niklas Söderlund wrote:
> If a pixel format is not supported by the hardware NULL is returned by
> rvin_format_from_pixel() for that fourcc. Verify that the pixel format
> is supported using this or skip it when enumera
If a pixel format is not supported by the hardware NULL is returned by
rvin_format_from_pixel() for that fourcc. Verify that the pixel format
is supported using this or skip it when enumerating.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-v4l2.c | 12 +++-
1
Hi Niklas,
On 05/07/2019 05:43, Niklas Söderlund wrote:
> Instead of scattering black listing of pixel formats who are not
> supported on particular platforms move it to a central location.
I'd write this as:
The rcar-vin on the M1 platform lacks support for XBGR32 and this is
guar
Instead of scattering black listing of pixel formats who are not
supported on particular platforms move it to a central location.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-dma.c | 2 +-
drivers/media/platform/rcar-vin/rcar-v4l2.c | 23
On Thu, 11 Apr 2019 10:24:16 +0200
Hans Verkuil wrote:
> > static void v4l_print_framebuffer(const void *arg, bool write_only)
> > {
> > const struct v4l2_framebuffer *p = arg;
> > @@ -951,11 +1027,15 @@ static int check_fmt(struct file *file, enum
> > v4l2_buf_type type)
> > switch (
On 4/4/19 10:16 AM, Boris Brezillon wrote:
> This is part of the multiplanar and singleplanar unification process.
> v4l2_ext_pix_format is supposed to work for both cases.
>
> We also add the concept of modifiers already employed in DRM to expose
> HW-specific formats (like tiled or compressed fo
This is part of the multiplanar and singleplanar unification process.
v4l2_ext_pix_format is supposed to work for both cases.
We also add the concept of modifiers already employed in DRM to expose
HW-specific formats (like tiled or compressed formats) and allow
exchanging this information with the
On Tue, 19 Mar 2019 17:37:59 +
Brian Starkey wrote:
> Hi Boris,
>
> On Tue, Mar 19, 2019 at 03:52:42PM +0100, Boris Brezillon wrote:
> > This is part of the multiplanar and singleplanar unification process.
> > v4l2_ext_pix_format is supposed to work for both cases.
> >
> > We also add the
On Tue, 19 Mar 2019 14:07:32 -0400
Nicolas Dufresne wrote:
> Le mardi 19 mars 2019 à 15:52 +0100, Boris Brezillon a écrit :
> > +/**
> > + * struct v4l2_plane_ext_pix_format - additional, per-plane format
> > definition
> > + * @modifier: modifier applied to the format (used for tiled
Le mardi 19 mars 2019 à 15:52 +0100, Boris Brezillon a écrit :
> +/**
> + * struct v4l2_plane_ext_pix_format - additional, per-plane format definition
> + * @modifier: modifier applied to the format (used for tiled formats
> + * and other kind of HW-specific formats, li
Hi Boris,
On Tue, Mar 19, 2019 at 03:52:42PM +0100, Boris Brezillon wrote:
> This is part of the multiplanar and singleplanar unification process.
> v4l2_ext_pix_format is supposed to work for both cases.
>
> We also add the concept of modifiers already employed in DRM to expose
> HW-specific for
This is part of the multiplanar and singleplanar unification process.
v4l2_ext_pix_format is supposed to work for both cases.
We also add the concept of modifiers already employed in DRM to expose
HW-specific formats (like tiled or compressed formats) and allow
exchanging this information with the
From: Swati Sharma
This patch series is for enabling P0xx, Y2xx and Y4xx pixel formats for
intel's i915 driver.
In this patch series, Juha Pekka's patch series Gen10+ P0xx formats
https://patchwork.freedesktop.org/series/56053/ is combined with Swati's
https://patchwork.freedes
This patch series is for enabling P0xx, Y2xx and Y4xx pixel formats for
intel's i915 driver.
In this patch series, Juha Pekka's patch series Gen10+ P0xx formats
https://patchwork.freedesktop.org/series/56053/ is combined with Swati's
https://patchwork.freedesktop.org/series/5
If a driver supports multiple pixel formats with the same frame size,
ENUM_FRAMEINTERVALS will currently only work for the first pixel format.
Fix this by adding pixelformat support to wxh_to_mode().
Signed-off-by: Philipp Zabel
---
drivers/media/usb/gspca/gspca.c | 8 +---
1 file changed
If a driver supports multiple pixel formats with the same frame size,
TRY_FMT will currently always return the first pixel format.
Fix this by adding pixelformat support to wxh_to_nearest_mode().
Signed-off-by: Philipp Zabel
---
drivers/media/usb/gspca/gspca.c | 10 --
1 file changed, 8
> > **
> > *** +V4L2_PIX_FMT_SBGGR12SP ('SRGGB12SP'), V4L2_PIX_FMT_SGBRG12SP
> > ('SGBRG12SP'), V4L2_PIX_FMT_SGRBG12SP ('SGRBG12SP'),
> > V4L2_PIX_FMT_SRGGB12SP ('SRGGB12SP')
> > +***
**
> +V4L2_PIX_FMT_SBGGR12SP ('SRGGB12SP'), V4L2_PIX_FMT_SGBRG12SP ('SGBRG12SP'),
> V4L2_PIX_FMT_SGRBG12SP
> ('SGRBG12SP'), V4L2_PIX_FMT_SRGGB12SP ('SRGGB12SP')
> +********
The new supported formats are
V4L2_PIX_FMT_GREY, V4L2_PIX_FMT_ARGB32, V4L2_PIX_FMT_ABGR32.
The returned encoded format is chaned to support various numbers
of planes instead of assuming 3 planes.
The first patch adds new fields to structs.
The second patch adds support for V4L2_PIX_FMT_GREY.
The
On Thu, 8 Nov 2018 at 14:54, Sasha Levin wrote:
>
> On Thu, Nov 08, 2018 at 10:10:10AM +0200, Dafna Hirschfeld wrote:
> >On Thu, Nov 8, 2018 at 2:51 AM Ezequiel Garcia <
> >ezequ...@vanguardiasur.com.ar> wrote:
> >
> >> Hello Dafna,
> >>
> >> Thanks for the patches.
> >>
> >> Just out of curiosity
From: Hans Verkuil
Add support for 4:2:2, 4:4:4 and RGB 24/32 bits formats.
This makes it a lot more useful, esp. as a simple video compression
codec for use with v4l2-ctl/qvidcap.
Note that it does not do any conversion between e.g. 4:2:2 and 4:2:0
or RGB and YUV: it still just compresses plan
SGRBG12SP'), V4L2_PIX_FMT_SRGGB12SP ('SRGGB12SP')
+**
+
+12-bit Bayer formats
+
+Description
+===
+
+These four pixel formats are use
From: Hans Verkuil
Add support for 4:2:2, 4:4:4 and RGB 24/32 bits formats.
This makes it a lot more useful, esp. as a simple video compression
codec for use with v4l2-ctl/qvidcap.
Note that it does not do any conversion between e.g. 4:2:2 and 4:2:0
or RGB and YUV: it still just compresses plan
, V4L2_PIX_FMT_SBGGR14P ('pBCC'),
+***
+
+*man V4L2_PIX_FMT_SRGGB14P(2)*
+
+V4L2_PIX_FMT_SGRBG14P
+V4L2_PIX_FMT_SGBRG14P
+V4L2_PIX_FMT_SBGGR14P
+14-bit packed Bayer formats
+
+
+Description
Hi Sakari,
Thanks for review.
On 24.07.2018 15:52, Sakari Ailus wrote:
> Hi Todor,
>
> On Mon, Jul 23, 2018 at 02:02:52PM +0300, Todor Tomov wrote:
>> This removes warning "Unknown pixelformat" for the following formats:
>> V4L2_PIX_FMT_SBGGR14P
>> V4L2_PIX_FMT_SGBRG14P
>>
, V4L2_PIX_FMT_SBGGR12P ('pBAA'),
+***
+
+
+12-bit packed Bayer formats
+
+
+Description
+===
+
+These four pixel formats are packed raw sRGB / Bayer formats with 12
+bits per colour.
, V4L2_PIX_FMT_SBGGR12P ('pBAA'),
+***
+
+
+12-bit packed Bayer formats
+
+
+Description
+===
+
+These four pixel formats are packed raw sRGB / Bayer formats with 12
+bits per colour.
On 04/18/2017 03:33 AM, Mauro Carvalho Chehab wrote:
Em Sun, 5 Mar 2017 18:00:32 +0800
Randy Li escreveu:
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those forma
Em Sun, 5 Mar 2017 18:00:32 +0800
Randy Li escreveu:
> The formats added by this patch are:
> V4L2_PIX_FMT_P010
> V4L2_PIX_FMT_P010M
> V4L2_PIX_FMT_P016
> V4L2_PIX_FMT_P016M
> Currently, none of driver uses those format.
>
> Also a variant of V4L2_PIX_FMT_P010M pixel for
This is good too, but if it's all right with you I would prefer to
squash this with the "redo pixel format enumeration and
negotiation" patch, to keep the patch count down.
Steve
On 03/19/2017 03:48 AM, Russell King wrote:
Allow imx_media_find_format() to look up bayer formats, which is
requi
Allow imx_media_find_format() to look up bayer formats, which is
required to support frame size and interval enumeration.
Signed-off-by: Russell King
---
drivers/staging/media/imx/imx-media-capture.c | 11 ++-
drivers/staging/media/imx/imx-media-utils.c | 6 +++---
drivers/staging/med
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format.
Also a variant of V4L2_PIX_FMT_P010M pixel format is added.
The V4L2_PIX_FMT_P010CM is a compat variant of the
On 02/01/2017 09:05 PM, Javier Martinez Canillas wrote:
> From: Thibault Saunier
>
> Those are useful formats that should be handled.
>
> Signed-off-by: Thibault Saunier
> Signed-off-by: Javier Martinez Canillas
Acked-by: Sylwester Nawrocki
t;>> The view of byte order for P010 serial is left empty, it is a little hard
>>> for me to use flat-table to draw them. Is there possible to use something
>>> like latex to do this job?
>>
>> Hmm. Not as far as I know. We recently switched from DocBook mostly d
gt; Hmm. Not as far as I know. We recently switched from DocBook mostly due to
> ReST being more simple to use AFAIU. I think LaTeX output could be produced
> ReST, that might not be very helpful here though.
No, you can't use LaTeX, as it won't be properly displayed on all output
formats. T
From: Thibault Saunier
Those are useful formats that should be handled.
Signed-off-by: Thibault Saunier
Signed-off-by: Javier Martinez Canillas
---
drivers/media/platform/exynos-gsc/gsc-core.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/media/pla
Hi Randy,
On Thu, Jan 05, 2017 at 11:22:26PM +0800, ayaka wrote:
>
>
> On 01/05/2017 06:30 PM, Sakari Ailus wrote:
> >Hi Randy,
> >
> >Thanks for the update.
> >
> >On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
> >>The formats added by this patch are:
> >>V4L2_PIX_FMT_P010
> >>
On 01/05/2017 06:30 PM, Sakari Ailus wrote:
Hi Randy,
Thanks for the update.
On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, non
Hi Randy,
Thanks for the update.
On Thu, Jan 05, 2017 at 12:29:11AM +0800, Randy Li wrote:
> The formats added by this patch are:
> V4L2_PIX_FMT_P010
> V4L2_PIX_FMT_P010M
> V4L2_PIX_FMT_P016
> V4L2_PIX_FMT_P016M
> Currently, none of driver uses those format, but some video
Those pixel formats mainly comes from Gstreamer and ffmpeg. Currently,
the VOP(video output mixer) found on RK3288 and future support
those 10 bits pixel formats are input. Also the decoder on RK3288
could use them as output.
The fourcc is not enough to store the endian information for those
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
V4L2_PIX_FMT_P016
V4L2_PIX_FMT_P016M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decode
Hi all,
On 2 January 2017 at 13:03, ayaka wrote:
> On 01/02/2017 07:07 PM, Sakari Ailus wrote:
>> On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
>>> On 01/02/2017 05:10 PM, Sakari Ailus wrote:
If the format resembles the existing formats but on a different bit
depth,
it sho
On 01/02/2017 07:07 PM, Sakari Ailus wrote:
Hi,
On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
On 01/02/2017 05:10 PM, Sakari Ailus wrote:
Hi Randy,
Thanks for the patch.
On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
The formats added by this patch are:
V4L2_P
Hi,
On Mon, Jan 02, 2017 at 06:53:16PM +0800, ayaka wrote:
>
>
> On 01/02/2017 05:10 PM, Sakari Ailus wrote:
> >Hi Randy,
> >
> >Thanks for the patch.
> >
> >On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
> >>The formats added by this patch are:
> >>V4L2_PIX_FMT_P010
> >>V4L2_
On 01/02/2017 05:10 PM, Sakari Ailus wrote:
Hi Randy,
Thanks for the patch.
On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
h
Hi Randy,
Thanks for the patch.
On Mon, Jan 02, 2017 at 04:50:04PM +0800, Randy Li wrote:
> The formats added by this patch are:
> V4L2_PIX_FMT_P010
> V4L2_PIX_FMT_P010M
> Currently, none of driver uses those format, but some video device
> has been confirmed with could as those forma
The formats added by this patch are:
V4L2_PIX_FMT_P010
V4L2_PIX_FMT_P010M
Currently, none of driver uses those format, but some video device
has been confirmed with could as those format for video output.
The Rockchip's new decoder has supported those format for profile_10
HEVC/AVC
, V4L2_PIX_FMT_SBGGR12P ('pBAA'),
+***
+
+*man V4L2_PIX_FMT_SRGGB12P(2)*
+
+V4L2_PIX_FMT_SGRBG12P
+V4L2_PIX_FMT_SGBRG12P
+V4L2_PIX_FMT_SBGGR12P
+12-bit packed Bayer formats
+
+
+Description
+===
+
+Thes
, V4L2_PIX_FMT_SBGGR12P ('pBAA'),
+***
+
+*man V4L2_PIX_FMT_SRGGB12P(2)*
+
+V4L2_PIX_FMT_SGRBG12P
+V4L2_PIX_FMT_SGBRG12P
+V4L2_PIX_FMT_SBGGR12P
+12-bit packed Bayer formats
+
+
+Description
+===
+
+These four pixel formats are
+
+*man V4L2_PIX_FMT_SRGGB14P(2)*
+
+V4L2_PIX_FMT_SGRBG14P
+V4L2_PIX_FMT_SGBRG14P
+V4L2_PIX_FMT_SBGGR14P
+14-bit packed Bayer formats
+
+
+Description
+===
+
+These four pixel formats are packed raw sRGB / Bayer formats with 14
+bits per colour. Every four consecutive sampl
X_FMT_SRGGB14P
+ V4L2_PIX_FMT_SGRBG14P
+ V4L2_PIX_FMT_SGBRG14P
+ V4L2_PIX_FMT_SBGGR14P
+ 14-bit packed Bayer formats
+
+
+ Description
+
+ These four pixel formats are packed raw sRGB / Bayer
+ formats with 14 bits per colour. Every four consecutive colour
+
X_FMT_SRGGB12P
+ V4L2_PIX_FMT_SGRBG12P
+ V4L2_PIX_FMT_SGBRG12P
+ V4L2_PIX_FMT_SBGGR12P
+ 12-bit packed Bayer formats
+
+
+ Description
+
+ These four pixel formats are packed raw sRGB / Bayer
+ formats with 12 bits per colour. Every four consecutive colour
+
Hi Hans,
Thanks for the review!
Hans Verkuil wrote:
> On 05/27/2016 02:44 PM, Sakari Ailus wrote:
>> These formats are compressed 12-bit raw bayer formats with four different
>> pixel orders. They are similar to 10-bit variants. The formats added by
>> this patch are
>>
>> V4L2_PIX_FMT_SBGGR
uot;>V4L2_PIX_FMT_SGRBG14P
> + id="V4L2-PIX-FMT-SGBRG14P">V4L2_PIX_FMT_SGBRG14P
> + id="V4L2-PIX-FMT-SBGGR14P">V4L2_PIX_FMT_SBGGR14P
> + 14-bit packed Bayer formats
> +
> +
> + Description
> +
> + These four pixel formats are
manvol;
> +
> +
> + id="V4L2-PIX-FMT-SRGGB12P">V4L2_PIX_FMT_SRGGB12P
> + id="V4L2-PIX-FMT-SGRBG12P">V4L2_PIX_FMT_SGRBG12P
> + id="V4L2-PIX-FMT-SGBRG12P">V4L2_PIX_FMT_SGBRG12P
> + id="V4L2-PIX-FMT-SBGGR12P">V
X_FMT_SGRBG14P
+ V4L2_PIX_FMT_SGBRG14P
+ V4L2_PIX_FMT_SBGGR14P
+ 14-bit packed Bayer formats
+
+
+ Description
+
+ These four pixel formats are packed raw sRGB / Bayer
+ formats with 14 bits per colour. Every four consecutive colour
+ components are pa
X_FMT_SGRBG12P
+ V4L2_PIX_FMT_SGBRG12P
+ V4L2_PIX_FMT_SBGGR12P
+ 12-bit packed Bayer formats
+
+
+ Description
+
+ These four pixel formats are packed raw sRGB / Bayer
+ formats with 12 bits per colour. Every four consecutive colour
+ components are pa
When mapping from a V4L2 pixel format to a media bus format in the
VIDIOC_TRY_FMT and VIDIOC_S_FMT handlers, the requested format may be
unsupported by the driver. Return a hardcoded default format instead of
WARN()ing in that case.
Signed-off-by: Laurent Pinchart
---
drivers/staging/media/omap4
On 24 February 2015 at 09:41, Hans Verkuil wrote:
> On 02/24/2015 06:00 PM, Miguel Casas-Sanchez wrote:
>> Hi Hans,
>>
>> go for it if you feel it's the best approach. Are you planning to add
>> multiplanar formats? Particularly, I'm interested in YUV420M and its
>> twin evil brother YVU420M.
>
>
On 02/24/2015 06:00 PM, Miguel Casas-Sanchez wrote:
> Hi Hans,
>
> go for it if you feel it's the best approach. Are you planning to add
> multiplanar formats? Particularly, I'm interested in YUV420M and its
> twin evil brother YVU420M.
Certainly. I'm planning to add all those YUV420 variants. On
Hi Hans,
go for it if you feel it's the best approach. Are you planning to add
multiplanar formats? Particularly, I'm interested in YUV420M and its
twin evil brother YVU420M.
I would recommend adding support for a less-common format such as
YUV410 (or variation thereof). Since this format is so d
Hi Miguel,
Thanks for the patch. However, after reviewing it and testing it
I decided to implement my own version. Partially because several
features were still failing (crop/compose/scale), partially because
I didn't like the way the tpg was changed: too much change basically.
Yesterday I added
ownsampling = 2;
+ tpg->horizontal_downsampling = 2;
+ break;
+ default:
+ tpg->vertical_downsampling = 0;
+ tpg->horizontal_downsampling = 0;
+ }
+
return true;
}
@@ -271,6 +299,12 @@ void tpg_reset_source(struct t
On 02/11/2015 08:32 PM, Miguel Casas-Sanchez wrote:
> Docos says for these pixel formats:
>
> start... : Cb00 Cr00 Cb01 Cr01
> start... : Cb10 Cr10 Cb11 Cr11
>
> whereas it should read:
>
> start... : Cb00 Cr00 Cb11 Cr11
> start... : Cb20 Cr20 Cb21 Cr21
>
> whe
Docos says for these pixel formats:
start... : Cb00 Cr00 Cb01 Cr01
start... : Cb10 Cr10 Cb11 Cr11
whereas it should read:
start... : Cb00 Cr00 Cb11 Cr11
start... : Cb20 Cr20 Cb21 Cr21
where ... depends on the exact multi/single planar format.
See e.g. http://linuxtv.org/downloads/v4l-dvb-apis
7;pBAA'),
+
+ &manvol;
+
+
+ V4L2_PIX_FMT_SRGGB10P
+ V4L2_PIX_FMT_SGRBG10P
+ V4L2_PIX_FMT_SGBRG10P
+ V4L2_PIX_FMT_SBGGR10P
+ 10-bit packed Bayer formats
+
+
+ Description
+
+ These four pixel formats are packed raw sRGB /
+ Bayer formats wit
GBRG10P ('pGAA'),
> > +V4L2_PIX_FMT_SBGGR10P ('pBAA'),
> > +
> > + &manvol;
> > +
> > +
> > +> id="V4L2-PIX-FMT-SRGGB10P">V4L2_PIX_FMT_SRGGB10P
> > +> id="V4L2-PIX-FMT-SGRBG10P&qu
PIX-FMT-SGRBG10P">V4L2_PIX_FMT_SGRBG10P
> + id="V4L2-PIX-FMT-SGBRG10P">V4L2_PIX_FMT_SGBRG10P
> + id="V4L2-PIX-FMT-SBGGR10P">V4L2_PIX_FMT_SBGGR10P
> + 10-bit packed Bayer formats
> +
> +
> + Description
> +
> +
+
+ V4L2_PIX_FMT_SRGGB10P
+ V4L2_PIX_FMT_SGRBG10P
+ V4L2_PIX_FMT_SGBRG10P
+ V4L2_PIX_FMT_SBGGR10P
+ 10-bit packed Bayer formats
+
+
+ Description
+
+ The following four pixel formats are packed raw sRGB /
+ Bayer formats with 10 bits per c
t deprecated.
>
> The new pixel formats 4CC values have been selected to match the DRM
> 4CCs for the same in-memory formats.
Acked-by: Hans Verkuil
But: I've double-checked your chosen fourcc's for the RGB32 formats, and I see
you made a mistake in the docbook (the videodev2.h he
The existing RGB555X pixel format is ill-defined in respect to its alpha
bit and its meaning is driver dependent. Create new standard ARGB555X
and XRGB555X variants with clearly defined meanings and make the
existing variant deprecated.
The new pixel formats 4CC values have been selected to match
AM, Laurent Pinchart wrote:
>>> From: Laurent Pinchart
>>>
>>> The existing RGB pixel formats are ill-defined in respect to their alpha
>>> bits and their meaning is driver dependent. Create new standard ARGB and
>>> XRGB variants with clearly defined meanin
red you missed
>>> one:
>>>
>>> On 06/24/2014 01:54 AM, Laurent Pinchart wrote:
>>>> From: Laurent Pinchart
>>>>
>>>> The existing RGB pixel formats are ill-defined in respect to their alpha
>>>> bits and their meani
Hi Hans,
On Thursday 17 July 2014 23:53:52 Hans Verkuil wrote:
> Hi Laurent,
>
> While implementing support for this in v4l-utils I discovered you missed
> one:
>
> On 06/24/2014 01:54 AM, Laurent Pinchart wrote:
> > From: Laurent Pinchart
> >
> > The existi
Hi Laurent,
While implementing support for this in v4l-utils I discovered you missed one:
On 06/24/2014 01:54 AM, Laurent Pinchart wrote:
> From: Laurent Pinchart
>
> The existing RGB pixel formats are ill-defined in respect to their alpha
> bits and their meaning is driver depen
Hi Laurent,
A small comment below:
On 06/24/2014 01:54 AM, Laurent Pinchart wrote:
When set, the new V4L2_PIX_FMT_FLAG_PREMUL_ALPHA flag indicates that the
pixel values are premultiplied by the alpha channel value.
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/media/v4l/pixfmt.x
Acked-by: Hans Verkuil
Regards,
Hans
On 06/24/2014 01:54 AM, Laurent Pinchart wrote:
From: Laurent Pinchart
The existing RGB pixel formats are ill-defined in respect to their alpha
bits and their meaning is driver dependent. Create new standard ARGB and
XRGB variants with clearly
When set, the new V4L2_PIX_FMT_FLAG_PREMUL_ALPHA flag indicates that the
pixel values are premultiplied by the alpha channel value.
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/media/v4l/pixfmt.xml | 28 +++-
Documentation/DocBook/media/v4l/v4l2.xml | 2 +-
From: Laurent Pinchart
The existing RGB pixel formats are ill-defined in respect to their alpha
bits and their meaning is driver dependent. Create new standard ARGB and
XRGB variants with clearly defined meanings and make the existing
variants deprecated.
The new pixel formats 4CC values have
When set, the new V4L2_PIX_FMT_FLAG_PREMUL_ALPHA flag indicates that the
pixel values are premultiplied by the alpha channel value.
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/media/v4l/pixfmt.xml | 28 +++-
Documentation/DocBook/media/v4l/v4l2.xml | 2 +-
From: Laurent Pinchart
The existing RGB pixel formats are ill-defined in respect to their alpha
bits and their meaning is driver dependent. Create new standard ARGB and
XRGB variants with clearly defined meanings and make the existing
variants deprecated.
The new pixel formats 4CC values have
Hi Hans,
On Tuesday 27 May 2014 09:18:23 Hans Verkuil wrote:
> On 05/27/2014 12:17 AM, Laurent Pinchart wrote:
> > Hello,
> >
> > This RFC patch series attempts to clean up the current ARGB format mess.
> >
> > The core issue is that the existing ARGB formats are ill-defined. The V4L2
> > specif
fixed
> alpha value on the other side.
I prefer a CAP_ALPHA_COMPONENT control. It's easy to add a capture-specific
control now, it's much harder to change it in the future.
Regards,
Hans
>
> Laurent Pinchart (2):
> v4l: Add ARGB and XRGB pixel formats
other side.
Laurent Pinchart (2):
v4l: Add ARGB and XRGB pixel formats
DocBook: media: Document ALPHA_COMPONENT control usage on output
devices
Documentation/DocBook/media/v4l/controls.xml | 17 +-
.../DocBook/media/v4l/pixfmt-packed-rgb.xml| 415 -
From: Laurent Pinchart
The existing RGB pixel formats are ill-defined in respect to their alpha
bits and their meaning is driver dependent. Create new standard ARGB and
XRGB variants with clearly defined meanings and make the existing
variants deprecated.
The new pixel formats 4CC values have
On 14/05/14 16:31, Kamil Debski wrote:
> The 'Code' column in the documentation should provide the real fourcc
> code that is used. Changed the documentation to provide the fourcc
> defined in videodev2.h
>
> Signed-off-by: Kamil Debski
Acked-by: Sylwester Nawrocki
> ---
> Documentation/DocBo
The 'Code' column in the documentation should provide the real fourcc
code that is used. Changed the documentation to provide the fourcc
defined in videodev2.h
Signed-off-by: Kamil Debski
---
Documentation/DocBook/media/v4l/pixfmt.xml |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
This patch fixes the v4l2-compliance "TRY_FMT(G_FMT) != G_FMT" issue.
The driver now overwrites invalid formats with the current setting, using
coda_get_max_dimensions to find device specific max width/height.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 72 +
This patch fixes the v4l2-compliance "TRY_FMT(G_FMT) != G_FMT" issue.
The driver now overwrites invalid formats with the current setting, using
coda_get_max_dimensions to find device specific max width/height.
Signed-off-by: Philipp Zabel
---
drivers/media/platform/coda.c | 72 +
(A bit late, sorry)
On Thursday 07 March 2013 22:37:26 Guennadi Liakhovetski wrote:
> On Wed, 6 Mar 2013, Christian Rhodin wrote:
> > Hi,
> >
> > I'm looking for some guidance on the correct way to handle a new pixel
> > format. What I'm dealing with is a CMOS image sensor that supports
> > dyna
Hi Christian
On Wed, 6 Mar 2013, Christian Rhodin wrote:
> Hi,
>
> I'm looking for some guidance on the correct way to handle a new pixel
> format. What I'm dealing with is a CMOS image sensor that supports
> dynamic switching between linear and iHDR modes. iHDR stands for
> "interlaced High D
Hi,
I'm looking for some guidance on the correct way to handle a new pixel
format. What I'm dealing with is a CMOS image sensor that supports
dynamic switching between linear and iHDR modes. iHDR stands for
"interlaced High Dynamic Range" and is a mode where odd and even lines
have different exp
1 - 100 of 169 matches
Mail list logo
