Re: [PATCH] Media: video: uvc: integer overflow in uvc_ioctl_ctrl_map()
The hard limit sounds good to me. But if you want to centralize error
handling, please make sure that "goto done" only frees map, but not
map->menu_info in that case.
- Haogang
On Tue, Nov 29, 2011 at 8:22 PM, Laurent Pinchart
wrote:
> Hi Haogang,
>
> On Tuesday 29 November 2011 22:32:25 Haogang Chen wrote:
>> There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
>> large xmap->menu_count is passed from the userspace, the subsequent call
>> to kmalloc() will allocate a buffer smaller than expected.
>> map->menu_count and map->menu_info would later be used in a loop (e.g.
>> in uvc_query_v4l2_ctrl), which leads to out-of-bound access.
>>
>> The patch checks the ioctl argument and returns -EINVAL for zero or too
>> large values in xmap->menu_count.
>
> Thanks for the patch.
>
>> Signed-off-by: Haogang Chen
>> ---
>> drivers/media/video/uvc/uvc_v4l2.c | 6 ++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/media/video/uvc/uvc_v4l2.c
>> b/drivers/media/video/uvc/uvc_v4l2.c index dadf11f..9a180d6 100644
>> --- a/drivers/media/video/uvc/uvc_v4l2.c
>> +++ b/drivers/media/video/uvc/uvc_v4l2.c
>> @@ -58,6 +58,12 @@ static int uvc_ioctl_ctrl_map(struct uvc_video_chain
>> *chain, break;
>>
>> case V4L2_CTRL_TYPE_MENU:
>> + if (xmap->menu_count == 0 ||
>> + xmap->menu_count > INT_MAX / sizeof(*map->menu_info)) {
>
> I'd like to prevent excessive memory consumption by limiting the number of
> menu entries, similarly to how the driver limits the number of mappings.
> Defining UVC_MAX_CONTROL_MENU_ENTRIES to 32 in uvcvideo.h should be a
> reasonable value.
>
>> + kfree(map);
>> + return -EINVAL;
>
> I'd rather do
>
> ret = -EINVAL;
> goto done;
>
> to centralize error handling.
>
> If you're fine with both changes I can modify the patch, there's no need to
> resubmit.
>
>> + }
>> +
>> size = xmap->menu_count * sizeof(*map->menu_info);
>> map->menu_info = kmalloc(size, GFP_KERNEL);
>> if (map->menu_info == NULL) {
>
> --
> Regards,
>
> Laurent Pinchart
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3isp: video: Don't WARN() on unknown pixel formats
Hi Sakari,
On Monday 28 November 2011 17:01:12 Sakari Ailus wrote:
> On Mon, Nov 28, 2011 at 12:37:34PM +0100, Laurent Pinchart wrote:
> > 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 format instead of
> > WARN()ing in that case.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/media/video/omap3isp/ispvideo.c |8
> > 1 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/media/video/omap3isp/ispvideo.c
> > b/drivers/media/video/omap3isp/ispvideo.c index d100072..ffe7ce9 100644
> > --- a/drivers/media/video/omap3isp/ispvideo.c
> > +++ b/drivers/media/video/omap3isp/ispvideo.c
> > @@ -210,14 +210,14 @@ static void isp_video_pix_to_mbus(const struct
> > v4l2_pix_format *pix,
> >
> > mbus->width = pix->width;
> > mbus->height = pix->height;
> >
> > - for (i = 0; i < ARRAY_SIZE(formats); ++i) {
> > + /* Skip the last format in the loop so that it will be selected if no
> > +* match is found.
> > +*/
> > + for (i = 0; i < ARRAY_SIZE(formats) - 1; ++i) {
> >
> > if (formats[i].pixelformat == pix->pixelformat)
> >
> > break;
> >
> > }
> >
> > - if (WARN_ON(i == ARRAY_SIZE(formats)))
> > - return;
> > -
> >
> > mbus->code = formats[i].code;
> > mbus->colorspace = pix->colorspace;
> > mbus->field = pix->field;
>
> In case of setting or trying an invalid format, instead of selecting a
> default format, shouldn't we leave the format unchanced --- the current
> setting is valid after all.
TRY/SET operations must succeed. The format we select when an invalid format
is requested isn't specified. We could keep the current format, but wouldn't
that be more confusing for applications ? The format they would get in
response to a TRY/SET operation would then potentially depend on the previous
SET operations.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: uvcvideo: Failed to query (SET_CUR) UVC control 10 on unit 2: -32 (exp. 2).
Hi Alex,
On Monday 28 November 2011 22:53:19 Alex wrote:
> On 11/28/2011 10:20 PM, Laurent Pinchart wrote:
> > On Monday 28 November 2011 20:14:25 Alex wrote:
> >> On 11/28/2011 10:08 PM, Laurent Pinchart wrote:
> >>> On Monday 28 November 2011 19:04:22 Alex wrote:
> Fortunately my laptop is alive now so I'm sending you lsusb output.
> >>>
> >>> Thanks. Would you mind re-running lsusb -v -d '04f2:b221' as root ?
> >>> What laptop brand/model is the camera embedded in ?
> >>>
> About reverting commit - will try bit later.
> >>>
> >>> I've received reports that reverting the commit helps. A proper patch
> >>> has also been posted to the linux-usb mailing list ("EHCI : Fix a
> >>> regression in the ISO scheduler"). It would be nice if you could check
> >>> whether that fixes your first issue as well.
> >>
> >> That is lsusb output you asked. Laptop is Thinkpad T420s. Camera works
> >> OK with 3.1.x kernel BTW.
> >
> > Thank you.
> >
> >> Could you send this fix patch to me please?
> >
> > http://www.spinics.net/lists/linux-usb/msg54992.html
> >
> > It was the first hit on Google...
>
> Laurent,
>
> Seems this patch didn't help I recompiled kernel and still get same error:
> [ 101.100914] uvcvideo: Failed to query (SET_CUR) UVC control 10 on
> unit 2: -32 (exp. 2).
> [ 103.900163] uvcvideo: Failed to query (SET_CUR) UVC control 10 on
> unit 2: -32 (exp. 2).
> [ 103.909735] uvcvideo: Failed to submit URB 0 (-28).
> [ 107.896939] uvcvideo: Failed to query (SET_CUR) UVC control 10 on
> unit 2: -32 (exp. 2).
I'm surprised. The patch has been included in 3.1.4, could you please try it ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add new alpha component control
Hi Sylwester, On Tuesday 29 November 2011 20:39:39 Sylwester Nawrocki wrote: > On 11/29/2011 07:10 PM, Laurent Pinchart wrote: > > On Tuesday 29 November 2011 17:40:10 Sylwester Nawrocki wrote: > >> On 11/29/2011 12:08 PM, Hans Verkuil wrote: > >>> On Monday 28 November 2011 14:02:49 Sylwester Nawrocki wrote: > On 11/28/2011 01:39 PM, Hans Verkuil wrote: > > On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote: > >> On 11/28/2011 12:38 PM, Hans Verkuil wrote: > >>> On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: > >> Nevertheless I have at least two use cases, for the alpha control and > >> for the image sensor driver. In case of the camera sensor, different > >> device revisions may have different step and maximum value for some > >> controls, depending on firmware. > >> By using v4l2_ctrl_range_update() I don't need to invoke lengthy sensor > >> start-up procedure just to find out properties of some controls. > > > > Wouldn't it be confusing for applications to start with a range and have > > it updated at runtime ? > > Indeed, changing a control range like this is not the brightest idea ever. > I would not consider doing something like this commonly. However if the > applications are aware that the control range may change at any time and > they handle the events, there shouldn't be a problem. Of course life for > applications is getting harder. The complexity for applications is > increasing maybe a bit too much at this point already... > > I guess you would agree that it's best to power up the sensor when > sub-device node is opened and do all necessary setup before any subdev > file operation is commenced. And applications won't be able to query the control range without opening the subdev anyway. > For that I'm just looking forward for the common struct clk to be merged and > all platforms to be converted to it. So we can use a struct clk object to > enable sensor clock from subdev drivers level. I think we're all looking for that :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Media: video: uvc: integer overflow in uvc_ioctl_ctrl_map()
Hi Haogang,
On Tuesday 29 November 2011 22:32:25 Haogang Chen wrote:
> There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
> large xmap->menu_count is passed from the userspace, the subsequent call
> to kmalloc() will allocate a buffer smaller than expected.
> map->menu_count and map->menu_info would later be used in a loop (e.g.
> in uvc_query_v4l2_ctrl), which leads to out-of-bound access.
>
> The patch checks the ioctl argument and returns -EINVAL for zero or too
> large values in xmap->menu_count.
Thanks for the patch.
> Signed-off-by: Haogang Chen
> ---
> drivers/media/video/uvc/uvc_v4l2.c |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/uvc/uvc_v4l2.c
> b/drivers/media/video/uvc/uvc_v4l2.c index dadf11f..9a180d6 100644
> --- a/drivers/media/video/uvc/uvc_v4l2.c
> +++ b/drivers/media/video/uvc/uvc_v4l2.c
> @@ -58,6 +58,12 @@ static int uvc_ioctl_ctrl_map(struct uvc_video_chain
> *chain, break;
>
> case V4L2_CTRL_TYPE_MENU:
> + if (xmap->menu_count == 0 ||
> + xmap->menu_count > INT_MAX / sizeof(*map->menu_info)) {
I'd like to prevent excessive memory consumption by limiting the number of
menu entries, similarly to how the driver limits the number of mappings.
Defining UVC_MAX_CONTROL_MENU_ENTRIES to 32 in uvcvideo.h should be a
reasonable value.
> + kfree(map);
> + return -EINVAL;
I'd rather do
ret = -EINVAL;
goto done;
to centralize error handling.
If you're fine with both changes I can modify the patch, there's no need to
resubmit.
> + }
> +
> size = xmap->menu_count * sizeof(*map->menu_info);
> map->menu_info = kmalloc(size, GFP_KERNEL);
> if (map->menu_info == NULL) {
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] V4L: soc-camera: change order of removing device
Hi Lei On Tue, 29 Nov 2011, Lei Wen wrote: > Hi, > > On Tue, Nov 22, 2011 at 10:04 PM, Lei Wen wrote: > > As our general practice, we use stream off before we close > > the video node. So that the drivers its stream off function > > would be called before its remove function. > > > > But for the case for ctrl+c, the program would be force closed. > > We have no chance to call that vb2 stream off from user space, > > but directly call the remove function in soc_camera. > > > > In that common code of soc_camera: > > > > ici->ops->remove(icd); > > if (ici->ops->init_videobuf2) > > vb2_queue_release(&icd->vb2_vidq); > > > > It would first call the device remove function, then release vb2, > > in which stream off function is called. Thus it create different > > order for the driver. > > > > This patch change the order to make driver see the same sequence > > to make it happy. This is a change, that would affect all soc-camera host drivers. Since you don't describe the actual problem and the platform, on which it occurs, I suppose, it is not a regression, and, possibly, it only affects an off-tree driver from your employer. Therefore I don't think it would be reasonable to push it in the middle of an -rc* period. Still, this change seems logical, and I'll consider including it in the 3.3 kernel. I'll come back to you if I have further questions. Thanks Guennadi > > > > Signed-off-by: Lei Wen > > --- > > drivers/media/video/soc_camera.c | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/media/video/soc_camera.c > > b/drivers/media/video/soc_camera.c > > index b72580c..fdc6167 100644 > > --- a/drivers/media/video/soc_camera.c > > +++ b/drivers/media/video/soc_camera.c > > @@ -600,9 +600,9 @@ static int soc_camera_close(struct file *file) > > pm_runtime_suspend(&icd->vdev->dev); > > pm_runtime_disable(&icd->vdev->dev); > > > > - ici->ops->remove(icd); > > if (ici->ops->init_videobuf2) > > vb2_queue_release(&icd->vb2_vidq); > > + ici->ops->remove(icd); > > > > soc_camera_power_off(icd, icl); > > } > > -- > > 1.7.0.4 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-media" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > Any comments? > > Thanks, > Lei > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Media: video: uvc: integer overflow in uvc_ioctl_ctrl_map()
There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a
large xmap->menu_count is passed from the userspace, the subsequent call
to kmalloc() will allocate a buffer smaller than expected.
map->menu_count and map->menu_info would later be used in a loop (e.g.
in uvc_query_v4l2_ctrl), which leads to out-of-bound access.
The patch checks the ioctl argument and returns -EINVAL for zero or too
large values in xmap->menu_count.
Signed-off-by: Haogang Chen
---
drivers/media/video/uvc/uvc_v4l2.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index dadf11f..9a180d6 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -58,6 +58,12 @@ static int uvc_ioctl_ctrl_map(struct uvc_video_chain *chain,
break;
case V4L2_CTRL_TYPE_MENU:
+ if (xmap->menu_count == 0 ||
+ xmap->menu_count > INT_MAX / sizeof(*map->menu_info)) {
+ kfree(map);
+ return -EINVAL;
+ }
+
size = xmap->menu_count * sizeof(*map->menu_info);
map->menu_info = kmalloc(size, GFP_KERNEL);
if (map->menu_info == NULL) {
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Status of RTL283xU support?
On 26.11.2011 17:20, Maik Zumstrull wrote: > On Sat, Nov 26, 2011 at 13:47, Maik Zumstrull wrote: .. > FYI, someone has contacted me off-list to point out that the newest(?) > Realtek tree for these devices is available online: > > Alessandro Ambrosini wrote: > >> Dear maik, >> >> I've read your post here >> http://www.mail-archive.com/linux-media@vger.kernel.org/msg39559.html >> I have not a subscription to linux-media mailing list. I see your post >> looking for in archive. >> >> Some days ago I've asked to Realtek if there are newer driver (latest on the >> net was 2.2.0) >> They kindly send me latest driver 2.2.2 kernel 2.6.x >> >> I've patched it yesterday for kernel 3.0.0 (Ubuntu 11.10) and they looks to >> work fine. >> I'm not an expert C coder, only an hobbyist. So I suppose there are >> problems. >> >> Anyway here you can find: >> >> 1) original Realtek 2.2.2 driver "simplified version" (DVB-T only and 4 >> tuners only) >> https://github.com/ambrosa/DVB-Realtek-RTL2832U-2.2.2-4_tuner >> >> 2) original Realtek 2.2.2 driver "full version" (DVB-T/ DTMB and 10 tuners) >> https://github.com/ambrosa/DVB-Realtek-RTL2832U-2.2.2-10_tuner >> >> 3) driver "full" modded by me for kernel 3.0.0 >> https://github.com/ambrosa/DVB-Realtek-RTL2832U-2.2.2-10tuner-mod_kernel-3.0.0 >> README file explain about all >> >> They compile fine in Ubuntu 11.10 64 bit and works great. .. Distro - Fedora release 16 (Verne)/3.1.2-1.fc16.x86_64 Device - DeLOCK USB 2.0 DVB-T Receiver 61744 http://www.delock.com/produkte/gruppen/Multimedia/Delock_USB_20_DVB-T_Receiver_61744.html based on: Realtek RTL2832U DVB-T demodulator-USB bridge & Fitipower FC0012 tuner lsusb: Bus 002 Device 003: ID 1f4d:b803 G-Tek Electronics Group Lifeview LV5TDLX DVB-T [RTL2832U] modinfo dvb_usb_rtl2832u: filename: /lib/modules/3.1.2-1.fc16.x86_64/kernel/drivers/media/dvb/dvb-usb/dvb-usb-rtl2832u.ko license:GPL version:2.2.2 description:Driver for the RTL2832U DVB-T / RTL2836 DTMB USB2.0 device author: Dean Chung author: Chialing Lu author: Realtek srcversion: 82E6C8E24DEE7DCA47B605E alias: usb:v1680pA332d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp9520d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp9530d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp9540d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp9550d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp9580d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp0680d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp0650d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp0640d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp0630d*dc*dsc*dp*ic*isc*ip* alias: usb:v185Bp0620d*dc*dsc*dp*ic*isc*ip* alias: usb:v1164p3284d*dc*dsc*dp*ic*isc*ip* alias: usb:v1164p3280d*dc*dsc*dp*ic*isc*ip* alias: usb:v1164p6601d*dc*dsc*dp*ic*isc*ip* alias: usb:v0413p6F11d*dc*dsc*dp*ic*isc*ip* alias: usb:v0413p6680d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpA683d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4Dp0139d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpD286d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpC280d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpD803d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpC803d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpB803d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4DpA803d*dc*dsc*dp*ic*isc*ip* alias: usb:v1F4Dp0837d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE41Dd*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD3A4d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD3A1d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pE77Bd*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD39Ed*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD39Cd*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD39Bd*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD39Ad*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD398d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD397d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD396d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD395d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD394d*dc*dsc*dp*ic*isc*ip* alias: usb:v1B80pD393d*dc*dsc*dp*ic*isc*ip* alias: usb:v1554p5026d*dc*dsc*dp*ic*isc*ip* alias: usb:v1554p5020d*dc*dsc*dp*ic*isc*ip* alias: usb:v1554p5013d*dc*dsc*dp*ic*isc*ip* alias: usb:v13D3p3282d*dc*dsc*dp*ic*isc*ip* alias: usb:v13D3p3274d*dc*dsc*dp*ic*isc*ip* alias: usb:v13D3p3234d*dc*dsc*dp*ic*isc*ip* alias: usb:v0CCDp00B3d*dc*dsc*dp*ic*isc*ip* alias: usb:v0CCDp00A9d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p9202d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p3103d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p9201d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p8202d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p2101d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p1108d*dc*dsc*dp*ic*isc*ip* alias: usb:v1D19p1107d*dc*dsc*dp*ic*isc*ip* alias:
Re: [PATCH v2 1/2] v4l: Add new alpha component control
Hi Laurent! On 11/29/2011 07:10 PM, Laurent Pinchart wrote: > Hi Sylwester, > > On Tuesday 29 November 2011 17:40:10 Sylwester Nawrocki wrote: >> On 11/29/2011 12:08 PM, Hans Verkuil wrote: >>> On Monday 28 November 2011 14:02:49 Sylwester Nawrocki wrote: On 11/28/2011 01:39 PM, Hans Verkuil wrote: > On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote: >> On 11/28/2011 12:38 PM, Hans Verkuil wrote: >>> On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: >> >> Nevertheless I have at least two use cases, for the alpha control and >> for the image sensor driver. In case of the camera sensor, different device >> revisions may have different step and maximum value for some controls, >> depending on firmware. >> By using v4l2_ctrl_range_update() I don't need to invoke lengthy sensor >> start-up procedure just to find out properties of some controls. > > Wouldn't it be confusing for applications to start with a range and have it > updated at runtime ? > Indeed, changing a control range like this is not the brightest idea ever. I would not consider doing something like this commonly. However if the applications are aware that the control range may change at any time and they handle the events, there shouldn't be a problem. Of course life for applications is getting harder. The complexity for applications is increasing maybe a bit too much at this point already... I guess you would agree that it's best to power up the sensor when sub-device node is opened and do all necessary setup before any subdev file operation is commenced. For that I'm just looking forward for the common struct clk to be merged and all platforms to be converted to it. So we can use a struct clk object to enable sensor clock from subdev drivers level. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add new alpha component control
Hi Hans, On Tuesday 29 November 2011 19:30:25 Hans Verkuil wrote: > On Tuesday, November 29, 2011 19:10:39 Laurent Pinchart wrote: > > On Tuesday 29 November 2011 17:40:10 Sylwester Nawrocki wrote: > > > On 11/29/2011 12:08 PM, Hans Verkuil wrote: > > > > On Monday 28 November 2011 14:02:49 Sylwester Nawrocki wrote: > > > >> On 11/28/2011 01:39 PM, Hans Verkuil wrote: > > > >>> On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote: > > > On 11/28/2011 12:38 PM, Hans Verkuil wrote: > > > > On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: > > > > Here is a patch that updates the range. It also sends a control event > > > > telling any listener that the range has changed. Tested with vivi and > > > > a modified v4l2-ctl. > > > > > > > > The only thing missing is a DocBook entry for that new event flag and > > > > perhaps some more documentation in places. > > > > > > > > Let me know how this works for you, and if it is really needed, then > > > > I can add it to the control framework. > > > > > > Thanks for your work, it's very appreciated. > > > > > > I've tested the patch with s5p-fimc and it works well. I just didn't > > > check the event part yet. > > > > > > I spoke to Kamil as in the past he considered the control range > > > updating at the codec driver. But since separate controls are used for > > > different encoding standards, this is not needed it any more. > > > > > > Nevertheless I have at least two use cases, for the alpha control and > > > for the image sensor driver. In case of the camera sensor, different > > > device revisions may have different step and maximum value for some > > > controls, depending on firmware. > > > By using v4l2_ctrl_range_update() I don't need to invoke lengthy sensor > > > start-up procedure just to find out properties of some controls. > > > > Wouldn't it be confusing for applications to start with a range and have > > it updated at runtime ? > > Good question. It was a nice exercise creating the range_update() function > and it works well, but it this something we want to do? I think that being able to modify the range is a very useful functionality. It's just that in this case the sensor would start with a default range and switch to another based on the model. It would be better if we could start with the right range from the start. > If we do, then we should mark such controls with a flag (_VOLATILE_RANGE or > something like that) so apps know that the range isn't fixed. > > I think that when it comes to apps writing or reading such a control > directly it isn't a problem. But for applications that automatically > generate control panels (xawtv et al) it is rather complex to support such > things. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Tue Nov 29 19:00:16 CET 2011 git hash:36d36b884c745c507d9b3f60eb42925749f7d758 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add new alpha component control
On Tuesday, November 29, 2011 19:10:39 Laurent Pinchart wrote: > Hi Sylwester, > > On Tuesday 29 November 2011 17:40:10 Sylwester Nawrocki wrote: > > On 11/29/2011 12:08 PM, Hans Verkuil wrote: > > > On Monday 28 November 2011 14:02:49 Sylwester Nawrocki wrote: > > >> On 11/28/2011 01:39 PM, Hans Verkuil wrote: > > >>> On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote: > > On 11/28/2011 12:38 PM, Hans Verkuil wrote: > > > On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: > > > Here is a patch that updates the range. It also sends a control event > > > telling any listener that the range has changed. Tested with vivi and a > > > modified v4l2-ctl. > > > > > > The only thing missing is a DocBook entry for that new event flag and > > > perhaps some more documentation in places. > > > > > > Let me know how this works for you, and if it is really needed, then I > > > can add it to the control framework. > > > > Thanks for your work, it's very appreciated. > > > > I've tested the patch with s5p-fimc and it works well. I just didn't check > > the event part yet. > > > > I spoke to Kamil as in the past he considered the control range updating > > at the codec driver. But since separate controls are used for different > > encoding standards, this is not needed it any more. > > > > Nevertheless I have at least two use cases, for the alpha control and > > for the image sensor driver. In case of the camera sensor, different device > > revisions may have different step and maximum value for some controls, > > depending on firmware. > > By using v4l2_ctrl_range_update() I don't need to invoke lengthy sensor > > start-up procedure just to find out properties of some controls. > > Wouldn't it be confusing for applications to start with a range and have it > updated at runtime ? Good question. It was a nice exercise creating the range_update() function and it works well, but it this something we want to do? If we do, then we should mark such controls with a flag (_VOLATILE_RANGE or something like that) so apps know that the range isn't fixed. I think that when it comes to apps writing or reading such a control directly it isn't a problem. But for applications that automatically generate control panels (xawtv et al) it is rather complex to support such things. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
Hi Sylwester, On Tuesday 29 November 2011 18:19:09 Sylwester Nawrocki wrote: > On 11/29/2011 11:26 AM, Laurent Pinchart wrote: > > NV24 and NV42 are planar YCbCr 4:4:4 and YCrCb 4:4:4 formats with a > > luma plane followed by an interleaved chroma plane. > > > > Signed-off-by: Laurent Pinchart > > --- > > ... > > > + > > + > > + > > + > > > > + > > I think this comment chunk is redundant, it's just for emacs configuration. > Every time I open the file containing litter like this I get a > not-so-useful message, asking if I want to load the variables defined > there or not. I agree. I'll remove it. Thanks for pointing it out. > I'm considering a patch cleaning up the Docbook from this emacs stuff, as I > also made a mistake copying this comment when adding NV12M, NV12MT formats. > > Looks like most of people are doing that, e.g. see > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg38637.html > > ;) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add new alpha component control
Hi Sylwester, On Tuesday 29 November 2011 17:40:10 Sylwester Nawrocki wrote: > On 11/29/2011 12:08 PM, Hans Verkuil wrote: > > On Monday 28 November 2011 14:02:49 Sylwester Nawrocki wrote: > >> On 11/28/2011 01:39 PM, Hans Verkuil wrote: > >>> On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote: > On 11/28/2011 12:38 PM, Hans Verkuil wrote: > > On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote: > > Here is a patch that updates the range. It also sends a control event > > telling any listener that the range has changed. Tested with vivi and a > > modified v4l2-ctl. > > > > The only thing missing is a DocBook entry for that new event flag and > > perhaps some more documentation in places. > > > > Let me know how this works for you, and if it is really needed, then I > > can add it to the control framework. > > Thanks for your work, it's very appreciated. > > I've tested the patch with s5p-fimc and it works well. I just didn't check > the event part yet. > > I spoke to Kamil as in the past he considered the control range updating > at the codec driver. But since separate controls are used for different > encoding standards, this is not needed it any more. > > Nevertheless I have at least two use cases, for the alpha control and > for the image sensor driver. In case of the camera sensor, different device > revisions may have different step and maximum value for some controls, > depending on firmware. > By using v4l2_ctrl_range_update() I don't need to invoke lengthy sensor > start-up procedure just to find out properties of some controls. Wouldn't it be confusing for applications to start with a range and have it updated at runtime ? > It would be nice to have this enhancement in mainline. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] s5p-fimc: Add support for alpha component configuration
On Exynos SoCs the FIMC IP allows to configure globally the alpha component
of all pixels for V4L2_PIX_FMT_RGB32, V4L2_PIX_FMT_RGB555 and
V4L2_PIX_FMT_RGB444 image formats. This patch adds a v4l2 control in order
to let the applications control the alpha component value.
The alpha value range depends on the pixel format, for RGB32 it's 0..255
(8-bits), for RGB555 - 0..1 (1-bit) and for RGB444 - 0..15 (4-bits). The
v4l2 control range is always 0..255 and the alpha component data width is
determined by currently set format on the V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE
buffer queue. The applications need to match the alpha channel value range
and the pixel format since the driver will clamp the alpha component.
Depending on fourcc the valid alpha bits are:
- V4L2_PIX_FMT_RGB555 [0]
- V4L2_PIX_FMT_RGB444 [3:0]
- V4L2_PIX_FMT_RGB32 [7:0]
When switching to a pixel format with smaller alpha component width the
currently set alpha value will be clamped to maximum value valid for current
format. When switching to a format with wider alpha the alpha value remains
unchanged.
The variant description data structure is extended with a new entry so an
additional control is created only where really supported by the hardware.
V4L2_PIX_FMT_RGB555 and V4L2_PIX_FMT_RGB444 formats are only valid for
V4L2_BUF_TYPE_VIDEO_CAPTURE buffer queue.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 16
drivers/media/video/s5p-fimc/fimc-core.c| 130 +--
drivers/media/video/s5p-fimc/fimc-core.h| 31 ++-
drivers/media/video/s5p-fimc/fimc-reg.c | 53 +---
drivers/media/video/s5p-fimc/regs-fimc.h|5 +
5 files changed, 193 insertions(+), 42 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 82d9ab6..8ca4d32 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -63,6 +63,8 @@ static int fimc_init_capture(struct fimc_dev *fimc)
fimc_hw_set_effect(ctx, false);
fimc_hw_set_output_path(ctx);
fimc_hw_set_out_dma(ctx);
+ if (fimc->variant->has_alpha)
+ fimc_hw_set_rgb_alpha(ctx);
clear_bit(ST_CAPT_APPLY_CFG, &fimc->state);
}
spin_unlock_irqrestore(&fimc->slock, flags);
@@ -154,6 +156,8 @@ int fimc_capture_config_update(struct fimc_ctx *ctx)
fimc_hw_set_rotation(ctx);
fimc_prepare_dma_offset(ctx, &ctx->d_frame);
fimc_hw_set_out_dma(ctx);
+ if (fimc->variant->has_alpha)
+ fimc_hw_set_rgb_alpha(ctx);
clear_bit(ST_CAPT_APPLY_CFG, &fimc->state);
}
spin_unlock(&ctx->slock);
@@ -812,6 +816,12 @@ static int fimc_capture_set_format(struct fimc_dev *fimc,
struct v4l2_format *f)
FIMC_SD_PAD_SOURCE);
if (!ff->fmt)
return -EINVAL;
+
+ /* Update RGB Alpha control state and value range */
+ ret = fimc_alpha_ctrl_update(ctx);
+ if (ret)
+ return ret;
+
/* Try to match format at the host and the sensor */
if (!fimc->vid_cap.user_subdev_api) {
mf->code = ff->fmt->mbus_code;
@@ -1216,6 +1226,7 @@ static int fimc_subdev_set_fmt(struct v4l2_subdev *sd,
struct fimc_ctx *ctx = fimc->vid_cap.ctx;
struct fimc_frame *ff;
struct fimc_fmt *ffmt;
+ int ret;
dbg("pad%d: code: 0x%x, %dx%d",
fmt->pad, mf->code, mf->width, mf->height);
@@ -1235,6 +1246,11 @@ static int fimc_subdev_set_fmt(struct v4l2_subdev *sd,
*mf = fmt->format;
return 0;
}
+ /* Update RGB Alpha control state and value range */
+ ret = fimc_alpha_ctrl_update(ctx);
+ if (ret)
+ return ret;
+
fimc_capture_mark_jpeg_xfer(ctx, fimc_fmt_is_jpeg(ffmt->color));
ff = fmt->pad == FIMC_SD_PAD_SINK ?
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 567e9ea..57d9e99 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -52,13 +52,29 @@ static struct fimc_fmt fimc_formats[] = {
.colplanes = 1,
.flags = FMT_FLAGS_M2M,
}, {
- .name = "XRGB-8-8-8-8, 32 bpp",
+ .name = "ARGB, 32 bpp",
.fourcc = V4L2_PIX_FMT_RGB32,
.depth = { 32 },
.color = S5P_FIMC_RGB888,
.memplanes = 1,
.colplanes = 1,
- .flags = FMT_FLAGS_M2M,
+ .flags = FMT_FLAGS_M2M | FMT_HAS_ALPHA,
+ }, {
+ .name
[PATCH 1/3] v4l-ctrl: Add a method for control value range update
From: Hans Verkuil
---
This patch is not for merging, I'm just resending it as patch 3/3 depends on
this one.
---
drivers/media/video/v4l2-ctrls.c | 147 +++---
include/linux/videodev2.h|1 +
include/media/v4l2-ctrls.h | 17 +
3 files changed, 122 insertions(+), 43 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 5552f81..b59b00a 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -912,8 +912,7 @@ static int new_to_user(struct v4l2_ext_control *c,
}
/* Copy the new value to the current value. */
-static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl,
- bool update_inactive)
+static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32
ch_flags)
{
bool changed = false;
@@ -937,8 +936,8 @@ static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl
*ctrl,
ctrl->cur.val = ctrl->val;
break;
}
- if (update_inactive) {
- /* Note: update_inactive can only be true for auto clusters. */
+ if (ch_flags & V4L2_EVENT_CTRL_CH_FLAGS) {
+ /* Note: CH_FLAGS is only set for auto clusters. */
ctrl->flags &=
~(V4L2_CTRL_FLAG_INACTIVE | V4L2_CTRL_FLAG_VOLATILE);
if (!is_cur_manual(ctrl->cluster[0])) {
@@ -947,14 +946,13 @@ static void new_to_cur(struct v4l2_fh *fh, struct
v4l2_ctrl *ctrl,
ctrl->flags |= V4L2_CTRL_FLAG_VOLATILE;
}
}
- if (changed || update_inactive) {
+ if (changed || ch_flags) {
/* If a control was changed that was not one of the controls
modified by the application, then send the event to all. */
if (!ctrl->is_new)
fh = NULL;
send_event(fh, ctrl,
- (changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) |
- (update_inactive ? V4L2_EVENT_CTRL_CH_FLAGS : 0));
+ (changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) | ch_flags);
}
}
@@ -1288,6 +1286,40 @@ unlock:
return 0;
}
+/* Control range checking */
+static int check_range(enum v4l2_ctrl_type type,
+ s32 min, s32 max, u32 step, s32 def)
+{
+ switch (type) {
+ case V4L2_CTRL_TYPE_BOOLEAN:
+ if (step != 1 || max > 1 || min < 0)
+ return -ERANGE;
+ /* fall through */
+ case V4L2_CTRL_TYPE_INTEGER:
+ if (step <= 0 || min > max || def < min || def > max)
+ return -ERANGE;
+ return 0;
+ case V4L2_CTRL_TYPE_BITMASK:
+ if (step || min || !max || (def & ~max))
+ return -ERANGE;
+ return 0;
+ case V4L2_CTRL_TYPE_MENU:
+ if (min > max || def < min || def > max)
+ return -ERANGE;
+ /* Note: step == menu_skip_mask for menu controls.
+ So here we check if the default value is masked out. */
+ if (step && ((1 << def) & step))
+ return -EINVAL;
+ return 0;
+ case V4L2_CTRL_TYPE_STRING:
+ if (min > max || min < 0 || step < 1 || def)
+ return -ERANGE;
+ return 0;
+ default:
+ return 0;
+ }
+}
+
/* Add a new control */
static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
@@ -1297,32 +1329,20 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
{
struct v4l2_ctrl *ctrl;
unsigned sz_extra = 0;
+ int err;
if (hdl->error)
return NULL;
/* Sanity checks */
if (id == 0 || name == NULL || id >= V4L2_CID_PRIVATE_BASE ||
- (type == V4L2_CTRL_TYPE_INTEGER && step == 0) ||
- (type == V4L2_CTRL_TYPE_BITMASK && max == 0) ||
- (type == V4L2_CTRL_TYPE_MENU && qmenu == NULL) ||
- (type == V4L2_CTRL_TYPE_STRING && max == 0)) {
- handler_set_err(hdl, -ERANGE);
- return NULL;
- }
- if (type != V4L2_CTRL_TYPE_BITMASK && max < min) {
+ (type == V4L2_CTRL_TYPE_MENU && qmenu == NULL)) {
handler_set_err(hdl, -ERANGE);
return NULL;
}
- if ((type == V4L2_CTRL_TYPE_INTEGER ||
-type == V4L2_CTRL_TYPE_MENU ||
-type == V4L2_CTRL_TYPE_BOOLEAN) &&
- (def < min || def > max)) {
- handler_set_err(hdl, -ERANGE);
- return NULL;
- }
- if (type == V4L2_CTRL_TYPE_BITMASK && ((def & ~max) || min || step)) {
- handler_set_err(hdl, -ERANGE);
+ err = check_range(type,
[PATCH v3 2/3] v4l: Add new alpha component control
The V4L2_CID_ALPHA_COMPONENT control is intended for the video capture
or memory-to-memory devices that are capable of setting up the per-pixel
alpha component to some arbitrary value. It allows to set the alpha
component for all pixels to an arbitrary value.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
Acked-by: Laurent Pinchart
---
The only change since v2 is removed limitation of maximum value to 0xff.
---
Documentation/DocBook/media/v4l/compat.xml | 11
Documentation/DocBook/media/v4l/controls.xml | 25 +++
.../DocBook/media/v4l/pixfmt-packed-rgb.xml|7 -
drivers/media/video/v4l2-ctrls.c |1 +
include/linux/videodev2.h |6 ++--
5 files changed, 39 insertions(+), 11 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/compat.xml
b/Documentation/DocBook/media/v4l/compat.xml
index b68698f..0adda43 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2379,6 +2379,17 @@ that used it. It was originally scheduled for removal in
2.6.35.
+
+ V4L2 in Linux 3.3
+
+
+ Added V4L2_CID_ALPHA_COMPONENT control
+ to the User controls class.
+
+
+
+
+
Relation of V4L2 to other Linux multimedia APIs
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 3bc5ee8..4fd83c0 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -324,12 +324,6 @@ minimum value disables backlight compensation.
(usually a microscope).
- V4L2_CID_LASTP1
-
- End of the predefined control IDs (currently
-V4L2_CID_ILLUMINATORS_2 + 1).
-
-
V4L2_CID_MIN_BUFFERS_FOR_CAPTURE
integer
This is a read-only control that can be read by the
application
@@ -345,6 +339,25 @@ and used as a hint to determine the number of OUTPUT
buffers to pass to REQBUFS.
The value is the minimum number of OUTPUT buffers that is necessary for
hardware
to work.
+
+ V4L2_CID_ALPHA_COMPONENT
+ integer
+Sets the alpha color component on the capture device or on
+ the capture buffer queue of a mem-to-mem device. When a mem-to-mem
+ device produces frame format that includes an alpha component
+ (e.g. packed RGB image formats)
+ and the alpha value is not defined by the mem-to-mem input data
+ this control lets you select the alpha component value of all
+ pixels. It is applicable to any pixel format that contains an alpha
+ component.
+
+
+
+ V4L2_CID_LASTP1
+
+ End of the predefined control IDs (currently
+ V4L2_CID_ALPHA_COMPONENT + 1).
+
V4L2_CID_PRIVATE_BASE
diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
index 4db272b..c13278b 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -428,8 +428,11 @@ colorspace
V4L2_COLORSPACE_SRGB.
Bit 7 is the most significant bit. The value of a = alpha
bits is undefined when reading from the driver, ignored when writing
to the driver, except when alpha blending has been negotiated for a
-Video Overlay or Video Output Overlay.
+Video Overlay or
+Video Output Overlay or when alpha component has been configured
+for a Video Capture by means of V4L2_CID_ALPHA_COMPONENT
+ control.
V4L2_PIX_FMT_BGR24 4 × 4 pixel
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index b59b00a..03fcb93 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -466,6 +466,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_ILLUMINATORS_2: return "Illuminator 2";
case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE: return "Minimum Number of
Capture Buffers";
case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT: return "Minimum Number of
Output Buffers";
+ case V4L2_CID_ALPHA_COMPONENT: return "Alpha Component";
/* MPEG controls */
/* Keep the order of the 'case's the same as in videodev2.h! */
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 22e632a..2f6bbba 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1204,10 +1204,10 @@ enum v4l2_colorfx {
#define V4L2_CID_MIN_BUFFERS_FOR_CAPTURE (V4L2_CID_BASE+39)
#define V4L2_CID_MIN_BUFFERS_FOR_OUTPUT(V4L2_CID_BASE+40)
-/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+41)
+#d
[PATCH/RFC v3] Add new V4L2_CID_ALPHA_COMPONENT control
Hello, This changeset adds new V4L2_CID_ALPHA_COMPONENT control that allows to configure an alpha component of all pixels on the video capture device or on capture queue of a mem-to-mem device. This is meant for devices that allow to set a per-pixel alpha at the pipeline output to a desired value and where the input alpha component doesn't influence the output alpha value. The second patch adds the control to s5p-fimc video capture and mem-to-mem driver. This changset also does a minor cleanup at the user controls DocBook chapter. Changes since v2: - removed limitation of maximum value for the V4L2_CID_ALPHA_COMPONENT control to 0xff in v4l core - the driver now uses function v4l2_ctrl_update_range() for the control range update according to selected colour format Changes since v1: - rename V4L2_CID_COLOR_ALPHA to V4L2_CID_ALPHA_COMPONENT, - the documentation improvements. Hans Verkuil (1): v4l-ctrl: Add a method for control value range update Sylwester Nawrocki (2): v4l: Add new alpha component control s5p-fimc: Add support for alpha component configuration Documentation/DocBook/media/v4l/compat.xml | 11 ++ Documentation/DocBook/media/v4l/controls.xml | 25 +++- .../DocBook/media/v4l/pixfmt-packed-rgb.xml|7 +- drivers/media/video/s5p-fimc/fimc-capture.c| 16 ++ drivers/media/video/s5p-fimc/fimc-core.c | 130 ++ drivers/media/video/s5p-fimc/fimc-core.h | 31 - drivers/media/video/s5p-fimc/fimc-reg.c| 53 ++-- drivers/media/video/s5p-fimc/regs-fimc.h |5 + drivers/media/video/v4l2-ctrls.c | 148 ++-- include/linux/videodev2.h |7 +- include/media/v4l2-ctrls.h | 17 +++ 11 files changed, 354 insertions(+), 96 deletions(-) -- Regards, Sylwester Nawrocki Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] JPEG encoders control class
On Mon, 28 Nov 2011 19:48:28 +0100 Luca Risolia wrote: > > Note that et61x251 and sn9c102 are going to be deprecated and removed at > > some > > time in the future (gspca will support these devices). > > Has this been discussed yet? Also, last time I tried the gspca driver > with a number of V4L2-compliant applications, it did not support at all > or work well for all the sn9c1xx-based devices I have here, which are > both controllers and sensors the manufacturer sent to me when developing > the driver with their collaboration. I also don't understand why the > gspca driver has been accepted in the mainline kernel in the first > place, despite the fact the sn9c1xx has been present in the kernel since > long time and already supported many devices at the time the gspca was > submitted. Maybe it's better to remove the duplicate code form the gspca > driver and add the different parts (if any) to the sn9c1xx. Hi Luca, Removing the sn9c102 is on the way for a long time. I think we were just waiting for a message from you! Why is gspca in the kernel? Because of its design: all the system / v4l2 interface are in the main driver, while the subdrivers only deal with the specific device exchanges. This simplifies development and maintenance. At the beginning, the gspca did not handle the sn9c102 webcams (but some Sonix based webcams were already handled only by gspca). From time to time, there were users saying that their webcams did not work correctly with the sn9c102, and that they worked better with gspca. So, we moved their IDs to gspca. Now, the sonixjb and sonixj subdrivers handle many more sensors than the sn9c102 with less problems. Indeed, there are still problems, but, as I have only 3 webcams (none with Sonix chips), I must wait for user reports and fix them. As you have some Sonix based webcams, and as you had contact with the manufacturers, you should easily find if there are wrong sequences in the gspca subdrivers and/or what could be done for a better support. This would help... Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/3] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
Hi Laurent, On 11/29/2011 11:26 AM, Laurent Pinchart wrote: > NV24 and NV42 are planar YCbCr 4:4:4 and YCrCb 4:4:4 formats with a > luma plane followed by an interleaved chroma plane. > > Signed-off-by: Laurent Pinchart > --- ... > + > + > + > + > + I think this comment chunk is redundant, it's just for emacs configuration. Every time I open the file containing litter like this I get a not-so-useful message, asking if I want to load the variables defined there or not. I'm considering a patch cleaning up the Docbook from this emacs stuff, as I also made a mistake copying this comment when adding NV12M, NV12MT formats. Looks like most of people are doing that, e.g. see http://www.mail-archive.com/linux-media@vger.kernel.org/msg38637.html ;) -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resent] Fix logic in sanity check
Hi Thomas, On 11/29/2011 01:26 PM, Thomas Jarosch wrote: > On Sunday, 20. November 2011 18:26:13 Sylwester Nawrocki wrote: >> If you care to resend the patch, please add "m5mols:" as a subsystem name >> in the subject so it looks something like: >> >> [PATCH ...] m5mols: Fix ... >> --- drivers/media/video/m5mols/m5mols_core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) > > I'll resend something soonish. Though feel free to > fix these cosmetic issues on the fly, too. OK, sorry to bother. I'll pick the patch and amend it when adding to a pull request. -- Thanks! Sylwester > > Cheers, > Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add new alpha component control
Hi Hans,
On 11/29/2011 12:08 PM, Hans Verkuil wrote:
> On Monday 28 November 2011 14:02:49 Sylwester Nawrocki wrote:
>> On 11/28/2011 01:39 PM, Hans Verkuil wrote:
>>> On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote:
On 11/28/2011 12:38 PM, Hans Verkuil wrote:
> On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote:
>
> Here is a patch that updates the range. It also sends a control event telling
> any listener that the range has changed. Tested with vivi and a modified
> v4l2-ctl.
>
> The only thing missing is a DocBook entry for that new event flag and perhaps
> some more documentation in places.
>
> Let me know how this works for you, and if it is really needed, then I can
> add it to the control framework.
Thanks for your work, it's very appreciated.
I've tested the patch with s5p-fimc and it works well. I just didn't check
the event part yet.
I spoke to Kamil as in the past he considered the control range updating
at the codec driver. But since separate controls are used for different
encoding standards, this is not needed it any more.
Nevertheless I have at least two use cases, for the alpha control and
for the image sensor driver. In case of the camera sensor, different device
revisions may have different step and maximum value for some controls,
depending on firmware.
By using v4l2_ctrl_range_update() I don't need to invoke lengthy sensor
start-up procedure just to find out properties of some controls.
It would be nice to have this enhancement in mainline.
>
> Regards,
>
> Hans
>
> index 0f415da..d7ca646 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -913,8 +913,7 @@ static int new_to_user(struct v4l2_ext_control *c,
> }
>
> /* Copy the new value to the current value. */
> -static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl,
> - bool update_inactive)
> +static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32
> ch_flags)
> {
> bool changed = false;
>
> @@ -938,8 +937,8 @@ static void new_to_cur(struct v4l2_fh *fh, struct
> v4l2_ctrl *ctrl,
> ctrl->cur.val = ctrl->val;
> break;
> }
> - if (update_inactive) {
> - /* Note: update_inactive can only be true for auto clusters. */
> + if (ch_flags & V4L2_EVENT_CTRL_CH_FLAGS) {
> + /* Note: CH_FLAGS is only set for auto clusters. */
> ctrl->flags &=
> ~(V4L2_CTRL_FLAG_INACTIVE | V4L2_CTRL_FLAG_VOLATILE);
> if (!is_cur_manual(ctrl->cluster[0])) {
> @@ -949,14 +948,13 @@ static void new_to_cur(struct v4l2_fh *fh, struct
> v4l2_ctrl *ctrl,
> }
> fh = NULL;
> }
> - if (changed || update_inactive) {
> + if (changed || ch_flags) {
> /* If a control was changed that was not one of the controls
> modified by the application, then send the event to all. */
> if (!ctrl->is_new)
> fh = NULL;
> send_event(fh, ctrl,
> - (changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) |
> - (update_inactive ? V4L2_EVENT_CTRL_CH_FLAGS : 0));
> + (changed ? V4L2_EVENT_CTRL_CH_VALUE : 0) | ch_flags);
> }
> }
>
> @@ -1290,6 +1288,40 @@ unlock:
> return 0;
> }
>
> +/* Control range checking */
> +static int check_range(enum v4l2_ctrl_type type,
> + s32 min, s32 max, u32 step, s32 def)
> +{
> + switch (type) {
> + case V4L2_CTRL_TYPE_BOOLEAN:
> + if (step != 1 || max > 1 || min < 0)
> + return -ERANGE;
> + /* fall through */
> + case V4L2_CTRL_TYPE_INTEGER:
> + if (step <= 0 || min > max || def < min || def > max)
> + return -ERANGE;
> + return 0;
> + case V4L2_CTRL_TYPE_BITMASK:
> + if (step || min || !max || (def & ~max))
> + return -ERANGE;
> + return 0;
> + case V4L2_CTRL_TYPE_MENU:
> + if (min > max || def < min || def > max)
> + return -ERANGE;
> + /* Note: step == menu_skip_mask for menu controls.
> +So here we check if the default value is masked out. */
> + if (step && ((1 << def) & step))
> + return -EINVAL;
> + return 0;
> + case V4L2_CTRL_TYPE_STRING:
> + if (min > max || min < 0 || step < 1 || def)
> + return -ERANGE;
> + return 0;
> + default:
> + return 0;
> + }
> +}
> +
> /* Add a new control */
> static struct v4l2_ctrl *v4l2_ctrl_new(struct v4l2_ctrl_handler *hdl,
> const struct v4l2_ctrl_ops *ops,
> @@ -1299,32 +1331,20 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl,
> {
> struct v4l2_ctrl *ctrl;
>
Re: drm pixel formats update
On Tue, 2011-11-29 at 13:10 +0100, Laurent Pinchart wrote: > To make it perfectly clear, I want to emphasize that I'm not trying to > replace > DRM, FBDEV and V4L2 with a new shared subsystem. What I would like to see in > the (near future) is collaboration and sharing of core features that make > sense to share. I believe we should address this from a "pain point" point of > view. The one that lead me to writing this e-mail is that developing a driver > that implements both the DRM and FBDEV APIs for video output currently > requires various similar structures, and code to translate between all of > them. That code can't be shared between multiple drivers, is error-prone, and > painful to maintin. We've been in the same situation with OMAP display driver for years. The same low level display driver is used by FB, V4L2 and now DRM drivers, so I didn't have much choice but to implement omapdss versions for things like video timings and color formats. I've been planning to write code for this almost as long as omapdss has had this problem, but there's always been yet-another-important-thing-to-do. So good that somebody finally brought this up =). I'm happy to test any code related to this with omapdss. Tomi signature.asc Description: This is a digitally signed message part
[PATCH] stv090x: implement function for reading uncorrected blocks count
This patch add support for reading UNC blocks for stv090x frontend.
Partially based on stv0900 code by Abylay Ospan
Signed-off-by: Mariusz Bialonczyk
---
drivers/media/dvb/frontends/stv090x.c | 32 +++-
1 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/frontends/stv090x.c
b/drivers/media/dvb/frontends/stv090x.c
index 52d8712..ad6141f 100644
--- a/drivers/media/dvb/frontends/stv090x.c
+++ b/drivers/media/dvb/frontends/stv090x.c
@@ -3687,6 +3687,35 @@ static int stv090x_read_cnr(struct dvb_frontend *fe, u16
*cnr)
return 0;
}
+static int stv090x_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
+{
+ struct stv090x_state *state = fe->demodulator_priv;
+ u32 reg_0, reg_1;
+ u32 val_header_err, val_packet_err;
+
+ switch (state->delsys) {
+ case STV090x_DVBS2:
+ /* DVB-S2 delineator error count */
+
+ /* retrieving number for erronous headers */
+ reg_1 = stv090x_read_reg(state, STV090x_P1_BBFCRCKO1);
+ reg_0 = stv090x_read_reg(state, STV090x_P1_BBFCRCKO0);
+ val_header_err = MAKEWORD16(reg_1, reg_0);
+
+ /* retrieving number for erronous packets */
+ reg_1 = stv090x_read_reg(state, STV090x_P1_UPCRCKO1);
+ reg_0 = stv090x_read_reg(state, STV090x_P1_UPCRCKO0);
+ val_packet_err = MAKEWORD16(reg_1, reg_0);
+
+ *ucblocks = val_packet_err + val_header_err;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int stv090x_set_tone(struct dvb_frontend *fe, fe_sec_tone_mode_t tone)
{
struct stv090x_state *state = fe->demodulator_priv;
@@ -4748,7 +4777,8 @@ static struct dvb_frontend_ops stv090x_ops = {
.read_status= stv090x_read_status,
.read_ber = stv090x_read_per,
.read_signal_strength = stv090x_read_signal_strength,
- .read_snr = stv090x_read_cnr
+ .read_snr = stv090x_read_cnr,
+ .read_ucblocks = stv090x_read_ucblocks
};
--
1.7.7.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gnutv should not ignore SIGPIPE
On 11-11-25 08:36 AM, Brian J. Murrell wrote:
>
> Yes, that is the other way to skin that cat I suppose.
I couldn't figure out what the right thing for writer thread to do to
terminate the application so I used SIGPIPE instead. Here's the patch:
--- linuxtv-dvb-apps-1.1.1+rev1273~/util/gnutv/gnutv_data.c 2011-11-28
09:10:33.010407011 -0500
+++ linuxtv-dvb-apps-1.1.1+rev1273/util/gnutv/gnutv_data.c 2011-11-28
09:10:26.446258282 -0500
@@ -265,7 +265,10 @@
while(written < size) {
int tmp = write(outfd, buf + written, size - written);
if (tmp == -1) {
- if (errno != EINTR) {
+ if (errno == EPIPE) {
+ fprintf(stderr, "processing EPIPE\n");
+ return 0;
+ } else if (errno != EINTR) {
fprintf(stderr, "Write error: %m\n");
break;
}
--- linuxtv-dvb-apps-1.1.1+rev1273~/util/gnutv/gnutv.c 2011-11-28
10:13:13.294445131 -0500
+++ linuxtv-dvb-apps-1.1.1+rev1273/util/gnutv/gnutv.c.new 2011-11-28
10:13:10.510492321 -0500
@@ -262,7 +262,7 @@
// setup any signals
signal(SIGINT, signal_handler);
- signal(SIGPIPE, SIG_IGN);
+ signal(SIGPIPE, signal_handler);
// start the CA stuff
gnutv_ca_params.adapter_id = adapter_id;
signature.asc
Description: OpenPGP digital signature
Re: drm pixel formats update
On Tuesday 29 November 2011 13:10:35 Laurent Pinchart wrote: > Hi Ville, > > Sorry for the late reply. > > (Cross-posting to the linux-fbdev and linux-media mailing lists, as the > topics I'm about to discuss are of interest to everybody) > > On Wednesday 16 November 2011 19:42:23 ville.syrj...@linux.intel.com wrote: > > I decided to go all out with the pixel format definitions. Added pretty > > much all of the possible RGB/BGR variations. Just left out ones with > > 16bit components and floats. Also added a whole bunch of YUV formats, > > and 8 bit pseudocolor for good measure. > > > > I'm sure some of the fourccs now clash with the ones used by v4l2, > > but that's life. > > Disclaimer: I realize this is a somehow controversial topic, and I'm not > trying to start a flame war :-) > > What about defining a common set of fourccs for both subsystem (and using > them in FBDEV, which currently uses the V4L2 fourccs) ? > > There's more and more overlap between DRM, FBDEV and V4L2, which results in > confusion for the user and mess in the kernel. I believe cleaning this up > will become more and more important with time, and also probably more and > more difficult if we don't act now. > > There's no way we will all quickly agree on a big picture unified > architecture (I don't even know what it should look like), so I'm thinking > about starting small and see where it will lead us. Sharing fourccs would > be such a first step, and would make it easier for drivers to implement > several of the DRM, FBDEV and V4L2 APIs. > > Another step I'd like to take would be working on sharing the video mode > definitions between subsystems. DRM has struct drm_mode_modeinfo and FBDEV > has struct fb_videomode. The former can't be modified as it's used in > userspace APIs, but I believe we should create a common in-kernel > structure to represent modes. This would also make it easier to share the > EDID parser between DRM and FBDEV. > > One issue here is names. I understand that using names from another > subsystem in a driver that has nothing to do with it (like using > V4L2_PIX_FMT_* in DRM, or drm_mode_modeinfo in FBDEV) can be frustrating > for many developers, so I'd like to propose an alternative. We have a > media-related kernel API that is cross-subsystem, that's the media > controller. It uses the prefix media_. We could use more specific versions > of that preview (such as media_video_ and media_display_) as a neutral > ground. I agree. > Another issue is control. It's quite natural to be suspicious about > subsystems we're not familiar with, and giving up control on things we > consider as highly important to other subsystems feels dangerous and > wrong. Once again, media_* could be an answer to this problem. Instead of > trying to push other subsystems to use our APIs (which are, obviously, the > best possible ever, as they're the ones we work on :-)) with the promise > that we will extend them to fullfill their needs if necessary, we could > design new shared structures and core functions together with a media_ > prefix, and make sure they fullfill all the needs from the start. What I > like about this approach is that each of the 3 video-related subsystems > would then benefit from the experience of the other 2. > > To make it perfectly clear, I want to emphasize that I'm not trying to > replace DRM, FBDEV and V4L2 with a new shared subsystem. What I would like > to see in the (near future) is collaboration and sharing of core features > that make sense to share. I believe we should address this from a "pain > point" point of view. The one that lead me to writing this e-mail is that > developing a driver that implements both the DRM and FBDEV APIs for video > output currently requires various similar structures, and code to > translate between all of them. That code can't be shared between multiple > drivers, is error-prone, and painful to maintin. > > I can (and actually would like to) submit an RFC, but I would first like to > hear your opinion on the topic. I have added Jesse Barker to the CC list. I think that to achieve closer cooperation between the various subsystems we need to organize a few days of talks between the main developers to 1) understand each others subsystem, 2) to discover what functionality would be good to share, and 3) figure out some sort of roadmap on how to do this. Linaro might be a suitable organization that can assist with at least the organizational part of setting up such a meeting. They did a good job in the past (in Budapest and Cambourne) with the buffer sharing discussions. One week of discussions/brainstorming between a small(ish) group of developers can be very, very productive in my experience. Regards, Hans > > > If anyone has problems with the way the formats are defined, please > > speak up now! Since only Jesse has bothered to comment on my rantings > > I can only assume people are happy with my approach to things. > > > > These patches sho
Re: [PATCH] em28xx: Add Terratec Cinergy HTC Stick
On 29.11.2011 13:04, Jens Erdmann wrote: > Hi Andreas, > > On Monday, November 28, 2011 05:57:35 PM you wrote: >> Hello Jens, >> >> On 28.11.2011 16:41, Jens Erdmann wrote: >>> Hi folks, >>> >>> just a few quetstions: >>> 1. Why is the device named EM2884_BOARD_CINERGY_HTC_STICK and not >>> >>> EM2884_BOARD_TERRATEC_HTC_STICK like all the other devices from that >>> vendor? Looks inconsistent to me. >> >> that's because it's the product name. Even though TERRATEC is the >> vendor, the TERRATEC series of devices is different from the Cinergy >> series (mostly due to software bundles, IMHO). See their homepage for >> details. >> >> So, TERRATEC_HTC_STICK would be wrong. You could change it to >> TERRATEC_CINERGY_HTC_STICK, if it's important to you. However, following >> the same logic, the TERRATEC H5 should then be called >> TERRATEC_TERRATEC_H5, which seems rather odd. >> >> Btw.: The em28xx driver wrongly lists the H5 as "Terratec Cinergy H5". >> > > Don't get me wrong on this. I am just asking. You have made the desicion > and if you are fine with it its ok. No problem. I was just explaining the rationale. I don't really care whether the constant's name gets changed or not. >>> 2. I stumbled over http://linux.terratec.de/tv_en.html where they list a >>> NXP TDA18271 >>> >>> as used tuner for H5 and HTC Stick devices. I dont have any >>> experience in this kind of stuff but i am just asking. >> >> That's right. >> > > So this should be made like the other devices which are using the TDA18271? > Or is there no driver for this tuner yet? I don't understand your question. Both TERRATEC H5 and Cinergy HTC Stick are already supported by Linux (at least for digital signals, the latter since the patch you're referring to), so a driver for every relevant chip, including TDA18271, is already involved. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH resent] Fix logic in sanity check
Hi Sylwester, On Sunday, 20. November 2011 18:26:13 Sylwester Nawrocki wrote: > If you care to resend the patch, please add "m5mols:" as a subsystem name > in the subject so it looks something like: > > [PATCH ...] m5mols: Fix ... > > >> --- > >> > >> drivers/media/video/m5mols/m5mols_core.c |2 +- > >> 1 files changed, 1 insertions(+), 1 deletions(-) I'll resend something soonish. Though feel free to fix these cosmetic issues on the fly, too. Cheers, Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] em28xx: Add Terratec Cinergy HTC Stick
Hi Andreas, On Monday, November 28, 2011 05:57:35 PM you wrote: > Hello Jens, > > On 28.11.2011 16:41, Jens Erdmann wrote: > > Hi folks, > > > > just a few quetstions: > > 1. Why is the device named EM2884_BOARD_CINERGY_HTC_STICK and not > > > > EM2884_BOARD_TERRATEC_HTC_STICK like all the other devices from that > > vendor? Looks inconsistent to me. > > that's because it's the product name. Even though TERRATEC is the > vendor, the TERRATEC series of devices is different from the Cinergy > series (mostly due to software bundles, IMHO). See their homepage for > details. > > So, TERRATEC_HTC_STICK would be wrong. You could change it to > TERRATEC_CINERGY_HTC_STICK, if it's important to you. However, following > the same logic, the TERRATEC H5 should then be called > TERRATEC_TERRATEC_H5, which seems rather odd. > > Btw.: The em28xx driver wrongly lists the H5 as "Terratec Cinergy H5". > Don't get me wrong on this. I am just asking. You have made the desicion and if you are fine with it its ok. > > 2. I stumbled over http://linux.terratec.de/tv_en.html where they list a > > NXP TDA18271 > > > > as used tuner for H5 and HTC Stick devices. I dont have any > > experience in this kind of stuff but i am just asking. > > That's right. > So this should be made like the other devices which are using the TDA18271? Or is there no driver for this tuner yet? Regards, Jens PS: Thanks to Antti Palosaari for the detailed explanation. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: drm pixel formats update
Hi Ville, Sorry for the late reply. (Cross-posting to the linux-fbdev and linux-media mailing lists, as the topics I'm about to discuss are of interest to everybody) On Wednesday 16 November 2011 19:42:23 ville.syrj...@linux.intel.com wrote: > I decided to go all out with the pixel format definitions. Added pretty > much all of the possible RGB/BGR variations. Just left out ones with > 16bit components and floats. Also added a whole bunch of YUV formats, > and 8 bit pseudocolor for good measure. > > I'm sure some of the fourccs now clash with the ones used by v4l2, > but that's life. Disclaimer: I realize this is a somehow controversial topic, and I'm not trying to start a flame war :-) What about defining a common set of fourccs for both subsystem (and using them in FBDEV, which currently uses the V4L2 fourccs) ? There's more and more overlap between DRM, FBDEV and V4L2, which results in confusion for the user and mess in the kernel. I believe cleaning this up will become more and more important with time, and also probably more and more difficult if we don't act now. There's no way we will all quickly agree on a big picture unified architecture (I don't even know what it should look like), so I'm thinking about starting small and see where it will lead us. Sharing fourccs would be such a first step, and would make it easier for drivers to implement several of the DRM, FBDEV and V4L2 APIs. Another step I'd like to take would be working on sharing the video mode definitions between subsystems. DRM has struct drm_mode_modeinfo and FBDEV has struct fb_videomode. The former can't be modified as it's used in userspace APIs, but I believe we should create a common in-kernel structure to represent modes. This would also make it easier to share the EDID parser between DRM and FBDEV. One issue here is names. I understand that using names from another subsystem in a driver that has nothing to do with it (like using V4L2_PIX_FMT_* in DRM, or drm_mode_modeinfo in FBDEV) can be frustrating for many developers, so I'd like to propose an alternative. We have a media-related kernel API that is cross-subsystem, that's the media controller. It uses the prefix media_. We could use more specific versions of that preview (such as media_video_ and media_display_) as a neutral ground. Another issue is control. It's quite natural to be suspicious about subsystems we're not familiar with, and giving up control on things we consider as highly important to other subsystems feels dangerous and wrong. Once again, media_* could be an answer to this problem. Instead of trying to push other subsystems to use our APIs (which are, obviously, the best possible ever, as they're the ones we work on :-)) with the promise that we will extend them to fullfill their needs if necessary, we could design new shared structures and core functions together with a media_ prefix, and make sure they fullfill all the needs from the start. What I like about this approach is that each of the 3 video-related subsystems would then benefit from the experience of the other 2. To make it perfectly clear, I want to emphasize that I'm not trying to replace DRM, FBDEV and V4L2 with a new shared subsystem. What I would like to see in the (near future) is collaboration and sharing of core features that make sense to share. I believe we should address this from a "pain point" point of view. The one that lead me to writing this e-mail is that developing a driver that implements both the DRM and FBDEV APIs for video output currently requires various similar structures, and code to translate between all of them. That code can't be shared between multiple drivers, is error-prone, and painful to maintin. I can (and actually would like to) submit an RFC, but I would first like to hear your opinion on the topic. > If anyone has problems with the way the formats are defined, please > speak up now! Since only Jesse has bothered to comment on my rantings > I can only assume people are happy with my approach to things. > > These patches should apply on top of Jesse's v3+v5 set... I think. > I sort of lost track of things when the patches started having > different version numbers. At least we're not yet into two digits > numbers ;) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-900H dvb-t regression(s)
On 11/29/2011 12:35 PM, Mauro Carvalho Chehab wrote: > On 29-11-2011 02:53, Fabio M. Di Nitto wrote: >>> [ 7867.776612] tm6000: Found Generic tm6010 board >>> [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 >>> 00 00 00 00 00 00 >> [SNIP] >>> [ 7869.707769] Device has eeprom but is currently unknown >>> >>> and the device will be miss-detected. >> >> I don't think this was ever the case, but I can easily check the dmesg >> output that I collected. > > This may affect your bisect tests. The eeprom was never 00 all the way. > >>> You can fix it by forcing the driver to use "card=9" via modprobe >>> option. >>> >>> Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the >>> audio issue with HVR-900H on analog mode. >> >> Ok, I'll try to grab them. It appears that mail relay from linux-media >> to my inbox is not reliable. > > I've applied them yesterday. tested them already, I sent the results in another email. > >> As for the analog, I should be able to test it today. > > On the tests I've made yesterday after applying Stefan and my patches, > analog is working fine. Audio got corrected by the patches for MSC > (the audio standard used on NTSC and PAL-M). I tested here with both NTSC > and PAL-M standards, and it worked as expected. > > There are some fixes applied yesterday that are related to DTV. One of them > fixes the alloc function call used for the DVB streaming buffer inside the > USB stack: > > - ret = usb_submit_urb(dvb->bulk_urb, GFP_KERNEL); > + ret = usb_submit_urb(dvb->bulk_urb, GFP_ATOMIC); > > The usage of GFP_KERNEL there may fail, causing failures at the DVB stream. > > I'm now seeing if I can make the IR work on HVR-900H. No luck with analog here, but I need to do more investigation as the source might be broken all together. Fabio -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-900H dvb-t regression(s)
On 11/28/2011 10:07 PM, Mauro Carvalho Chehab wrote: > Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the > audio issue with HVR-900H on analog mode. I just finished testing those ones and they seem to fix my specific issue. There is still one thing that puzzles me, but maybe it´s just my misunderstanding on how dvb-t protocol works. > root@cerberus:~# scan -a 0 /home/fabbione/dk > scanning /home/fabbione/dk > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > initial transponder 58600 0 2 9 3 1 3 0 tune to: 58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > 0x 0x0065: pmt_pid 0x0065 DR -- DR1 (running) > 0x 0x00d9: pmt_pid 0x0835 TV 2 -- TV 2 (Lorry) (running) > 0x 0x01a1: pmt_pid 0x0191 DIGI-TV -- Hovedstaden (running) > 0x 0x0066: pmt_pid 0x00c9 DR -- DR2 (running) > 0x 0x006f: pmt_pid 0x0068 DR -- DR Synstolkning (running) > 0x 0x0051: pmt_pid 0x0051 DIGI-TV -- OAD MUX1 (running) > Network Name 'Mux1 kbhv-glx' tune to: 73000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE > WARNING: filter timeout pid 0x0011 > WARNING: filter timeout pid 0x > WARNING: filter timeout pid 0x0010 > dumping lists (6 services) > OAD > MUX1:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:81 > DR1:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:111:121:101 > DR2:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:211:221:102 > DR > Synstolkning:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:111:122:111 > TV 2 > (Lorry):58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2111:2121:217 > Hovedstaden:58600:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:411:421:417 > Done. In my dk file I only specify: > root@cerberus:~# cat /home/fabbione/dk > # Denmark, whole country > # Created from http://www.digi-tv.dk/Indhold_og_tilbud/frekvenser.asp > # and http://www.digi-tv.dk/Sendenettets_opbygning/ > # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy > T 58600 8MHz 2/3 NONE QAM64 8k 1/4 NONE because for simple testing I don´t need to scan the whole spectrum. Now, in some versions of the driver, it automatically picks up 730MHz (I know it´s a good frequency in the area as I get it at my home and shares the same channels as 586). What I noticed is that sometimes it tunes and time outs, sometime it tunes and scan correctly, but with the latest driver from HEAD, it failed completely to tune with the usual error. Not sure if this info might be relevant. As for analog I am not able to even get scantv to find the channel broadcasted from the VCR. I´ll need to investigate if it´s a problem with the VCR/tuner/driver etc. (there is no analog broadcast in dk). So far this is what I get: > scantv -n PAL-DK -f europe-west -c /dev/video0 -C /dev/null > [global] > freqtab = europe-west > > [defaults] > input = Television > norm = PAL-DK > > ioctl: VIDIOC_S_CTRL(id=9963778;value=0): Inappropriate ioctl for device > ioctl: VIDIOC_S_CTRL(id=9963776;value=0): Inappropriate ioctl for device > ioctl: VIDIOC_S_CTRL(id=9963779;value=0): Inappropriate ioctl for device > ioctl: VIDIOC_S_CTRL(id=9963777;value=130): Inappropriate ioctl for device > scanning channel list europe-west... > E2 ( 48.25 MHz): ioctl: VIDIOC_S_CTRL(id=9963785;value=1): Inappropriate > ioctl for device > ioctl: VIDIOC_S_CTRL(id=9963785;value=0): Inappropriate ioctl for device > no station (repeat the above for every single channel and no channels found) The result is pretty much the same with or without tm6000-dvb loaded. Fabio -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-900H dvb-t regression(s)
On 29-11-2011 02:53, Fabio M. Di Nitto wrote: On 11/28/2011 10:07 PM, Mauro Carvalho Chehab wrote: On 28-11-2011 12:41, Fabio M. Di Nitto wrote: Hi all, short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working. Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary. Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time. Based on git bisect: The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004 The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb commit f010dca2e52d8dcc0445d695192df19241afacdb Author: Stefan Ringel Date: Mon May 9 16:53:58 2011 -0300 [media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask move from tm6000_set_reg to tm6000_set_reg_mask Signed-off-by: Stefan Ringel Signed-off-by: Mauro Carvalho Chehab While this commit appears rather innocent, it changes the way some registries are set. the original code did: read_reg... change value write_reg.. (unconditionally) the new code path: read_reg... calculate new value check if it is same if not, write_reg... So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again. something along those lines: diff --git a/drivers/media/video/tm6000/tm6000-core.c b/drivers/media/video/tm6000/tm6000-core.c index 9783616..818f542 100644 --- a/drivers/media/video/tm6000/tm6000-core.c +++ b/drivers/media/video/tm6000/tm6000-core.c @@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8 req, u16 value, new_index = (buf[0]& ~mask) | (index& mask); - if (new_index == index) - return 0; +// if (new_index == index) +// return 0; return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR, req, value, new_index, NULL, 0); but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point. Hmm... It occurred to me that HVR-900H has a bug at device initialization. Sometimes, after a device connect it can't read anything from eeprom. As result, it will print: [ 7867.776612] tm6000: Found Generic tm6010 board [ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [SNIP] [ 7869.707769] Device has eeprom but is currently unknown and the device will be miss-detected. I don't think this was ever the case, but I can easily check the dmesg output that I collected. This may affect your bisect tests. You can fix it by forcing the driver to use "card=9" via modprobe option. Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode. Ok, I'll try to grab them. It appears that mail relay from linux-media to my inbox is not reliable. I've applied them yesterday. As for the analog, I should be able to test it today. On the tests I've made yesterday after applying Stefan and my patches, analog is working fine. Audio got corrected by the patches for MSC (the audio standard used on NTSC and PAL-M). I tested here with both NTSC and PAL-M standards, and it worked as expected. There are some fixes applied yesterday that are related to DTV. One of them fixes the alloc function call used for the DVB streaming buffer inside the USB stack: - ret = usb_submit_urb(dvb->bulk_urb, GFP_KERNEL); + ret = usb_submit_urb(dvb->bulk_urb, GFP_ATOMIC); The usage of GFP_KERNEL there may fail, causing failures at the DVB stream. I'm now seeing if I can make the IR work on HVR-900H. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] convert drivers/media/* to use module_platform_driver()
Hello. On Sat, 2011-11-26 at 14:48 +0800, ext Axel Lin wrote: > This patch converts the drivers in drivers/media/* to use the > module_platform_driver() macro which makes the code smaller and a bit > simpler. > > Cc: Mauro Carvalho Chehab > Cc: Laurent Pinchart > Cc: Kyungmin Park > Cc: Hans Verkuil > Cc: "Richard Röjfors" > Cc: "Matti J. Aaltonen" > Cc: Lucas De Marchi > Cc: Manjunath Hadli > Cc: Muralidharan Karicheri > Cc: Anatolij Gustschin > Cc: Guennadi Liakhovetski > Cc: Marek Szyprowski > Cc: Robert Jarzmik > Cc: Jonathan Corbet > Cc: Daniel Drake > Signed-off-by: Axel Lin > drivers/media/radio/radio-wl1273.c | 17 +--- For the above: Acked-by: Matti J. Aaltonen -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] v4l: Add new alpha component control
On Monday 28 November 2011 14:02:49 Sylwester Nawrocki wrote:
> On 11/28/2011 01:39 PM, Hans Verkuil wrote:
> > On Monday 28 November 2011 13:13:32 Sylwester Nawrocki wrote:
> >> On 11/28/2011 12:38 PM, Hans Verkuil wrote:
> >>> On Friday 25 November 2011 16:39:31 Sylwester Nawrocki wrote:
> This control is intended for the video capture or memory-to-memory
> devices that are capable of setting up a per-pixel alpha component to
> some arbitrary value. The V4L2_CID_ALPHA_COMPONENT control allows to
> set the alpha component for all pixels to a value in range from 0 to
> 255.
>
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
> ---
>
> Documentation/DocBook/media/v4l/compat.xml | 11
> Documentation/DocBook/media/v4l/controls.xml | 25
>
> +++ .../DocBook/media/v4l/pixfmt-packed-rgb.xml
> |
>
> 7 -
> drivers/media/video/v4l2-ctrls.c |7 +
> include/linux/videodev2.h |6 ++--
> 5 files changed, 45 insertions(+), 11 deletions(-)
> >>
> >> ...
> >>
> /* MPEG controls */
> /* Keep the order of the 'case's the same as in videodev2.h! */
>
> @@ -714,6 +715,12 @@ void v4l2_ctrl_fill(u32 id, const char **name,
> enum v4l2_ctrl_type *type, /* Max is calculated as RGB888 that is
> 2^24 */
>
> *max = 0xFF;
> break;
>
> +case V4L2_CID_ALPHA_COMPONENT:
> +*type = V4L2_CTRL_TYPE_INTEGER;
> +*step = 1;
> +*min = 0;
> +*max = 0xff;
> +break;
> >>>
> >>> Hmm. Do we really want to fix the max value to 0xff? The bits assigned
> >>> to the alpha component will vary between 1 (V4L2_PIX_FMT_RGB555X), 4
> >>> (V4L2_PIX_FMT_RGB444) or 8 (V4L2_PIX_FMT_RGB32). It wouldn't surprise
> >>> me to see larger sizes as well in the future (e.g. 16 bits).
> >>>
> >>> I think the max value should be the largest alpha value the hardware
> >>> can support. The application has to set it to the right value that
> >>> corresponds to the currently chosen pixel format. The driver just
> >>> copies the first N bits into the alpha value where N depends on the
> >>> pixel format.
> >>>
> >>> what do you think?
> >>
> >> Yes, ideally the maximum value of the alpha control should be changing
> >> depending on the set colour format.
> >> Currently the maximum value of the control equals maximum alpha value
> >> for the fourcc of maximum colour depth (V4L2_PIX_FMT_RGB32).
> >>
> >> What I found missing was a method for changing the control range
> >> dynamically, without deleting and re-initializing the control handler.
> >> If we reinitalize whole control handler the previously set control
> >> values are lost.
> >
> > You can just change the maximum field of struct v4l2_ctrl on the fly like
> > this:
> > diff --git a/drivers/media/video/v4l2-ctrls.c
> > b/drivers/media/video/v4l2-ctrls.c
> > struct v4l2_ctrl *my_ctrl;
> >
> > v4l2_ctrl_lock(my_ctrl);
> > my_ctrl->maximum = 10;
> > if (my_ctrl->cur.val > my_ctrl->maximum)
> >
> > my_ctrl->cur.val = my_ctrl->maximum;
> >
> > v4l2_ctrl_unlock(my_ctrl);
> >
> > Although this might warrant a v4l2_ctrl_update_range() function that does
> > this for you. Because after a change like this a V4L2_EVENT_CTRL should
> > also be sent.
> >
> > In any case, this functionality isn't hard to add. Just let me know if
> > you need it and I can make a patch for this.
>
> Yes, it would be great if you could prepare a patch for
> v4l2_ctrl_update_range(). Then I could use it in the next iteration of the
> patches, instead of hacking at the driver. IIRC it's not the first time we
> needed changing the control range dynamically.
Here is a patch that updates the range. It also sends a control event telling
any listener that the range has changed. Tested with vivi and a modified
v4l2-ctl.
The only thing missing is a DocBook entry for that new event flag and perhaps
some more documentation in places.
Let me know how this works for you, and if it is really needed, then I can
add it to the control framework.
Regards,
Hans
index 0f415da..d7ca646 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -913,8 +913,7 @@ static int new_to_user(struct v4l2_ext_control *c,
}
/* Copy the new value to the current value. */
-static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl,
- bool update_inactive)
+static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl *ctrl, u32
ch_flags)
{
bool changed = false;
@@ -938,8 +937,8 @@ static void new_to_cur(struct v4l2_fh *fh, struct v4l2_ctrl
*ctrl,
ctrl->cur.val = ctrl->val;
bre
[PATCH v4 3/3] fbdev: sh_mobile_lcdc: Support FOURCC-based format API
Signed-off-by: Laurent Pinchart
---
arch/arm/mach-shmobile/board-ag5evm.c |2 +-
arch/arm/mach-shmobile/board-ap4evb.c |4 +-
arch/arm/mach-shmobile/board-mackerel.c |4 +-
arch/sh/boards/mach-ap325rxa/setup.c|2 +-
arch/sh/boards/mach-ecovec24/setup.c|2 +-
arch/sh/boards/mach-kfr2r09/setup.c |2 +-
arch/sh/boards/mach-migor/setup.c |4 +-
arch/sh/boards/mach-se/7724/setup.c |2 +-
drivers/video/sh_mobile_lcdcfb.c| 360 --
include/video/sh_mobile_lcdc.h |4 +-
10 files changed, 253 insertions(+), 133 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-ag5evm.c
b/arch/arm/mach-shmobile/board-ag5evm.c
index 7e3dd73..80319f2 100644
--- a/arch/arm/mach-shmobile/board-ag5evm.c
+++ b/arch/arm/mach-shmobile/board-ag5evm.c
@@ -271,7 +271,7 @@ static struct sh_mobile_lcdc_info lcdc0_info = {
.flags = LCDC_FLAGS_DWPOL,
.lcd_size_cfg.width = 44,
.lcd_size_cfg.height = 79,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = lcdc0_modes,
.num_cfg = ARRAY_SIZE(lcdc0_modes),
.board_cfg = {
diff --git a/arch/arm/mach-shmobile/board-ap4evb.c
b/arch/arm/mach-shmobile/board-ap4evb.c
index 904b608..42b4dda 100644
--- a/arch/arm/mach-shmobile/board-ap4evb.c
+++ b/arch/arm/mach-shmobile/board-ap4evb.c
@@ -491,7 +491,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.meram_dev = &meram_info,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = ap4evb_lcdc_modes,
.num_cfg = ARRAY_SIZE(ap4evb_lcdc_modes),
.meram_cfg = &lcd_meram_cfg,
@@ -813,7 +813,7 @@ static struct sh_mobile_lcdc_info sh_mobile_lcdc1_info = {
.meram_dev = &meram_info,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB24,
.clock_divider = 1,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/arch/arm/mach-shmobile/board-mackerel.c
b/arch/arm/mach-shmobile/board-mackerel.c
index 9c5e598..7db6a17 100644
--- a/arch/arm/mach-shmobile/board-mackerel.c
+++ b/arch/arm/mach-shmobile/board-mackerel.c
@@ -388,7 +388,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.clock_source = LCDC_CLK_BUS,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_cfg = mackerel_lcdc_modes,
.num_cfg = ARRAY_SIZE(mackerel_lcdc_modes),
.interface_type = RGB24,
@@ -451,7 +451,7 @@ static struct sh_mobile_lcdc_info hdmi_lcdc_info = {
.clock_source = LCDC_CLK_EXTERNAL,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB24,
.clock_divider = 1,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/arch/sh/boards/mach-ap325rxa/setup.c
b/arch/sh/boards/mach-ap325rxa/setup.c
index 7030f4c..7977911 100644
--- a/arch/sh/boards/mach-ap325rxa/setup.c
+++ b/arch/sh/boards/mach-ap325rxa/setup.c
@@ -207,7 +207,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.clock_source = LCDC_CLK_EXTERNAL,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = RGB18,
.clock_divider = 1,
.lcd_cfg = ap325rxa_lcdc_modes,
diff --git a/arch/sh/boards/mach-ecovec24/setup.c
b/arch/sh/boards/mach-ecovec24/setup.c
index 92ddce4..1d4a706 100644
--- a/arch/sh/boards/mach-ecovec24/setup.c
+++ b/arch/sh/boards/mach-ecovec24/setup.c
@@ -330,7 +330,7 @@ static struct sh_mobile_lcdc_info lcdc_info = {
.ch[0] = {
.interface_type = RGB18,
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.lcd_size_cfg = { /* 7.0 inch */
.width = 152,
.height = 91,
diff --git a/arch/sh/boards/mach-kfr2r09/setup.c
b/arch/sh/boards/mach-kfr2r09/setup.c
index f65271a..208c9b0 100644
--- a/arch/sh/boards/mach-kfr2r09/setup.c
+++ b/arch/sh/boards/mach-kfr2r09/setup.c
@@ -146,7 +146,7 @@ static struct sh_mobile_lcdc_info kfr2r09_sh_lcdc_info = {
.clock_source = LCDC_CLK_BUS,
.ch[0] = {
.chan = LCDC_CHAN_MAINLCD,
- .bpp = 16,
+ .fourcc = V4L2_PIX_FMT_RGB565,
.interface_type = SYS18,
.clock_divider = 6,
.flags = LCDC_FLAGS_DWPOL,
diff --git a/arch/sh/boards/mach-migor/setup.c
b/arch/sh/boards/mach-migor/setu
[PATCH v4 2/3] v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats
NV24 and NV42 are planar YCbCr 4:4:4 and YCrCb 4:4:4 formats with a
luma plane followed by an interleaved chroma plane.
Signed-off-by: Laurent Pinchart
---
Documentation/DocBook/media/v4l/pixfmt-nv24.xml | 129 +++
Documentation/DocBook/media/v4l/pixfmt.xml |1 +
include/linux/videodev2.h |2 +
3 files changed, 132 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
new file mode 100644
index 000..939c803
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv24.xml
@@ -0,0 +1,129 @@
+
+
+ V4L2_PIX_FMT_NV24 ('NV24'), V4L2_PIX_FMT_NV42
('NV42')
+ &manvol;
+
+
+ V4L2_PIX_FMT_NV24
+ V4L2_PIX_FMT_NV42
+ Formats with full horizontal and vertical
+chroma resolutions, also known as YUV 4:4:4. One luminance and one
+chrominance plane with alternating chroma samples as opposed to
+V4L2_PIX_FMT_YVU420
+
+
+ Description
+
+ These are two-plane versions of the YUV 4:4:4 format. The three
+ components are separated into two sub-images or planes. The Y plane is
+ first, with each Y sample stored in one byte per pixel. For
+ V4L2_PIX_FMT_NV24, a combined CbCr plane
+ immediately follows the Y plane in memory. The CbCr plane has the same
+ width and height, in pixels, as the Y plane (and the image). Each line
+ contains one CbCr pair per pixel, with each Cb and Cr sample stored in
+ one byte. V4L2_PIX_FMT_NV42 is the same except that
+ the Cb and Cr samples are swapped, the CrCb plane starts with a Cr
+ sample.
+
+ If the Y plane has pad bytes after each row, then the CbCr plane
+ has twice as many pad bytes after its rows.
+
+
+ V4L2_PIX_FMT_NV24 4 × 4
+pixel image
+
+
+ Byte Order.
+ Each cell is one byte.
+
+
+
+
+
+ start + 0:
+ Y'00
+ Y'01
+ Y'02
+ Y'03
+
+
+ start + 4:
+ Y'10
+ Y'11
+ Y'12
+ Y'13
+
+
+ start + 8:
+ Y'20
+ Y'21
+ Y'22
+ Y'23
+
+
+ start + 12:
+ Y'30
+ Y'31
+ Y'32
+ Y'33
+
+
+ start + 16:
+ Cb00
+ Cr00
+ Cb01
+ Cr01
+ Cb02
+ Cr02
+ Cb03
+ Cr03
+
+
+ start + 24:
+ Cb10
+ Cr10
+ Cb11
+ Cr11
+ Cb12
+ Cr12
+ Cb13
+ Cr13
+
+
+ start + 32:
+ Cb20
+ Cr20
+ Cb21
+ Cr21
+ Cb22
+ Cr22
+ Cb23
+ Cr23
+
+
+ start + 40:
+ Cb30
+ Cr30
+ Cb31
+ Cr31
+ Cb32
+ Cr32
+ Cb33
+ Cr33
+
+
+
+
+
+
+
+
+
+
+
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 2ff6b77..aef4615 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -714,6 +714,7 @@ information.
&sub-nv12m;
&sub-nv12mt;
&sub-nv16;
+&sub-nv24;
&sub-m420;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..d2f74f8 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -343,6 +343,8 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1') /* 12 Y/CrCb
4:2:0 */
#define V4L2_PIX_FMT_NV16v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr
4:2:2 */
#define V4L2_PIX_FMT_NV61v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb
4:2:2 */
+#define V4L2_PIX_FMT_NV24v4l2_fourcc('N', 'V', '2', '4') /*
[PATCH v4 1/3] fbdev: Add FOURCC-based format configuration API
This API will be used to support YUV frame buffer formats in a standard
way.
Last but not least, create a much needed fbdev API documentation and
document the format setting APIs.
Signed-off-by: Laurent Pinchart
---
Documentation/fb/api.txt | 306 ++
include/linux/fb.h | 14 ++-
2 files changed, 316 insertions(+), 4 deletions(-)
create mode 100644 Documentation/fb/api.txt
diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt
new file mode 100644
index 000..8e2db6c
--- /dev/null
+++ b/Documentation/fb/api.txt
@@ -0,0 +1,306 @@
+ The Frame Buffer Device API
+ ---
+
+Last revised: June 21, 2011
+
+
+0. Introduction
+---
+
+This document describes the frame buffer API used by applications to interact
+with frame buffer devices. In-kernel APIs between device drivers and the frame
+buffer core are not described.
+
+Due to a lack of documentation in the original frame buffer API, drivers
+behaviours differ in subtle (and not so subtle) ways. This document describes
+the recommended API implementation, but applications should be prepared to
+deal with different behaviours.
+
+
+1. Capabilities
+---
+
+Device and driver capabilities are reported in the fixed screen information
+capabilities field.
+
+struct fb_fix_screeninfo {
+ ...
+ __u16 capabilities; /* see FB_CAP_* */
+ ...
+};
+
+Application should use those capabilities to find out what features they can
+expect from the device and driver.
+
+- FB_CAP_FOURCC
+
+The driver supports the four character code (FOURCC) based format setting API.
+When supported, formats are configured using a FOURCC instead of manually
+specifying color components layout.
+
+
+2. Types and visuals
+
+
+Pixels are stored in memory in hardware-dependent formats. Applications need
+to be aware of the pixel storage format in order to write image data to the
+frame buffer memory in the format expected by the hardware.
+
+Formats are described by frame buffer types and visuals. Some visuals require
+additional information, which are stored in the variable screen information
+bits_per_pixel, grayscale, red, green, blue and transp fields.
+
+Visuals describe how color information is encoded and assembled to create
+macropixels. Types describe how macropixels are stored in memory. The following
+types and visuals are supported.
+
+- FB_TYPE_PACKED_PIXELS
+
+Macropixels are stored contiguously in a single plane. If the number of bits
+per macropixel is not a multiple of 8, whether macropixels are padded to the
+next multiple of 8 bits or packed together into bytes depends on the visual.
+
+Padding at end of lines may be present and is then reported through the fixed
+screen information line_length field.
+
+- FB_TYPE_PLANES
+
+Macropixels are split across multiple planes. The number of planes is equal to
+the number of bits per macropixel, with plane i'th storing i'th bit from all
+macropixels.
+
+Planes are located contiguously in memory.
+
+- FB_TYPE_INTERLEAVED_PLANES
+
+Macropixels are split across multiple planes. The number of planes is equal to
+the number of bits per macropixel, with plane i'th storing i'th bit from all
+macropixels.
+
+Planes are interleaved in memory. The interleave factor, defined as the
+distance in bytes between the beginning of two consecutive interleaved blocks
+belonging to different planes, is stored in the fixed screen information
+type_aux field.
+
+- FB_TYPE_FOURCC
+
+Macropixels are stored in memory as described by the format FOURCC identifier
+stored in the variable screen information grayscale field.
+
+- FB_VISUAL_MONO01
+
+Pixels are black or white and stored on a number of bits (typically one)
+specified by the variable screen information bpp field.
+
+Black pixels are represented by all bits set to 1 and white pixels by all bits
+set to 0. When the number of bits per pixel is smaller than 8, several pixels
+are packed together in a byte.
+
+FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_MONO10
+
+Pixels are black or white and stored on a number of bits (typically one)
+specified by the variable screen information bpp field.
+
+Black pixels are represented by all bits set to 0 and white pixels by all bits
+set to 1. When the number of bits per pixel is smaller than 8, several pixels
+are packed together in a byte.
+
+FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only.
+
+- FB_VISUAL_TRUECOLOR
+
+Pixels are broken into red, green and blue components, and each component
+indexes a read-only lookup table for the corresponding value. Lookup tables
+are device-dependent, and provide linear or non-linear ramps.
+
+Each component is stored in a macropixel according to the variable screen
+information red, green, blue and transp fields.
+
+- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_S
[PATCH v4 0/3] fbdev: Add FOURCC-based format configuration API
Hi everybody, Here's the fourth version of the fbdev FOURCC-based format configuration API. The third version nearly got merged, but we noticed that gcc choked on anonymous union initializers. This has been fixed in gcc 4.6, but I don't have the power to force Linux to set the base gcc version to 4.6 :-) There were two ways to fix the issue, neither of which was particularly attractive to me. The first one involved a 10k lines patch that modified all the drivers, and the second one required using one of the reserved fields in the fb_var_screeninfo structure. After discussing this with Florian, I've decided to go for the second fix. The colorspace field is thus now stored in a previously reserved field. The fourcc field is still shared with the grayscale field, but doesn't have its own name anymore. I've updated the fbdev-test tool to this new API. The code is available in the fbdev-test yuv branch at http://git.ideasonboard.org/?p=fbdev-test.git;a=shortlog;h=refs/heads/yuv. Laurent Pinchart (3): fbdev: Add FOURCC-based format configuration API v4l: Add V4L2_PIX_FMT_NV24 and V4L2_PIX_FMT_NV42 formats fbdev: sh_mobile_lcdc: Support FOURCC-based format API Documentation/DocBook/media/v4l/pixfmt-nv24.xml | 129 Documentation/DocBook/media/v4l/pixfmt.xml |1 + Documentation/fb/api.txt| 306 +++ arch/arm/mach-shmobile/board-ag5evm.c |2 +- arch/arm/mach-shmobile/board-ap4evb.c |4 +- arch/arm/mach-shmobile/board-mackerel.c |4 +- arch/sh/boards/mach-ap325rxa/setup.c|2 +- arch/sh/boards/mach-ecovec24/setup.c|2 +- arch/sh/boards/mach-kfr2r09/setup.c |2 +- arch/sh/boards/mach-migor/setup.c |4 +- arch/sh/boards/mach-se/7724/setup.c |2 +- drivers/video/sh_mobile_lcdcfb.c| 360 +++ include/linux/fb.h | 14 +- include/linux/videodev2.h |2 + include/video/sh_mobile_lcdc.h |4 +- 15 files changed, 701 insertions(+), 137 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-nv24.xml create mode 100644 Documentation/fb/api.txt -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Support for multiple section feeds with same PIDs
Hello Question on the current behavior of dvb_dmxdev_filter_start (dmxdev.c) In case of DMXDEV_TYPE_SEC, the code restricts of having multiple sections feeds allocated (allocate_section_feed) with same PID. From my experience, applications might request allocating several section feeds using same PID but with different filters (for example, in DVB standard, SDT and BAT tables have same PID). The current implementation only supports of having multiple filters on the same section feed. Any special reason why it was implemented this way? Thank you Hamad -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
