headers
David M | 1 Feb 01:25
Picon

Package name for lsdiff for Zorin OS 5 is....

Howdy,

I Was compiling drivers for this card...
I ran this command....

user <at> computer:~/media_build$ ./build

And got this error:

Checking if the needed tools for Zorin OS 5 are available
ERROR: please install "lsdiff", otherwise, build won't work.
I don't know distro Zorin OS 5. So, I can't provide you a hint with the
package names.
Be welcome to contribute with a patch for media-build, by submitting a
distro-specific hint
to linux-media <at> vger.kernel.org
Build can't procceed as 1 dependency is missing at ./build line 202.

The secret answer is.... the package "patchutils"

David M.
Permalink | Reply | 0 comments |
headers
Guennadi Liakhovetski | 1 Feb 02:44
Picon
Picon

Re: [Q] Interleaved formats on the media bus

Hi Sylwester

On Tue, 31 Jan 2012, Sylwester Nawrocki wrote:

> Hi all,
> 
> Some camera sensors generate data formats that cannot be described using
> current convention of the media bus pixel code naming.
> For instance, interleaved JPEG data and raw VYUY. Moreover interleaving
> is rather vendor specific, IOW I imagine there might be many ways of how
> the interleaving algorithm is designed.
> 
> I'm wondering how to handle this. For sure such an image format will need
> a new vendor-specific fourcc. Should we have also vendor specific media bus code ?
> 
> I would like to avoid vendor specific media bus codes as much as possible.
> For instance defining something like
> 
> V4L2_MBUS_FMT_VYUY_JPEG_1X8

Hmm... Are such sensors not sending this data over something like CSI-2 
with different channel IDs? In which case we just deal with two formats 
cleanly.

Otherwise - I'm a bit sceptical about defining a new format for each pair 
of existing codes. Maybe we should rather try to describe individual 
formats and the way they are interleaved? In any case the end user will 
want them separately, right? So, at some point they will want to know what 
are those two formats, that the camera has sent.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Taylor Ralph | 1 Feb 04:04
Picon

Re: [PATCH] [media] hdpvr: update picture controls to support firmware versions > 0.15

On Wed, Dec 21, 2011 at 5:14 PM, Taylor Ralph <taylor.ralph <at> gmail.com> wrote:
> On Mon, Nov 7, 2011 at 7:54 PM, Taylor Ralph <taylor.ralph <at> gmail.com> wrote:
>> On Mon, Nov 7, 2011 at 7:21 AM, Mauro Carvalho Chehab
>> <mchehab <at> redhat.com> wrote:
>>> Em 21-10-2011 01:33, Taylor Ralph escreveu:
>>>> On Thu, Oct 20, 2011 at 3:26 PM, Taylor Ralph <taylor.ralph <at> gmail.com> wrote:
>>>>> On Thu, Oct 20, 2011 at 2:14 PM, Devin Heitmueller
>>>>> <dheitmueller <at> kernellabs.com> wrote:
>>>>>> On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau <j <at> jannau.net> wrote:
>>>>>>> I think such scenario is unlikely but I don't know it for sure and
>>>>>>> I don't want to force anyone to test every firmware version.
>>>>>>> Ignoring them for firmware version < 16 should be safe since we assume
>>>>>>> they had no effect. Returning -EINVAL might break API-ignoring
>>>>>>> applications written with the HD PVR in mind but I think it's a better
>>>>>>> approach than silently ignoring those controls.
>>>>>>
>>>>>> At this point, let's just make it so that the old behavior is
>>>>>> unchanged for old firmwares, meaning from both an API standpoint as
>>>>>> well as what the values are.  At some point if somebody cares enough
>>>>>> to go back and fix the support so that the controls actually work with
>>>>>> old firmwares, they can take that up as a separate task.  In reality,
>>>>>> it is likely that nobody will ever do that, as the "easy answer" is
>>>>>> just to upgrade to firmware 16.
>>>>>>
>>>>>> Taylor, could you please tweak your patch to that effect and resubmit?
>>>>>>
>>>>>
>>>>> Sure, I'll try to get to it tonight and have it tested.
>>>>>
>>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sachin Kamat | 1 Feb 06:09
Favicon

[PATCH v3] [media] s5p-g2d: Add HFLIP and VFLIP support

Add support for flipping the image horizontally and vertically.

Signed-off-by: Sachin Kamat <sachin.kamat <at> linaro.org>
---
 drivers/media/video/s5p-g2d/g2d-hw.c |    5 +++++
 drivers/media/video/s5p-g2d/g2d.c    |   23 ++++++++++++++++++-----
 drivers/media/video/s5p-g2d/g2d.h    |    4 ++++
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/s5p-g2d/g2d-hw.c b/drivers/media/video/s5p-g2d/g2d-hw.c
index 39937cf..5b86cbe 100644
--- a/drivers/media/video/s5p-g2d/g2d-hw.c
+++ b/drivers/media/video/s5p-g2d/g2d-hw.c
@@ -77,6 +77,11 @@ void g2d_set_rop4(struct g2d_dev *d, u32 r)
 	w(r, ROP4_REG);
 }

