[RFC][PATCH 0/2] Sensor orientation reporting

[RFC][PATCH 0/2] Sensor orientation reporting

[Adam Baker]

Hi all,

I've finally got round to writing a sample patch to support the proposed 
mechanism of reporting sensor orientation to user space. It is split into 2 
parts, part 1 contains the kernel changes and part 2 the libv4l changes. In 
order to keep the patch simple I haven't attempted to add support to libv4l 
for HFLIP and VFLIP but just assumed for now that if a cam needs one then it 
needs both. If the basic idea gets accepted then fixing that is purely a user 
space change.

I also haven't provided an implementation of VIDIOC_ENUMINPUT in libv4l that 
updates the flags to reflect what libv4l has done to the image. Hans Verkuil 
originally said he wanted to leave the orientation information available to 
the user app but I suspect that is actually undesirable. If an app is 
designed to work without libv4l and to re-orient an image as required then if 
someone runs it with the LD_PRELOAD capability of libv4l then correct 
operation depends upon reporting the corrected orientation to the app, not 
the original orientation.

Adam

[RFC][PATCH 1/2] Sensor orientation reporting

[Adam Baker]

Add support to the SQ-905 driver to pass back to user space the
sensor orientation information obtained from the camera during init.
Modifies gspca and the videodev2.h header to create the necessary
API.

Signed-off-by: Adam Baker <linux@baker-net.org.uk>

---
diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c	Sat Mar 14 08:44:42 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c	Sun Mar 15 22:25:34 2009 +0000
@@ -1147,6 +1147,7 @@ static int vidioc_enum_input(struct file
 	if (input->index != 0)
 		return -EINVAL;
 	input->type = V4L2_INPUT_TYPE_CAMERA;
+	input->status = gspca_dev->input_flags;
 	strncpy(input->name, gspca_dev->sd_desc->name,
 		sizeof input->name);
 	return 0;
diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h	Sat Mar 14 08:44:42 2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.h	Sun Mar 15 22:25:34 2009 +0000
@@ -168,6 +168,7 @@ struct gspca_dev {
 	__u8 alt;			/* USB alternate setting */
 	__u8 nbalt;			/* number of USB alternate settings */
 	u8 bulk;			/* image transfer by 0:isoc / 1:bulk */
+	u32 input_flags;		/* value for ENUM_INPUT status flags */
 };
 
 int gspca_dev_probe(struct usb_interface *intf,
diff -r 1248509d8bed linux/drivers/media/video/gspca/sq905.c
--- a/linux/drivers/media/video/gspca/sq905.c	Sat Mar 14 08:44:42 2009 +0100
+++ b/linux/drivers/media/video/gspca/sq905.c	Sun Mar 15 22:25:34 2009 +0000
@@ -357,6 +357,12 @@ static int sd_init(struct gspca_dev *gsp
 	gspca_dev->cam.nmodes = ARRAY_SIZE(sq905_mode);
 	if (!(ident & SQ905_HIRES_MASK))
 		gspca_dev->cam.nmodes--;
+
+	if (ident & SQ905_ORIENTATION_MASK)
+		gspca_dev->input_flags = V4L2_IN_ST_VFLIP;
+	else
+		gspca_dev->input_flags = V4L2_IN_ST_VFLIP |
+					 V4L2_IN_ST_HFLIP;
 	return 0;
 }
 
diff -r 1248509d8bed linux/include/linux/videodev2.h
--- a/linux/include/linux/videodev2.h	Sat Mar 14 08:44:42 2009 +0100
+++ b/linux/include/linux/videodev2.h	Sun Mar 15 22:25:34 2009 +0000
@@ -736,6 +736,11 @@ struct v4l2_input {
 #define V4L2_IN_ST_NO_SIGNAL   0x00000002
 #define V4L2_IN_ST_NO_COLOR    0x00000004
 
+/* field 'status' - sensor orientation */
+/* If sensor is mounted upside down set both bits */
+#define V4L2_IN_ST_HFLIP       0x00000010 /* Output is flipped horizontally */
+#define V4L2_IN_ST_VFLIP       0x00000020 /* Output is flipped vertically */
+
 /* field 'status' - analog */
 #define V4L2_IN_ST_NO_H_LOCK   0x00000100  /* No horizontal sync lock */
 #define V4L2_IN_ST_COLOR_KILL  0x00000200  /* Color killer is active */

[RFC][PATCH 2/2] Sensor orientation reporting

[Adam Baker]

Add check to libv4l of the sensor orientation as reported by
VIDIOC_ENUMINPUT

Signed-off-by: Adam Baker <linux@baker-net.org.uk>

---
diff -r a647c2dfa989 v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.c
--- a/v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.c	Tue Jan 20 11:25:54 
2009 +0100
+++ b/v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.c	Sun Mar 15 22:34:00 
2009 +0000
@@ -28,6 +28,11 @@
 
 #define MIN(a,b) (((a)<(b))?(a):(b))
 #define ARRAY_SIZE(x) ((int)sizeof(x)/(int)sizeof((x)[0]))
+
+/* Workaround this potentially being missing from videodev2.h */
+#ifndef V4L2_IN_ST_VFLIP
+#define V4L2_IN_ST_VFLIP       0x00000020 /* Output is flipped vertically */
+#endif
 
 /* Note for proper functioning of v4lconvert_enum_fmt the first entries in
   supported_src_pixfmts must match with the entries in supported_dst_pixfmts 
*/
@@ -134,6 +139,7 @@ struct v4lconvert_data *v4lconvert_creat
   int i, j;
   struct v4lconvert_data *data = calloc(1, sizeof(struct v4lconvert_data));
   struct v4l2_capability cap;
+  struct v4l2_input input;
 
   if (!data)
     return NULL;
@@ -161,6 +167,13 @@ struct v4lconvert_data *v4lconvert_creat
 
   /* Check if this cam has any special flags */
   data->flags = v4lconvert_get_flags(data->fd);
+  if ((syscall(SYS_ioctl, fd, VIDIOC_G_INPUT, &input.index) == 0) &&
+      (syscall(SYS_ioctl, fd, VIDIOC_ENUMINPUT, &input) == 0)) {
+    /* Don't yet support independent HFLIP and VFLIP so getting
+     * image the right way up is highest priority. */
+    if (input.status & V4L2_IN_ST_VFLIP)
+      data->flags |= V4LCONVERT_ROTATE_180;
+  }
   if (syscall(SYS_ioctl, fd, VIDIOC_QUERYCAP, &cap) == 0) {
     if (!strcmp((char *)cap.driver, "uvcvideo"))
       data->flags |= V4LCONVERT_IS_UVC;

Re: [RFC][PATCH 0/2] Sensor orientation reporting

[Hans de Goede]

Adam Baker wrote:
> Hi all,
> 
> I've finally got round to writing a sample patch to support the proposed 
> mechanism of reporting sensor orientation to user space. It is split into 2 
> parts, part 1 contains the kernel changes and part 2 the libv4l changes. In 
> order to keep the patch simple I haven't attempted to add support to libv4l 
> for HFLIP and VFLIP but just assumed for now that if a cam needs one then it 
> needs both. If the basic idea gets accepted then fixing that is purely a user 
> space change.
> 
> I also haven't provided an implementation of VIDIOC_ENUMINPUT in libv4l that 
> updates the flags to reflect what libv4l has done to the image. Hans Verkuil 
> originally said he wanted to leave the orientation information available to 
> the user app but I suspect that is actually undesirable. If an app is 
> designed to work without libv4l and to re-orient an image as required then if 
> someone runs it with the LD_PRELOAD capability of libv4l then correct 
> operation depends upon reporting the corrected orientation to the app, not 
> the original orientation.
> 

Thanks!

Both patches look good to me.

Regards,

Hans

Re: [RFC][PATCH 0/2] Sensor orientation reporting

[Theodore Kilgore]

On Mon, 16 Mar 2009, Hans de Goede wrote:

> Adam Baker wrote:
>> Hi all,
>> 
>> I've finally got round to writing a sample patch to support the proposed 
>> mechanism of reporting sensor orientation to user space. It is split into 2 
>> parts, part 1 contains the kernel changes and part 2 the libv4l changes. In 
>> order to keep the patch simple I haven't attempted to add support to libv4l 
>> for HFLIP and VFLIP but just assumed for now that if a cam needs one then 
>> it needs both. If the basic idea gets accepted then fixing that is purely a 
>> user space change.
>> 
>> I also haven't provided an implementation of VIDIOC_ENUMINPUT in libv4l 
>> that updates the flags to reflect what libv4l has done to the image. Hans 
>> Verkuil originally said he wanted to leave the orientation information 
>> available to the user app but I suspect that is actually undesirable. If an 
>> app is designed to work without libv4l and to re-orient an image as 
>> required then if someone runs it with the LD_PRELOAD capability of libv4l 
>> then correct operation depends upon reporting the corrected orientation to 
>> the app, not the original orientation.
>>

Finally, we can get the SQ905 cameras to work right-side-up, and move on 
to other things. This appears to me to be exactly the kind of solution 
which we needed.

Theodore Kilgore

Re: [RFC][PATCH 0/2] Sensor orientation reporting

[Adam Baker]

On Monday 16 March 2009, Hans de Goede wrote:
> Both patches look good to me.

A complaint about lack of documentation wouldn't have gone amiss. 
Unfortunately having just remembered that I should have done that I'm 
struggling to get the current docbook to compile (So far I've suffered Ubuntu 
not packaging an old enough docbook, missing character set definition files 
and the Makefile depending on bash but not explicitly requesting it so 
getting dash).

It looks like it now builds the docs so I'm ready to start updating them.

Adam

Re: [RFC][PATCH 0/2] Sensor orientation reporting

[Hans de Goede]

Adam Baker wrote:
> On Monday 16 March 2009, Hans de Goede wrote:
>> Both patches look good to me.
> 
> A complaint about lack of documentation wouldn't have gone amiss. 

Er, good point.

Regards,

Hans

> Unfortunately having just remembered that I should have done that I'm 
> struggling to get the current docbook to compile (So far I've suffered Ubuntu 
> not packaging an old enough docbook, missing character set definition files 
> and the Makefile depending on bash but not explicitly requesting it so 
> getting dash).
> 
> It looks like it now builds the docs so I'm ready to start updating them.
> 
> Adam
> 

Re: [RFC][PATCH 1/2] Sensor orientation reporting

[Mauro Carvalho Chehab]

On Sun, 15 Mar 2009 22:29:48 +0000
Adam Baker <linux@baker-net.org.uk> wrote:

> Add support to the SQ-905 driver to pass back to user space the
> sensor orientation information obtained from the camera during init.
> Modifies gspca and the videodev2.h header to create the necessary
> API.

Please provide also the V4L2 specs change to include those new controls.

> 
> Signed-off-by: Adam Baker <linux@baker-net.org.uk>
> 
> ---
> diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.c
> --- a/linux/drivers/media/video/gspca/gspca.c	Sat Mar 14 08:44:42 2009 +0100
> +++ b/linux/drivers/media/video/gspca/gspca.c	Sun Mar 15 22:25:34 2009 +0000
> @@ -1147,6 +1147,7 @@ static int vidioc_enum_input(struct file
>  	if (input->index != 0)
>  		return -EINVAL;
>  	input->type = V4L2_INPUT_TYPE_CAMERA;
> +	input->status = gspca_dev->input_flags;
>  	strncpy(input->name, gspca_dev->sd_desc->name,
>  		sizeof input->name);
>  	return 0;
> diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.h
> --- a/linux/drivers/media/video/gspca/gspca.h	Sat Mar 14 08:44:42 2009 +0100
> +++ b/linux/drivers/media/video/gspca/gspca.h	Sun Mar 15 22:25:34 2009 +0000
> @@ -168,6 +168,7 @@ struct gspca_dev {
>  	__u8 alt;			/* USB alternate setting */
>  	__u8 nbalt;			/* number of USB alternate settings */
>  	u8 bulk;			/* image transfer by 0:isoc / 1:bulk */
> +	u32 input_flags;		/* value for ENUM_INPUT status flags */
>  };
>  
>  int gspca_dev_probe(struct usb_interface *intf,
> diff -r 1248509d8bed linux/drivers/media/video/gspca/sq905.c
> --- a/linux/drivers/media/video/gspca/sq905.c	Sat Mar 14 08:44:42 2009 +0100
> +++ b/linux/drivers/media/video/gspca/sq905.c	Sun Mar 15 22:25:34 2009 +0000
> @@ -357,6 +357,12 @@ static int sd_init(struct gspca_dev *gsp
>  	gspca_dev->cam.nmodes = ARRAY_SIZE(sq905_mode);
>  	if (!(ident & SQ905_HIRES_MASK))
>  		gspca_dev->cam.nmodes--;
> +
> +	if (ident & SQ905_ORIENTATION_MASK)
> +		gspca_dev->input_flags = V4L2_IN_ST_VFLIP;
> +	else
> +		gspca_dev->input_flags = V4L2_IN_ST_VFLIP |
> +					 V4L2_IN_ST_HFLIP;
>  	return 0;
>  }
>  
> diff -r 1248509d8bed linux/include/linux/videodev2.h
> --- a/linux/include/linux/videodev2.h	Sat Mar 14 08:44:42 2009 +0100
> +++ b/linux/include/linux/videodev2.h	Sun Mar 15 22:25:34 2009 +0000
> @@ -736,6 +736,11 @@ struct v4l2_input {
>  #define V4L2_IN_ST_NO_SIGNAL   0x00000002
>  #define V4L2_IN_ST_NO_COLOR    0x00000004
>  
> +/* field 'status' - sensor orientation */
> +/* If sensor is mounted upside down set both bits */
> +#define V4L2_IN_ST_HFLIP       0x00000010 /* Output is flipped horizontally */
> +#define V4L2_IN_ST_VFLIP       0x00000020 /* Output is flipped vertically */
> +
>  /* field 'status' - analog */
>  #define V4L2_IN_ST_NO_H_LOCK   0x00000100  /* No horizontal sync lock */
>  #define V4L2_IN_ST_COLOR_KILL  0x00000200  /* Color killer is active */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html




Cheers,
Mauro

Re: [RFC][PATCH 1/2] Sensor orientation reporting

[Jean-Francois Moine]

On Sun, 15 Mar 2009 22:29:48 +0000
Adam Baker <linux@baker-net.org.uk> wrote:

> Add support to the SQ-905 driver to pass back to user space the
> sensor orientation information obtained from the camera during init.
> Modifies gspca and the videodev2.h header to create the necessary
> API.
> 
> Signed-off-by: Adam Baker <linux@baker-net.org.uk>
> 
> ---
	[snip]
> diff -r 1248509d8bed linux/drivers/media/video/gspca/gspca.h
> --- a/linux/drivers/media/video/gspca/gspca.h	Sat Mar 14
> 08:44:42 2009 +0100
> +++ b/linux/drivers/media/video/gspca/gspca.h	Sun Mar 15
> 22:25:34 2009 +0000
> @@ -168,6 +168,7 @@ struct gspca_dev {
> 	__u8 alt;		/* USB alternate setting */
> 	__u8 nbalt;		/* number of USB alternate settings */
>	 u8 bulk;		/* image transfer by 0:isoc / 1:bulk
> */
> +	u32 input_flags;	/* value for ENUM_INPUT status flags
> */ };
	[snip]

Hi Adam,

This 'input_flags' should better go to the 'struct cam' (line 59).

Cheers.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

Re: [RFC][PATCH 1/2] Sensor orientation reporting

[Adam Baker]

On Friday 27 Mar 2009, Mauro Carvalho Chehab wrote:
> On Sun, 15 Mar 2009 22:29:48 +0000
>
> Adam Baker <linux@baker-net.org.uk> wrote:
> > Add support to the SQ-905 driver to pass back to user space the
> > sensor orientation information obtained from the camera during init.
> > Modifies gspca and the videodev2.h header to create the necessary
> > API.
>
> Please provide also the V4L2 specs change to include those new controls.

I hadn't forgotten this, it was just taking rather longer than expected to put 
together a working build system for the documentation (In the end I concluded 
the quickest approach was a complete OS upgrade to get working versions of the 
docbook tools and config files).

Adam