+void g2d_set_flip(struct g2d_dev *d, u32 r)
+{
+	w(r, SRC_MSK_DIRECT_REG);
+}
+
 u32 g2d_cmd_stretch(u32 e)
 {
 	e &= 1;
diff --git a/drivers/media/video/s5p-g2d/g2d.c b/drivers/media/video/s5p-g2d/g2d.c
index febaa67..c615101 100644
--- a/drivers/media/video/s5p-g2d/g2d.c
+++ b/drivers/media/video/s5p-g2d/g2d.c
@@ -178,6 +178,7 @@ static int g2d_s_ctrl(struct v4l2_ctrl *ctrl)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sylwester Nawrocki | 1 Feb 10:01

Re: [PATCH v3] [media] s5p-g2d: Add HFLIP and VFLIP support

Hi Sachin,

On 02/01/2012 06:09 AM, Sachin Kamat wrote:
> @@ -200,11 +206,7 @@ int g2d_setup_ctrls(struct g2d_ctx *ctx)
>  {
>  	struct g2d_dev *dev = ctx->dev;
>  
> -	v4l2_ctrl_handler_init(&ctx->ctrl_handler, 1);
> -	if (ctx->ctrl_handler.error) {
> -		v4l2_err(&dev->v4l2_dev, "v4l2_ctrl_handler_init failed\n");
> -		return ctx->ctrl_handler.error;
> -	}
> +	v4l2_ctrl_handler_init(&ctx->ctrl_handler, 3);
>  
>  	v4l2_ctrl_new_std_menu(
>  		&ctx->ctrl_handler,
> @@ -214,11 +216,20 @@ int g2d_setup_ctrls(struct g2d_ctx *ctx)
>  		~((1 << V4L2_COLORFX_NONE) | (1 << V4L2_COLORFX_NEGATIVE)),
>  		V4L2_COLORFX_NONE);
>  
> +
> +	ctx->ctrl_hflip = v4l2_ctrl_new_std(&ctx->ctrl_handler, &g2d_ctrl_ops,
> +						V4L2_CID_HFLIP, 0, 1, 1, 0);
> +
> +	ctx->ctrl_vflip = v4l2_ctrl_new_std(&ctx->ctrl_handler, &g2d_ctrl_ops,
> +						V4L2_CID_VFLIP, 0, 1, 1, 0);
> +
>  	if (ctx->ctrl_handler.error) {
>  		v4l2_err(&dev->v4l2_dev, "v4l2_ctrl_handler_init failed\n");
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sachin Kamat | 1 Feb 10:03
Favicon

Re: [PATCH v3] [media] s5p-g2d: Add HFLIP and VFLIP support

Hi Sylwester,

On 1 February 2012 14:31, Sylwester Nawrocki <s.nawrocki <at> samsung.com> wrote:
> Hi Sachin,
>
> On 02/01/2012 06:09 AM, Sachin Kamat wrote:
>> @@ -200,11 +206,7 @@ int g2d_setup_ctrls(struct g2d_ctx *ctx)
>>  {
>>       struct g2d_dev *dev = ctx->dev;
>>
>> -     v4l2_ctrl_handler_init(&ctx->ctrl_handler, 1);
>> -     if (ctx->ctrl_handler.error) {
>> -             v4l2_err(&dev->v4l2_dev, "v4l2_ctrl_handler_init failed\n");
>> -             return ctx->ctrl_handler.error;
>> -     }
>> +     v4l2_ctrl_handler_init(&ctx->ctrl_handler, 3);
>>
>>       v4l2_ctrl_new_std_menu(
>>               &ctx->ctrl_handler,
>> @@ -214,11 +216,20 @@ int g2d_setup_ctrls(struct g2d_ctx *ctx)
>>               ~((1 << V4L2_COLORFX_NONE) | (1 << V4L2_COLORFX_NEGATIVE)),
>>               V4L2_COLORFX_NONE);
>>
>> +
>> +     ctx->ctrl_hflip = v4l2_ctrl_new_std(&ctx->ctrl_handler, &g2d_ctrl_ops,
>> +                                             V4L2_CID_HFLIP, 0, 1, 1, 0);
>> +
>> +     ctx->ctrl_vflip = v4l2_ctrl_new_std(&ctx->ctrl_handler, &g2d_ctrl_ops,
>> +                                             V4L2_CID_VFLIP, 0, 1, 1, 0);
>> +
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sachin Kamat | 1 Feb 10:48
Favicon

[PATCH v4] [media] s5p-g2d: Add HFLIP and VFLIP support

Add support for flipping the image horizontally and vertically.

Signed-off-by: Sachin Kamat <sachin.kamat <at> linaro.org>
---
 drivers/media/video/s5p-g2d/g2d-hw.c |    5 +++++
 drivers/media/video/s5p-g2d/g2d.c    |   27 ++++++++++++++++++++-------
 drivers/media/video/s5p-g2d/g2d.h    |    4 ++++
 3 files changed, 29 insertions(+), 7 deletions(-)

diff --git a/drivers/media/video/s5p-g2d/g2d-hw.c b/drivers/media/video/s5p-g2d/g2d-hw.c
index 39937cf..5b86cbe 100644
--- a/drivers/media/video/s5p-g2d/g2d-hw.c
+++ b/drivers/media/video/s5p-g2d/g2d-hw.c
@@ -77,6 +77,11 @@ void g2d_set_rop4(struct g2d_dev *d, u32 r)
 	w(r, ROP4_REG);
 }

+void g2d_set_flip(struct g2d_dev *d, u32 r)
+{
+	w(r, SRC_MSK_DIRECT_REG);
+}
+
 u32 g2d_cmd_stretch(u32 e)
 {
 	e &= 1;
diff --git a/drivers/media/video/s5p-g2d/g2d.c b/drivers/media/video/s5p-g2d/g2d.c
index febaa67..5f58128 100644
--- a/drivers/media/video/s5p-g2d/g2d.c
+++ b/drivers/media/video/s5p-g2d/g2d.c
@@ -185,6 +185,11 @@ static int g2d_s_ctrl(struct v4l2_ctrl *ctrl)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Sakari Ailus | 1 Feb 11:00
Picon
Picon
Favicon

Re: [Q] Interleaved formats on the media bus

Hi Sylwester,

On Tue, Jan 31, 2012 at 12:23:21PM +0100, Sylwester Nawrocki wrote:
> Hi all,
> 
> Some camera sensors generate data formats that cannot be described using
> current convention of the media bus pixel code naming.
> 
> For instance, interleaved JPEG data and raw VYUY. Moreover interleaving
> is rather vendor specific, IOW I imagine there might be many ways of how
> the interleaving algorithm is designed.

Is that truly interleaved, or is that e.g. first yuv and then jpeg?
Interleaving the two sounds quite strange to me.

> I'm wondering how to handle this. For sure such an image format will need
> a new vendor-specific fourcc. Should we have also vendor specific media bus code ?
> 
> I would like to avoid vendor specific media bus codes as much as possible.
> For instance defining something like
> 
> V4L2_MBUS_FMT_VYUY_JPEG_1X8
> 
> for interleaved VYUY and JPEG data might do, except it doesn't tell anything
> about how the data is interleaved.
> 
> So maybe we could add some code describing interleaving (xxxx)
> 
> V4L2_MBUS_FMT_xxxx_VYUY_JPEG_1X8
>
(Continue reading)

Permalink | Reply | 27 comments |
headers
Sylwester Nawrocki | 1 Feb 11:05

[ANN] IRC meeting on camera controls

Hi all,

I would like to invite everyone interested to a short IRC meeting on 
#v4l-meeting channel we are going to have at 14:00 CET, this Friday 
2012-02-03. The main topics are camera exposure and auto focus control
API. There were previous discussions on the mailing list regarding this
and patches from HeungJun Kim and me [1], [2]. Most of the patches are 
now available at gitweb interface [4]. They incorporate comments from
the discussions and the documentation is improved slightly. Some controls
will depend on the new integer menu control type patches from Sakari [3].

There were suggestions to create a new class for the proposed controls
as they are relatively high level. However as we're going to also have
a low level "image source" control class there are doubts whether it's 
a good thing to do.

The proposed controls can be divided into following groups:

Exposure controls:

* V4L2_CID_METERING_MODE		- light metering mode for auto exposure
* V4L2_CID_EXPOSURE_BIAS		- auto exposure bias
* V4L2_CID_ISO				- manual ISO sensitivity
* V4L2_CID_ISO_AUTO			- enable disable automatic ISO adjustments
* V4L2_CID_ISO_PRESET			- sensitivity preset

White balance:

* V4L2_CID_WHITE_BALANCE_PRESET		- white balance preset
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sylwester Nawrocki | 1 Feb 11:44

Re: [Q] Interleaved formats on the media bus

Hi Guennadi,

On 02/01/2012 02:44 AM, Guennadi Liakhovetski wrote:
>> V4L2_MBUS_FMT_VYUY_JPEG_1X8
> 
> Hmm... Are such sensors not sending this data over something like CSI-2 
> with different channel IDs? In which case we just deal with two formats 
> cleanly.

I think they could, it might be just a matter of a proper firmware. But now
all that is available is only truly interleaved data, in the chunks of page
or so. For a full picture I should mention that such a frame contains also
embedded non image data, at the end of frame. But this can possibly be handled
with a separate buffer queue, like in VBI case for instance.

> Otherwise - I'm a bit sceptical about defining a new format for each pair 
> of existing codes. Maybe we should rather try to describe individual 
> formats and the way they are interleaved? In any case the end user will 

Yes, sounds reasonable. However the sensor specific frame is transferred
as MIPI-CSI2 User Defined Data 1. So it should be possible to associate such 
information with the format on the media bus, for the bus receiver to be able
to properly handle the data. 

> want them separately, right? So, at some point they will want to know what 
> are those two formats, that the camera has sent.

I'm afraid the data will data have to be separated in user space. Moreover 
the user space needs to know what are resolutions for each YUV and JPEG frames.
But this could be probably queried at relevant subdevs/pads.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane