[RFCv2 PATCH 00/12] stk-webcam: v4l2-compliance fixes

[RFCv2 PATCH 00/12] stk-webcam: v4l2-compliance fixes

[Hans Verkuil]

Hi all,

This second patch series updates this driver to the control framework,
switches it to unlocked_ioctl and fixes a variety of V4L2 compliance issues.

This patch series has been tested by Arvydas Sidorenko. Thank you!

I also like to thank Jose Gómez who also did some testing for me.

Changes in this second patch series:

- The first patch is new and fixes a bug introduced by commit
  7a29ee2e37b3f9675f46c87998c67b68c315c54a ("stk-webcam: Add an upside down
  dmi table, and add the Asus G1 to it").
- Patches 10-12 are also new and fix some more bugs found when running
  the compliance tests.

If there are no more comments then I intend to post the pull request on Friday.

Regards,

        Hans

[RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

This resulted in an upside-down picture.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index 4cbab08..71ac307 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -1305,15 +1305,15 @@ static int stk_camera_probe(struct usb_interface *interface,
 	if (hflip != -1)
 		dev->vsettings.hflip = hflip;
 	else if (dmi_check_system(stk_upside_down_dmi_table))
-		dev->vsettings.hflip = 1;
-	else
 		dev->vsettings.hflip = 0;
+	else
+		dev->vsettings.hflip = 1;
 	if (vflip != -1)
 		dev->vsettings.vflip = vflip;
 	else if (dmi_check_system(stk_upside_down_dmi_table))
-		dev->vsettings.vflip = 1;
-	else
 		dev->vsettings.vflip = 0;
+	else
+		dev->vsettings.vflip = 1;
 	dev->n_sbufs = 0;
 	set_present(dev);
 
-- 
1.7.10.4

[RFCv2 PATCH 02/12] stk-webcam: remove bogus STD support.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

It's a webcam, the STD API is not applicable to webcams.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |    9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index 71ac307..3b874e4 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -768,12 +768,6 @@ static int stk_vidioc_s_input(struct file *filp, void *priv, unsigned int i)
 		return 0;
 }
 
-/* from vivi.c */
-static int stk_vidioc_s_std(struct file *filp, void *priv, v4l2_std_id *a)
-{
-	return 0;
-}
-
 /* List of all V4Lv2 controls supported by the driver */
 static struct v4l2_queryctrl stk_controls[] = {
 	{
@@ -1225,7 +1219,6 @@ static const struct v4l2_ioctl_ops v4l_stk_ioctl_ops = {
 	.vidioc_enum_input = stk_vidioc_enum_input,
 	.vidioc_s_input = stk_vidioc_s_input,
 	.vidioc_g_input = stk_vidioc_g_input,
-	.vidioc_s_std = stk_vidioc_s_std,
 	.vidioc_reqbufs = stk_vidioc_reqbufs,
 	.vidioc_querybuf = stk_vidioc_querybuf,
 	.vidioc_qbuf = stk_vidioc_qbuf,
@@ -1251,8 +1244,6 @@ static void stk_v4l_dev_release(struct video_device *vd)
 
 static struct video_device stk_v4l_data = {
 	.name = "stkwebcam",
-	.tvnorms = V4L2_STD_UNKNOWN,
-	.current_norm = V4L2_STD_UNKNOWN,
 	.fops = &v4l_stk_fops,
 	.ioctl_ops = &v4l_stk_ioctl_ops,
 	.release = stk_v4l_dev_release,
-- 
1.7.10.4

[RFCv2 PATCH 03/12] stk-webcam: add support for struct v4l2_device.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |   10 +++++++++-
 drivers/media/usb/stkwebcam/stk-webcam.h |    2 ++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index 3b874e4..f21ba43 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -1256,7 +1256,7 @@ static int stk_register_video_device(struct stk_camera *dev)
 
 	dev->vdev = stk_v4l_data;
 	dev->vdev.debug = debug;
-	dev->vdev.parent = &dev->interface->dev;
+	dev->vdev.v4l2_dev = &dev->v4l2_dev;
 	err = video_register_device(&dev->vdev, VFL_TYPE_GRABBER, -1);
 	if (err)
 		STK_ERROR("v4l registration failed\n");
@@ -1285,6 +1285,12 @@ static int stk_camera_probe(struct usb_interface *interface,
 		STK_ERROR("Out of memory !\n");
 		return -ENOMEM;
 	}
+	err = v4l2_device_register(&interface->dev, &dev->v4l2_dev);
+	if (err < 0) {
+		dev_err(&udev->dev, "couldn't register v4l2_device\n");
+		kfree(dev);
+		return err;
+	}
 
 	spin_lock_init(&dev->spinlock);
 	init_waitqueue_head(&dev->wait_frame);
@@ -1345,6 +1351,7 @@ static int stk_camera_probe(struct usb_interface *interface,
 	return 0;
 
 error:
+	v4l2_device_unregister(&dev->v4l2_dev);
 	kfree(dev);
 	return err;
 }
@@ -1362,6 +1369,7 @@ static void stk_camera_disconnect(struct usb_interface *interface)
 		 video_device_node_name(&dev->vdev));
 
 	video_unregister_device(&dev->vdev);
+	v4l2_device_unregister(&dev->v4l2_dev);
 }
 
 #ifdef CONFIG_PM
diff --git a/drivers/media/usb/stkwebcam/stk-webcam.h b/drivers/media/usb/stkwebcam/stk-webcam.h
index 9f67366..49ebe85 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.h
+++ b/drivers/media/usb/stkwebcam/stk-webcam.h
@@ -23,6 +23,7 @@
 #define STKWEBCAM_H
 
 #include <linux/usb.h>
+#include <media/v4l2-device.h>
 #include <media/v4l2-common.h>
 
 #define DRIVER_VERSION		"v0.0.1"
@@ -91,6 +92,7 @@ struct regval {
 };
 
 struct stk_camera {
+	struct v4l2_device v4l2_dev;
 	struct video_device vdev;
 	struct usb_device *udev;
 	struct usb_interface *interface;
-- 
1.7.10.4

[RFCv2 PATCH 04/12] stk-webcam: convert to the control framework.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |  119 ++++++++----------------------
 drivers/media/usb/stkwebcam/stk-webcam.h |    3 +-
 2 files changed, 33 insertions(+), 89 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index f21ba43..aef7365 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -768,99 +768,25 @@ static int stk_vidioc_s_input(struct file *filp, void *priv, unsigned int i)
 		return 0;
 }
 
-/* List of all V4Lv2 controls supported by the driver */
-static struct v4l2_queryctrl stk_controls[] = {
-	{
-		.id      = V4L2_CID_BRIGHTNESS,
-		.type    = V4L2_CTRL_TYPE_INTEGER,
-		.name    = "Brightness",
-		.minimum = 0,
-		.maximum = 0xffff,
-		.step    = 0x0100,
-		.default_value = 0x6000,
-	},
-	{
-		.id      = V4L2_CID_HFLIP,
-		.type    = V4L2_CTRL_TYPE_BOOLEAN,
-		.name    = "Horizontal Flip",
-		.minimum = 0,
-		.maximum = 1,
-		.step    = 1,
-		.default_value = 1,
-	},
-	{
-		.id      = V4L2_CID_VFLIP,
-		.type    = V4L2_CTRL_TYPE_BOOLEAN,
-		.name    = "Vertical Flip",
-		.minimum = 0,
-		.maximum = 1,
-		.step    = 1,
-		.default_value = 1,
-	},
-};
-
-static int stk_vidioc_queryctrl(struct file *filp,
-		void *priv, struct v4l2_queryctrl *c)
+static int stk_s_ctrl(struct v4l2_ctrl *ctrl)
 {
-	int i;
-	int nbr;
-	nbr = ARRAY_SIZE(stk_controls);
-
-	for (i = 0; i < nbr; i++) {
-		if (stk_controls[i].id == c->id) {
-			memcpy(c, &stk_controls[i],
-				sizeof(struct v4l2_queryctrl));
-			return 0;
-		}
-	}
-	return -EINVAL;
-}
-
-static int stk_vidioc_g_ctrl(struct file *filp,
-		void *priv, struct v4l2_control *c)
-{
-	struct stk_camera *dev = priv;
-	switch (c->id) {
-	case V4L2_CID_BRIGHTNESS:
-		c->value = dev->vsettings.brightness;
-		break;
-	case V4L2_CID_HFLIP:
-		if (dmi_check_system(stk_upside_down_dmi_table))
-			c->value = !dev->vsettings.hflip;
-		else
-			c->value = dev->vsettings.hflip;
-		break;
-	case V4L2_CID_VFLIP:
-		if (dmi_check_system(stk_upside_down_dmi_table))
-			c->value = !dev->vsettings.vflip;
-		else
-			c->value = dev->vsettings.vflip;
-		break;
-	default:
-		return -EINVAL;
-	}
-	return 0;
-}
+	struct stk_camera *dev =
+		container_of(ctrl->handler, struct stk_camera, hdl);
 
-static int stk_vidioc_s_ctrl(struct file *filp,
-		void *priv, struct v4l2_control *c)
-{
-	struct stk_camera *dev = priv;
-	switch (c->id) {
+	switch (ctrl->id) {
 	case V4L2_CID_BRIGHTNESS:
-		dev->vsettings.brightness = c->value;
-		return stk_sensor_set_brightness(dev, c->value >> 8);
+		return stk_sensor_set_brightness(dev, ctrl->val);
 	case V4L2_CID_HFLIP:
 		if (dmi_check_system(stk_upside_down_dmi_table))
-			dev->vsettings.hflip = !c->value;
+			dev->vsettings.hflip = !ctrl->val;
 		else
-			dev->vsettings.hflip = c->value;
+			dev->vsettings.hflip = ctrl->val;
 		return 0;
 	case V4L2_CID_VFLIP:
 		if (dmi_check_system(stk_upside_down_dmi_table))
-			dev->vsettings.vflip = !c->value;
+			dev->vsettings.vflip = !ctrl->val;
 		else
-			dev->vsettings.vflip = c->value;
+			dev->vsettings.vflip = ctrl->val;
 		return 0;
 	default:
 		return -EINVAL;
@@ -1200,6 +1126,10 @@ static int stk_vidioc_enum_framesizes(struct file *filp,
 	}
 }
 
+static const struct v4l2_ctrl_ops stk_ctrl_ops = {
+	.s_ctrl = stk_s_ctrl,
+};
+
 static struct v4l2_file_operations v4l_stk_fops = {
 	.owner = THIS_MODULE,
 	.open = v4l_stk_open,
@@ -1225,9 +1155,6 @@ static const struct v4l2_ioctl_ops v4l_stk_ioctl_ops = {
 	.vidioc_dqbuf = stk_vidioc_dqbuf,
 	.vidioc_streamon = stk_vidioc_streamon,
 	.vidioc_streamoff = stk_vidioc_streamoff,
-	.vidioc_queryctrl = stk_vidioc_queryctrl,
-	.vidioc_g_ctrl = stk_vidioc_g_ctrl,
-	.vidioc_s_ctrl = stk_vidioc_s_ctrl,
 	.vidioc_g_parm = stk_vidioc_g_parm,
 	.vidioc_enum_framesizes = stk_vidioc_enum_framesizes,
 };
@@ -1272,8 +1199,9 @@ static int stk_register_video_device(struct stk_camera *dev)
 static int stk_camera_probe(struct usb_interface *interface,
 		const struct usb_device_id *id)
 {
-	int i;
+	struct v4l2_ctrl_handler *hdl;
 	int err = 0;
+	int i;
 
 	struct stk_camera *dev = NULL;
 	struct usb_device *udev = interface_to_usbdev(interface);
@@ -1291,6 +1219,20 @@ static int stk_camera_probe(struct usb_interface *interface,
 		kfree(dev);
 		return err;
 	}
+	hdl = &dev->hdl;
+	v4l2_ctrl_handler_init(hdl, 3);
+	v4l2_ctrl_new_std(hdl, &stk_ctrl_ops,
+			  V4L2_CID_BRIGHTNESS, 0, 0xff, 0x1, 0x60);
+	v4l2_ctrl_new_std(hdl, &stk_ctrl_ops,
+			  V4L2_CID_HFLIP, 0, 1, 1, 1);
+	v4l2_ctrl_new_std(hdl, &stk_ctrl_ops,
+			  V4L2_CID_VFLIP, 0, 1, 1, 1);
+	if (hdl->error) {
+		err = hdl->error;
+		dev_err(&udev->dev, "couldn't register control\n");
+		goto error;
+	}
+	dev->v4l2_dev.ctrl_handler = hdl;
 
 	spin_lock_init(&dev->spinlock);
 	init_waitqueue_head(&dev->wait_frame);
@@ -1334,7 +1276,6 @@ static int stk_camera_probe(struct usb_interface *interface,
 		err = -ENODEV;
 		goto error;
 	}
-	dev->vsettings.brightness = 0x7fff;
 	dev->vsettings.palette = V4L2_PIX_FMT_RGB565;
 	dev->vsettings.mode = MODE_VGA;
 	dev->frame_size = 640 * 480 * 2;
@@ -1351,6 +1292,7 @@ static int stk_camera_probe(struct usb_interface *interface,
 	return 0;
 
 error:
+	v4l2_ctrl_handler_free(hdl);
 	v4l2_device_unregister(&dev->v4l2_dev);
 	kfree(dev);
 	return err;
@@ -1369,6 +1311,7 @@ static void stk_camera_disconnect(struct usb_interface *interface)
 		 video_device_node_name(&dev->vdev));
 
 	video_unregister_device(&dev->vdev);
+	v4l2_ctrl_handler_free(&dev->hdl);
 	v4l2_device_unregister(&dev->v4l2_dev);
 }
 
diff --git a/drivers/media/usb/stkwebcam/stk-webcam.h b/drivers/media/usb/stkwebcam/stk-webcam.h
index 49ebe85..901f0df 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.h
+++ b/drivers/media/usb/stkwebcam/stk-webcam.h
@@ -24,6 +24,7 @@
 
 #include <linux/usb.h>
 #include <media/v4l2-device.h>
+#include <media/v4l2-ctrls.h>
 #include <media/v4l2-common.h>
 
 #define DRIVER_VERSION		"v0.0.1"
@@ -60,7 +61,6 @@ enum stk_mode {MODE_VGA, MODE_SXGA, MODE_CIF, MODE_QVGA, MODE_QCIF};
 
 struct stk_video {
 	enum stk_mode mode;
-	int brightness;
 	__u32 palette;
 	int hflip;
 	int vflip;
@@ -93,6 +93,7 @@ struct regval {
 
 struct stk_camera {
 	struct v4l2_device v4l2_dev;
+	struct v4l2_ctrl_handler hdl;
 	struct video_device vdev;
 	struct usb_device *udev;
 	struct usb_interface *interface;
-- 
1.7.10.4

[RFCv2 PATCH 05/12] stk-webcam: don't use private_data, use video_drvdata

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

file->private_data is needed to store the pointer to struct v4l2_fh.
So use video_drvdata to get hold of the stk_camera struct.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |   32 +++++++++++++-----------------
 1 file changed, 14 insertions(+), 18 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index aef7365..05fb48a 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -566,11 +566,7 @@ static void stk_free_buffers(struct stk_camera *dev)
 static int v4l_stk_open(struct file *fp)
 {
 	static int first_init = 1; /* webcam LED management */
-	struct stk_camera *dev;
-	struct video_device *vdev;
-
-	vdev = video_devdata(fp);
-	dev = vdev_to_camera(vdev);
+	struct stk_camera *dev = video_drvdata(fp);
 
 	if (dev == NULL || !is_present(dev))
 		return -ENXIO;
@@ -580,7 +576,6 @@ static int v4l_stk_open(struct file *fp)
 	else
 		first_init = 0;
 
-	fp->private_data = dev;
 	usb_autopm_get_interface(dev->interface);
 
 	return 0;
@@ -588,7 +583,7 @@ static int v4l_stk_open(struct file *fp)
 
 static int v4l_stk_release(struct file *fp)
 {
-	struct stk_camera *dev = fp->private_data;
+	struct stk_camera *dev = video_drvdata(fp);
 
 	if (dev->owner == fp) {
 		stk_stop_stream(dev);
@@ -611,7 +606,7 @@ static ssize_t v4l_stk_read(struct file *fp, char __user *buf,
 	int ret;
 	unsigned long flags;
 	struct stk_sio_buffer *sbuf;
-	struct stk_camera *dev = fp->private_data;
+	struct stk_camera *dev = video_drvdata(fp);
 
 	if (!is_present(dev))
 		return -EIO;
@@ -667,7 +662,7 @@ static ssize_t v4l_stk_read(struct file *fp, char __user *buf,
 
 static unsigned int v4l_stk_poll(struct file *fp, poll_table *wait)
 {
-	struct stk_camera *dev = fp->private_data;
+	struct stk_camera *dev = video_drvdata(fp);
 
 	poll_wait(fp, &dev->wait_frame, wait);
 
@@ -703,7 +698,7 @@ static int v4l_stk_mmap(struct file *fp, struct vm_area_struct *vma)
 	unsigned int i;
 	int ret;
 	unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
-	struct stk_camera *dev = fp->private_data;
+	struct stk_camera *dev = video_drvdata(fp);
 	struct stk_sio_buffer *sbuf = NULL;
 
 	if (!(vma->vm_flags & VM_WRITE) || !(vma->vm_flags & VM_SHARED))
@@ -841,7 +836,7 @@ static int stk_vidioc_g_fmt_vid_cap(struct file *filp,
 		void *priv, struct v4l2_format *f)
 {
 	struct v4l2_pix_format *pix_format = &f->fmt.pix;
-	struct stk_camera *dev = priv;
+	struct stk_camera *dev = video_drvdata(filp);
 	int i;
 
 	for (i = 0; i < ARRAY_SIZE(stk_sizes) &&
@@ -946,7 +941,7 @@ static int stk_vidioc_s_fmt_vid_cap(struct file *filp,
 		void *priv, struct v4l2_format *fmtd)
 {
 	int ret;
-	struct stk_camera *dev = priv;
+	struct stk_camera *dev = video_drvdata(filp);
 
 	if (dev == NULL)
 		return -ENODEV;
@@ -973,7 +968,7 @@ static int stk_vidioc_s_fmt_vid_cap(struct file *filp,
 static int stk_vidioc_reqbufs(struct file *filp,
 		void *priv, struct v4l2_requestbuffers *rb)
 {
-	struct stk_camera *dev = priv;
+	struct stk_camera *dev = video_drvdata(filp);
 
 	if (dev == NULL)
 		return -ENODEV;
@@ -999,7 +994,7 @@ static int stk_vidioc_reqbufs(struct file *filp,
 static int stk_vidioc_querybuf(struct file *filp,
 		void *priv, struct v4l2_buffer *buf)
 {
-	struct stk_camera *dev = priv;
+	struct stk_camera *dev = video_drvdata(filp);
 	struct stk_sio_buffer *sbuf;
 
 	if (buf->index >= dev->n_sbufs)
@@ -1012,7 +1007,7 @@ static int stk_vidioc_querybuf(struct file *filp,
 static int stk_vidioc_qbuf(struct file *filp,
 		void *priv, struct v4l2_buffer *buf)
 {
-	struct stk_camera *dev = priv;
+	struct stk_camera *dev = video_drvdata(filp);
 	struct stk_sio_buffer *sbuf;
 	unsigned long flags;
 
@@ -1036,7 +1031,7 @@ static int stk_vidioc_qbuf(struct file *filp,
 static int stk_vidioc_dqbuf(struct file *filp,
 		void *priv, struct v4l2_buffer *buf)
 {
-	struct stk_camera *dev = priv;
+	struct stk_camera *dev = video_drvdata(filp);
 	struct stk_sio_buffer *sbuf;
 	unsigned long flags;
 	int ret;
@@ -1069,7 +1064,7 @@ static int stk_vidioc_dqbuf(struct file *filp,
 static int stk_vidioc_streamon(struct file *filp,
 		void *priv, enum v4l2_buf_type type)
 {
-	struct stk_camera *dev = priv;
+	struct stk_camera *dev = video_drvdata(filp);
 	if (is_streaming(dev))
 		return 0;
 	if (dev->sio_bufs == NULL)
@@ -1081,7 +1076,7 @@ static int stk_vidioc_streamon(struct file *filp,
 static int stk_vidioc_streamoff(struct file *filp,
 		void *priv, enum v4l2_buf_type type)
 {
-	struct stk_camera *dev = priv;
+	struct stk_camera *dev = video_drvdata(filp);
 	unsigned long flags;
 	int i;
 	stk_stop_stream(dev);
@@ -1184,6 +1179,7 @@ static int stk_register_video_device(struct stk_camera *dev)
 	dev->vdev = stk_v4l_data;
 	dev->vdev.debug = debug;
 	dev->vdev.v4l2_dev = &dev->v4l2_dev;
+	video_set_drvdata(&dev->vdev, dev);
 	err = video_register_device(&dev->vdev, VFL_TYPE_GRABBER, -1);
 	if (err)
 		STK_ERROR("v4l registration failed\n");
-- 
1.7.10.4

[RFCv2 PATCH 06/12] stk-webcam: add support for control events and prio handling.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Also correct the first_init static: this should be part of the stk_camera struct.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |   27 +++++++++++++++++----------
 drivers/media/usb/stkwebcam/stk-webcam.h |    1 +
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index 05fb48a..272e1a2 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -35,6 +35,7 @@
 #include <linux/videodev2.h>
 #include <media/v4l2-common.h>
 #include <media/v4l2-ioctl.h>
+#include <media/v4l2-event.h>
 
 #include "stk-webcam.h"
 
@@ -565,20 +566,21 @@ static void stk_free_buffers(struct stk_camera *dev)
 
 static int v4l_stk_open(struct file *fp)
 {
-	static int first_init = 1; /* webcam LED management */
 	struct stk_camera *dev = video_drvdata(fp);
+	int err;
 
 	if (dev == NULL || !is_present(dev))
 		return -ENXIO;
 
-	if (!first_init)
+	if (!dev->first_init)
 		stk_camera_write_reg(dev, 0x0, 0x24);
 	else
-		first_init = 0;
-
-	usb_autopm_get_interface(dev->interface);
+		dev->first_init = 0;
 
-	return 0;
+	err = v4l2_fh_open(fp);
+	if (!err)
+		usb_autopm_get_interface(dev->interface);
+	return err;
 }
 
 static int v4l_stk_release(struct file *fp)
@@ -595,8 +597,7 @@ static int v4l_stk_release(struct file *fp)
 
 	if (is_present(dev))
 		usb_autopm_put_interface(dev->interface);
-
-	return 0;
+	return v4l2_fh_release(fp);
 }
 
 static ssize_t v4l_stk_read(struct file *fp, char __user *buf,
@@ -663,6 +664,7 @@ static ssize_t v4l_stk_read(struct file *fp, char __user *buf,
 static unsigned int v4l_stk_poll(struct file *fp, poll_table *wait)
 {
 	struct stk_camera *dev = video_drvdata(fp);
+	unsigned res = v4l2_ctrl_poll(fp, wait);
 
 	poll_wait(fp, &dev->wait_frame, wait);
 
@@ -670,9 +672,9 @@ static unsigned int v4l_stk_poll(struct file *fp, poll_table *wait)
 		return POLLERR;
 
 	if (!list_empty(&dev->sio_full))
-		return POLLIN | POLLRDNORM;
+		return res | POLLIN | POLLRDNORM;
 
-	return 0;
+	return res;
 }
 
 
@@ -1152,6 +1154,9 @@ static const struct v4l2_ioctl_ops v4l_stk_ioctl_ops = {
 	.vidioc_streamoff = stk_vidioc_streamoff,
 	.vidioc_g_parm = stk_vidioc_g_parm,
 	.vidioc_enum_framesizes = stk_vidioc_enum_framesizes,
+	.vidioc_log_status = v4l2_ctrl_log_status,
+	.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+	.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
 };
 
 static void stk_v4l_dev_release(struct video_device *vd)
@@ -1179,6 +1184,7 @@ static int stk_register_video_device(struct stk_camera *dev)
 	dev->vdev = stk_v4l_data;
 	dev->vdev.debug = debug;
 	dev->vdev.v4l2_dev = &dev->v4l2_dev;
+	set_bit(V4L2_FL_USE_FH_PRIO, &dev->vdev.flags);
 	video_set_drvdata(&dev->vdev, dev);
 	err = video_register_device(&dev->vdev, VFL_TYPE_GRABBER, -1);
 	if (err)
@@ -1232,6 +1238,7 @@ static int stk_camera_probe(struct usb_interface *interface,
 
 	spin_lock_init(&dev->spinlock);
 	init_waitqueue_head(&dev->wait_frame);
+	dev->first_init = 1; /* webcam LED management */
 
 	dev->udev = udev;
 	dev->interface = interface;
diff --git a/drivers/media/usb/stkwebcam/stk-webcam.h b/drivers/media/usb/stkwebcam/stk-webcam.h
index 901f0df..2156320 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.h
+++ b/drivers/media/usb/stkwebcam/stk-webcam.h
@@ -99,6 +99,7 @@ struct stk_camera {
 	struct usb_interface *interface;
 	int webcam_model;
 	struct file *owner;
+	int first_init;
 
 	u8 isoc_ep;
 
-- 
1.7.10.4

[RFCv2 PATCH 07/12] stk-webcam: fix querycap and simplify s_input.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Add device_caps support to querycap, fill in bus_info correctly and
do not set the version field (let the core handle that).

Also simplify the s_input ioctl.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index 272e1a2..c72a1c4 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -730,12 +730,15 @@ static int v4l_stk_mmap(struct file *fp, struct vm_area_struct *vma)
 static int stk_vidioc_querycap(struct file *filp,
 		void *priv, struct v4l2_capability *cap)
 {
+	struct stk_camera *dev = video_drvdata(filp);
+
 	strcpy(cap->driver, "stk");
 	strcpy(cap->card, "stk");
-	cap->version = DRIVER_VERSION_NUM;
+	usb_make_path(dev->udev, cap->bus_info, sizeof(cap->bus_info));
 
-	cap->capabilities = V4L2_CAP_VIDEO_CAPTURE
+	cap->device_caps = V4L2_CAP_VIDEO_CAPTURE
 		| V4L2_CAP_READWRITE | V4L2_CAP_STREAMING;
+	cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
 	return 0;
 }
 
@@ -759,10 +762,7 @@ static int stk_vidioc_g_input(struct file *filp, void *priv, unsigned int *i)
 
 static int stk_vidioc_s_input(struct file *filp, void *priv, unsigned int i)
 {
-	if (i != 0)
-		return -EINVAL;
-	else
-		return 0;
+	return i ? -EINVAL : 0;
 }
 
 static int stk_s_ctrl(struct v4l2_ctrl *ctrl)
-- 
1.7.10.4

[RFCv2 PATCH 08/12] stk-webcam: zero the priv field of v4l2_pix_format.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

The priv field should be set to 0. In this case the driver abused the priv
field for internal housekeeping. Modify the code so priv is no longer used
for that purpose.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |   23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index c72a1c4..ce802f7 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -859,11 +859,12 @@ static int stk_vidioc_g_fmt_vid_cap(struct file *filp,
 		pix_format->bytesperline = 2 * pix_format->width;
 	pix_format->sizeimage = pix_format->bytesperline
 				* pix_format->height;
+	pix_format->priv = 0;
 	return 0;
 }
 
-static int stk_vidioc_try_fmt_vid_cap(struct file *filp,
-		void *priv, struct v4l2_format *fmtd)
+static int stk_try_fmt_vid_cap(struct file *filp,
+		struct v4l2_format *fmtd, int *idx)
 {
 	int i;
 	switch (fmtd->fmt.pix.pixelformat) {
@@ -885,11 +886,13 @@ static int stk_vidioc_try_fmt_vid_cap(struct file *filp,
 			< abs(fmtd->fmt.pix.width - stk_sizes[i].w))) {
 		fmtd->fmt.pix.height = stk_sizes[i-1].h;
 		fmtd->fmt.pix.width = stk_sizes[i-1].w;
-		fmtd->fmt.pix.priv = i - 1;
+		if (idx)
+			*idx = i - 1;
 	} else {
 		fmtd->fmt.pix.height = stk_sizes[i].h;
 		fmtd->fmt.pix.width = stk_sizes[i].w;
-		fmtd->fmt.pix.priv = i;
+		if (idx)
+			*idx = i;
 	}
 
 	fmtd->fmt.pix.field = V4L2_FIELD_NONE;
@@ -900,9 +903,16 @@ static int stk_vidioc_try_fmt_vid_cap(struct file *filp,
 		fmtd->fmt.pix.bytesperline = 2 * fmtd->fmt.pix.width;
 	fmtd->fmt.pix.sizeimage = fmtd->fmt.pix.bytesperline
 		* fmtd->fmt.pix.height;
+	fmtd->fmt.pix.priv = 0;
 	return 0;
 }
 
+static int stk_vidioc_try_fmt_vid_cap(struct file *filp,
+		void *priv, struct v4l2_format *fmtd)
+{
+	return stk_try_fmt_vid_cap(filp, fmtd, NULL);
+}
+
 static int stk_setup_format(struct stk_camera *dev)
 {
 	int i = 0;
@@ -943,6 +953,7 @@ static int stk_vidioc_s_fmt_vid_cap(struct file *filp,
 		void *priv, struct v4l2_format *fmtd)
 {
 	int ret;
+	int idx;
 	struct stk_camera *dev = video_drvdata(filp);
 
 	if (dev == NULL)
@@ -953,7 +964,7 @@ static int stk_vidioc_s_fmt_vid_cap(struct file *filp,
 		return -EBUSY;
 	if (dev->owner && dev->owner != filp)
 		return -EBUSY;
-	ret = stk_vidioc_try_fmt_vid_cap(filp, priv, fmtd);
+	ret = stk_try_fmt_vid_cap(filp, fmtd, &idx);
 	if (ret)
 		return ret;
 	dev->owner = filp;
@@ -961,7 +972,7 @@ static int stk_vidioc_s_fmt_vid_cap(struct file *filp,
 	dev->vsettings.palette = fmtd->fmt.pix.pixelformat;
 	stk_free_buffers(dev);
 	dev->frame_size = fmtd->fmt.pix.sizeimage;
-	dev->vsettings.mode = stk_sizes[fmtd->fmt.pix.priv].m;
+	dev->vsettings.mode = stk_sizes[idx].m;
 
 	stk_initialise(dev);
 	return stk_setup_format(dev);
-- 
1.7.10.4

[RFCv2 PATCH 09/12] stk-webcam: enable core-locking.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

This makes it possible to switch to unlocked_ioctl.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |   24 ++++++++++++++++++++++--
 drivers/media/usb/stkwebcam/stk-webcam.h |    1 +
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index ce802f7..f3fabda 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -572,6 +572,8 @@ static int v4l_stk_open(struct file *fp)
 	if (dev == NULL || !is_present(dev))
 		return -ENXIO;
 
+	if (mutex_lock_interruptible(&dev->lock))
+		return -ERESTARTSYS;
 	if (!dev->first_init)
 		stk_camera_write_reg(dev, 0x0, 0x24);
 	else
@@ -580,6 +582,7 @@ static int v4l_stk_open(struct file *fp)
 	err = v4l2_fh_open(fp);
 	if (!err)
 		usb_autopm_get_interface(dev->interface);
+	mutex_unlock(&dev->lock);
 	return err;
 }
 
@@ -587,6 +590,7 @@ static int v4l_stk_release(struct file *fp)
 {
 	struct stk_camera *dev = video_drvdata(fp);
 
+	mutex_lock(&dev->lock);
 	if (dev->owner == fp) {
 		stk_stop_stream(dev);
 		stk_free_buffers(dev);
@@ -597,10 +601,11 @@ static int v4l_stk_release(struct file *fp)
 
 	if (is_present(dev))
 		usb_autopm_put_interface(dev->interface);
+	mutex_unlock(&dev->lock);
 	return v4l2_fh_release(fp);
 }
 
-static ssize_t v4l_stk_read(struct file *fp, char __user *buf,
+static ssize_t stk_read(struct file *fp, char __user *buf,
 		size_t count, loff_t *f_pos)
 {
 	int i;
@@ -661,6 +666,19 @@ static ssize_t v4l_stk_read(struct file *fp, char __user *buf,
 	return count;
 }
 
+static ssize_t v4l_stk_read(struct file *fp, char __user *buf,
+		size_t count, loff_t *f_pos)
+{
+	struct stk_camera *dev = video_drvdata(fp);
+	int ret;
+
+	if (mutex_lock_interruptible(&dev->lock))
+		return -ERESTARTSYS;
+	ret = stk_read(fp, buf, count, f_pos);
+	mutex_unlock(&dev->lock);
+	return ret;
+}
+
 static unsigned int v4l_stk_poll(struct file *fp, poll_table *wait)
 {
 	struct stk_camera *dev = video_drvdata(fp);
@@ -1145,7 +1163,7 @@ static struct v4l2_file_operations v4l_stk_fops = {
 	.read = v4l_stk_read,
 	.poll = v4l_stk_poll,
 	.mmap = v4l_stk_mmap,
-	.ioctl = video_ioctl2,
+	.unlocked_ioctl = video_ioctl2,
 };
 
 static const struct v4l2_ioctl_ops v4l_stk_ioctl_ops = {
@@ -1193,6 +1211,7 @@ static int stk_register_video_device(struct stk_camera *dev)
 	int err;
 
 	dev->vdev = stk_v4l_data;
+	dev->vdev.lock = &dev->lock;
 	dev->vdev.debug = debug;
 	dev->vdev.v4l2_dev = &dev->v4l2_dev;
 	set_bit(V4L2_FL_USE_FH_PRIO, &dev->vdev.flags);
@@ -1248,6 +1267,7 @@ static int stk_camera_probe(struct usb_interface *interface,
 	dev->v4l2_dev.ctrl_handler = hdl;
 
 	spin_lock_init(&dev->spinlock);
+	mutex_init(&dev->lock);
 	init_waitqueue_head(&dev->wait_frame);
 	dev->first_init = 1; /* webcam LED management */
 
diff --git a/drivers/media/usb/stkwebcam/stk-webcam.h b/drivers/media/usb/stkwebcam/stk-webcam.h
index 2156320..03550cf 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.h
+++ b/drivers/media/usb/stkwebcam/stk-webcam.h
@@ -99,6 +99,7 @@ struct stk_camera {
 	struct usb_interface *interface;
 	int webcam_model;
 	struct file *owner;
+	struct mutex lock;
 	int first_init;
 
 	u8 isoc_ep;
-- 
1.7.10.4

[RFCv2 PATCH 10/12] stk-webcam: fix read() handling when reqbufs was already called.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |    3 ++-
 drivers/media/usb/stkwebcam/stk-webcam.h |    1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index f3fabda..e3442de 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -616,7 +616,7 @@ static ssize_t stk_read(struct file *fp, char __user *buf,
 
 	if (!is_present(dev))
 		return -EIO;
-	if (dev->owner && dev->owner != fp)
+	if (dev->owner && (!dev->reading || dev->owner != fp))
 		return -EBUSY;
 	dev->owner = fp;
 	if (!is_streaming(dev)) {
@@ -624,6 +624,7 @@ static ssize_t stk_read(struct file *fp, char __user *buf,
 			|| stk_allocate_buffers(dev, 3)
 			|| stk_start_stream(dev))
 			return -ENOMEM;
+		dev->reading = 1;
 		spin_lock_irqsave(&dev->spinlock, flags);
 		for (i = 0; i < dev->n_sbufs; i++) {
 			list_add_tail(&dev->sio_bufs[i].list, &dev->sio_avail);
diff --git a/drivers/media/usb/stkwebcam/stk-webcam.h b/drivers/media/usb/stkwebcam/stk-webcam.h
index 03550cf..9bbfa3d 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.h
+++ b/drivers/media/usb/stkwebcam/stk-webcam.h
@@ -118,6 +118,7 @@ struct stk_camera {
 
 	int frame_size;
 	/* Streaming buffers */
+	int reading;
 	unsigned int n_sbufs;
 	struct stk_sio_buffer *sio_bufs;
 	struct list_head sio_avail;
-- 
1.7.10.4

[RFCv2 PATCH 11/12] stk-webcam: s_fmt shouldn't grab ownership.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index e3442de..0b25448 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -981,12 +981,11 @@ static int stk_vidioc_s_fmt_vid_cap(struct file *filp,
 		return -ENODEV;
 	if (is_streaming(dev))
 		return -EBUSY;
-	if (dev->owner && dev->owner != filp)
+	if (dev->owner)
 		return -EBUSY;
 	ret = stk_try_fmt_vid_cap(filp, fmtd, &idx);
 	if (ret)
 		return ret;
-	dev->owner = filp;
 
 	dev->vsettings.palette = fmtd->fmt.pix.pixelformat;
 	stk_free_buffers(dev);
-- 
1.7.10.4

[RFCv2 PATCH 12/12] stk-webcam: implement support for count == 0 when calling REQBUFS.

[Hans Verkuil]

From: Hans Verkuil <hans.verkuil@cisco.com>

The spec specifies that setting count to 0 in v4l2_requestbuffers
should result in releasing any streaming resources and the stream
ownership. Implement this.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Tested-by: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index 0b25448..5aeef83 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -1008,6 +1008,13 @@ static int stk_vidioc_reqbufs(struct file *filp,
 	if (is_streaming(dev)
 		|| (dev->owner && dev->owner != filp))
 		return -EBUSY;
+	stk_free_buffers(dev);
+	if (rb->count == 0) {
+		stk_camera_write_reg(dev, 0x0, 0x49); /* turn off the LED */
+		unset_initialised(dev);
+		dev->owner = NULL;
+		return 0;
+	}
 	dev->owner = filp;
 
 	/*FIXME If they ask for zero, we must stop streaming and free */
-- 
1.7.10.4

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Hans de Goede]

Hi,

Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around

No it is not.

On 02/10/2013 06:52 PM, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> This resulted in an upside-down picture.

No it does not, the laptop having an upside down mounted camera and not being
in the dmi-table is what causes an upside down picture. For a non upside
down camera (so no dmi-match) hflip and vflip should be 0.

The fix for the upside-down-ness Arvydas Sidorenko reported would be to
add his laptop to the upside down table.

Regards,

Hans

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Hans Verkuil]

On Mon February 11 2013 14:08:44 Hans de Goede wrote:
> Hi,
> 
> Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around
> 
> No it is not.

You are right, that patch makes no sense. It was a long day :-)

> On 02/10/2013 06:52 PM, Hans Verkuil wrote:
> > From: Hans Verkuil <hans.verkuil@cisco.com>
> >
> > This resulted in an upside-down picture.
> 
> No it does not, the laptop having an upside down mounted camera and not being
> in the dmi-table is what causes an upside down picture. For a non upside
> down camera (so no dmi-match) hflip and vflip should be 0.
> 
> The fix for the upside-down-ness Arvydas Sidorenko reported would be to
> add his laptop to the upside down table.

That doesn't make sense either. Arvydas, it worked fine for you before, right?
That is, if you use e.g. v3.8-rc7 then your picture is the right side up.

Can you confirm that?

Regards,

	Hans

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Hans de Goede]

Hi,

On 02/11/2013 02:21 PM, Hans Verkuil wrote:
> On Mon February 11 2013 14:08:44 Hans de Goede wrote:
>> Hi,
>>
>> Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around
>>
>> No it is not.
>
> You are right, that patch makes no sense. It was a long day :-)
>
>> On 02/10/2013 06:52 PM, Hans Verkuil wrote:
>>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>>
>>> This resulted in an upside-down picture.
>>
>> No it does not, the laptop having an upside down mounted camera and not being
>> in the dmi-table is what causes an upside down picture. For a non upside
>> down camera (so no dmi-match) hflip and vflip should be 0.
>>
>> The fix for the upside-down-ness Arvydas Sidorenko reported would be to
>> add his laptop to the upside down table.
>
> That doesn't make sense either. Arvydas, it worked fine for you before, right?

Yes, it probably worked before, but not with...

> That is, if you use e.g. v3.8-rc7 then your picture is the right side up.

3.8 will show it upside down for Arvydas

The story goes likes this:

1) Once upon a time the stkwebcam driver was written
2) The webcam in question was used mostly in Asus laptop models, including
the laptop of the original author of the driver, and in these models, in
typical Asus fashion (see the long long list for uvc cams inside v4l-utils),
they mounted the webcam-module the wrong way up. So the hflip and vflip
module options were given a default value of 1 (the correct value for
upside down mounted models)

3) Years later I got a bug report from a user with a laptop with stkwebcam,
where the module was actually mounted the right way up, and thus showed upside
down under Linux. So now I was facing the choice of 2 options:
a) Add a not-upside-down list to stkwebcam, which overrules the default
b) Do it like all the other drivers do, and make the default right for
cams mounted the proper way and add an upside-down model list, with models
where we need to flip-by-default.

Despite knowing that going b) would cause a period of pain where we were
building the table (ie what we're discussing now) I opted to go for option
b), since a) is just too ugly, and worse different from how every other
driver does it leading to confusion in the long run.

IOW this is entirely my fault, and I take full responsibility for it.

Arvydas, can you please run "sudo dmidecode > dmi.log", and send me or
Hans V. the generated dmi.log file? Then we can add your laptop to the
upside-down model list.

Regards,

Hans

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Hans Verkuil]

On Mon February 11 2013 14:41:08 Hans de Goede wrote:
> Hi,
> 
> On 02/11/2013 02:21 PM, Hans Verkuil wrote:
> > On Mon February 11 2013 14:08:44 Hans de Goede wrote:
> >> Hi,
> >>
> >> Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around
> >>
> >> No it is not.
> >
> > You are right, that patch makes no sense. It was a long day :-)
> >
> >> On 02/10/2013 06:52 PM, Hans Verkuil wrote:
> >>> From: Hans Verkuil <hans.verkuil@cisco.com>
> >>>
> >>> This resulted in an upside-down picture.
> >>
> >> No it does not, the laptop having an upside down mounted camera and not being
> >> in the dmi-table is what causes an upside down picture. For a non upside
> >> down camera (so no dmi-match) hflip and vflip should be 0.
> >>
> >> The fix for the upside-down-ness Arvydas Sidorenko reported would be to
> >> add his laptop to the upside down table.
> >
> > That doesn't make sense either. Arvydas, it worked fine for you before, right?
> 
> Yes, it probably worked before, but not with...
> 
> > That is, if you use e.g. v3.8-rc7 then your picture is the right side up.
> 
> 3.8 will show it upside down for Arvydas
> 
> The story goes likes this:
> 
> 1) Once upon a time the stkwebcam driver was written
> 2) The webcam in question was used mostly in Asus laptop models, including
> the laptop of the original author of the driver, and in these models, in
> typical Asus fashion (see the long long list for uvc cams inside v4l-utils),
> they mounted the webcam-module the wrong way up. So the hflip and vflip
> module options were given a default value of 1 (the correct value for
> upside down mounted models)
> 
> 3) Years later I got a bug report from a user with a laptop with stkwebcam,
> where the module was actually mounted the right way up, and thus showed upside
> down under Linux. So now I was facing the choice of 2 options:
> a) Add a not-upside-down list to stkwebcam, which overrules the default
> b) Do it like all the other drivers do, and make the default right for
> cams mounted the proper way and add an upside-down model list, with models
> where we need to flip-by-default.
> 
> Despite knowing that going b) would cause a period of pain where we were
> building the table (ie what we're discussing now) I opted to go for option
> b), since a) is just too ugly, and worse different from how every other
> driver does it leading to confusion in the long run.
> 
> IOW this is entirely my fault, and I take full responsibility for it.

Ah, OK. Now it makes sense. I wasn't aware of this history and it (clearly)
confused me greatly.

Can you perhaps provide me with a patch that adds some comments to the source
explaining this. And in particular with which kernel this change took place?

The next time some poor sod (e.g. me) has to work on this the comments should
explain this history.

> 
> Arvydas, can you please run "sudo dmidecode > dmi.log", and send me or
> Hans V. the generated dmi.log file? Then we can add your laptop to the
> upside-down model list.

When I have this information I'll update my patch series and ask Arvydas
to test again.

Regards,

	Hans

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Hans de Goede]

Hi,

On 02/11/2013 02:51 PM, Hans Verkuil wrote:
> On Mon February 11 2013 14:41:08 Hans de Goede wrote:
>> Hi,
>>
>> On 02/11/2013 02:21 PM, Hans Verkuil wrote:
>>> On Mon February 11 2013 14:08:44 Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around
>>>>
>>>> No it is not.
>>>
>>> You are right, that patch makes no sense. It was a long day :-)
>>>
>>>> On 02/10/2013 06:52 PM, Hans Verkuil wrote:
>>>>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>>>>
>>>>> This resulted in an upside-down picture.
>>>>
>>>> No it does not, the laptop having an upside down mounted camera and not being
>>>> in the dmi-table is what causes an upside down picture. For a non upside
>>>> down camera (so no dmi-match) hflip and vflip should be 0.
>>>>
>>>> The fix for the upside-down-ness Arvydas Sidorenko reported would be to
>>>> add his laptop to the upside down table.
>>>
>>> That doesn't make sense either. Arvydas, it worked fine for you before, right?
>>
>> Yes, it probably worked before, but not with...
>>
>>> That is, if you use e.g. v3.8-rc7 then your picture is the right side up.
>>
>> 3.8 will show it upside down for Arvydas
>>
>> The story goes likes this:
>>
>> 1) Once upon a time the stkwebcam driver was written
>> 2) The webcam in question was used mostly in Asus laptop models, including
>> the laptop of the original author of the driver, and in these models, in
>> typical Asus fashion (see the long long list for uvc cams inside v4l-utils),
>> they mounted the webcam-module the wrong way up. So the hflip and vflip
>> module options were given a default value of 1 (the correct value for
>> upside down mounted models)
>>
>> 3) Years later I got a bug report from a user with a laptop with stkwebcam,
>> where the module was actually mounted the right way up, and thus showed upside
>> down under Linux. So now I was facing the choice of 2 options:
>> a) Add a not-upside-down list to stkwebcam, which overrules the default
>> b) Do it like all the other drivers do, and make the default right for
>> cams mounted the proper way and add an upside-down model list, with models
>> where we need to flip-by-default.
>>
>> Despite knowing that going b) would cause a period of pain where we were
>> building the table (ie what we're discussing now) I opted to go for option
>> b), since a) is just too ugly, and worse different from how every other
>> driver does it leading to confusion in the long run.
>>
>> IOW this is entirely my fault, and I take full responsibility for it.
>
> Ah, OK. Now it makes sense. I wasn't aware of this history and it (clearly)
> confused me greatly.
>
> Can you perhaps provide me with a patch that adds some comments to the source
> explaining this. And in particular with which kernel this change took place?

Feel free to copy my 1) - 3) From above to a comment, step 3 landed in kernel 3.6
(you doing it seems better then me doing a patch conflicting with your patchset)

> The next time some poor sod (e.g. me) has to work on this the comments should
> explain this history.

Ack.

Regards,

Hans

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Anca Emanuel]

I think the driver is not up to standard: look at the error messages.
And there are a lot of "to do" because of lack of documentation.

On Mon, Feb 11, 2013 at 4:55 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
>
> On 02/11/2013 02:51 PM, Hans Verkuil wrote:
>>
>> On Mon February 11 2013 14:41:08 Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> On 02/11/2013 02:21 PM, Hans Verkuil wrote:
>>>>
>>>> On Mon February 11 2013 14:08:44 Hans de Goede wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Subject: stk-webcam: the initial hflip and vflip setup was the wrong
>>>>> way around
>>>>>
>>>>> No it is not.
>>>>
>>>>
>>>> You are right, that patch makes no sense. It was a long day :-)
>>>>
>>>>> On 02/10/2013 06:52 PM, Hans Verkuil wrote:
>>>>>>
>>>>>> From: Hans Verkuil <hans.verkuil@cisco.com>
>>>>>>
>>>>>> This resulted in an upside-down picture.
>>>>>
>>>>>
>>>>> No it does not, the laptop having an upside down mounted camera and not
>>>>> being
>>>>> in the dmi-table is what causes an upside down picture. For a non
>>>>> upside
>>>>> down camera (so no dmi-match) hflip and vflip should be 0.
>>>>>
>>>>> The fix for the upside-down-ness Arvydas Sidorenko reported would be to
>>>>> add his laptop to the upside down table.
>>>>
>>>>
>>>> That doesn't make sense either. Arvydas, it worked fine for you before,
>>>> right?
>>>
>>>
>>> Yes, it probably worked before, but not with...
>>>
>>>> That is, if you use e.g. v3.8-rc7 then your picture is the right side
>>>> up.
>>>
>>>
>>> 3.8 will show it upside down for Arvydas
>>>
>>> The story goes likes this:
>>>
>>> 1) Once upon a time the stkwebcam driver was written
>>> 2) The webcam in question was used mostly in Asus laptop models,
>>> including
>>> the laptop of the original author of the driver, and in these models, in
>>> typical Asus fashion (see the long long list for uvc cams inside
>>> v4l-utils),
>>> they mounted the webcam-module the wrong way up. So the hflip and vflip
>>> module options were given a default value of 1 (the correct value for
>>> upside down mounted models)
>>>
>>> 3) Years later I got a bug report from a user with a laptop with
>>> stkwebcam,
>>> where the module was actually mounted the right way up, and thus showed
>>> upside
>>> down under Linux. So now I was facing the choice of 2 options:
>>> a) Add a not-upside-down list to stkwebcam, which overrules the default
>>> b) Do it like all the other drivers do, and make the default right for
>>> cams mounted the proper way and add an upside-down model list, with
>>> models
>>> where we need to flip-by-default.
>>>
>>> Despite knowing that going b) would cause a period of pain where we were
>>> building the table (ie what we're discussing now) I opted to go for
>>> option
>>> b), since a) is just too ugly, and worse different from how every other
>>> driver does it leading to confusion in the long run.
>>>
>>> IOW this is entirely my fault, and I take full responsibility for it.
>>
>>
>> Ah, OK. Now it makes sense. I wasn't aware of this history and it
>> (clearly)
>> confused me greatly.
>>
>> Can you perhaps provide me with a patch that adds some comments to the
>> source
>> explaining this. And in particular with which kernel this change took
>> place?
>
>
> Feel free to copy my 1) - 3) From above to a comment, step 3 landed in
> kernel 3.6
> (you doing it seems better then me doing a patch conflicting with your
> patchset)
>
>
>> The next time some poor sod (e.g. me) has to work on this the comments
>> should
>> explain this history.
>
>
> Ack.
>
>
> Regards,
>
> Hans
> --
> 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

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Arvydas Sidorenko]

On Mon, Feb 11, 2013 at 2:21 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> That doesn't make sense either. Arvydas, it worked fine for you before, right?
> That is, if you use e.g. v3.8-rc7 then your picture is the right side up.
>

It is upside down using any v3.7.x or v3.8-rc7. I didn't pay attention
in the older versions, but I am aware of this issue since pre-v3.

On Mon, Feb 11, 2013 at 2:41 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Arvydas, can you please run "sudo dmidecode > dmi.log", and send me or
> Hans V. the generated dmi.log file? Then we can add your laptop to the
> upside-down model list.
>

$ sudo dmidecode
# dmidecode 2.11
SMBIOS 2.4 present.
37 structures occupying 1499 bytes.
Table at 0x000E5020.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: American Megatrends Inc.
	Version: 305
	Release Date: 02/15/2007
	Address: 0xF0000
	Runtime Size: 64 kB
	ROM Size: 512 kB
	Characteristics:
		ISA is supported
		PCI is supported
		PC Card (PCMCIA) is supported
		PNP is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		ESCD support is available
		Boot from CD is supported
		Selectable boot is supported
		EDD is supported
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		Smart battery is supported
		BIOS boot specification is supported
		Function key-initiated network boot is supported
		Targeted content distribution is supported
	BIOS Revision: 1.124
	Firmware Revision: 168.153

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: ASUSTeK Computer Inc.
	Product Name: F3JC
	Version: 1.0
	Serial Number: SSN12345678901234567
	UUID: F13181DB-43CD-9AAD-CE00-0018F338B599
	Wake-up Type: Power Switch
	SKU Number:
	Family:

Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
	Manufacturer: ASUSTeK Computer Inc.
	Product Name: F3JC
	Version: 1.0
	Serial Number: BSN12345678901234567
	Asset Tag: ATN12345678901234567
	Features:
		Board is a hosting board
		Board requires at least one daughter board
		Board is replaceable
	Location In Chassis: MIDDLE
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
	Manufacturer: ASUSTeK Computer Inc.
	Type: Notebook
	Lock: Not Present
	Version:
	Serial Number:
	Asset Tag:
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0

Handle 0x0004, DMI type 4, 35 bytes
Processor Information
	Socket Designation: Socket 478
	Type: Central Processor
	Family: Other
	Manufacturer: Intel
	ID: F6 06 00 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 15, Stepping 6
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (FXSAVE and FXSTOR instructions supported)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Multi-threading)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz
	Voltage: 1.1 V
	External Clock: 167 MHz
	Max Speed: 1667 MHz
	Current Speed: 1666 MHz
	Status: Populated, Enabled
	Upgrade: Socket 423
	L1 Cache Handle: 0x0005
	L2 Cache Handle: 0x0006
	L3 Cache Handle: Not Provided
	Serial Number: PSN12345678901234567
	Asset Tag: PATN1234567890123456
	Part Number: PPN12345678901234567

Handle 0x0005, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L1-Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 64 kB
	Maximum Size: 64 kB
	Supported SRAM Types:
		Other
	Installed SRAM Type: Other
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Instruction
	Associativity: 8-way Set-associative

Handle 0x0006, DMI type 7, 19 bytes
Cache Information
	Socket Designation: L2-Cache
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 2048 kB
	Maximum Size: 2048 kB
	Supported SRAM Types:
		Other
	Installed SRAM Type: Other
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 8-way Set-associative

Handle 0x0007, DMI type 5, 20 bytes
Memory Controller Information
	Error Detecting Method: None
	Error Correcting Capabilities:
		None
	Supported Interleave: One-way Interleave
	Current Interleave: One-way Interleave
	Maximum Memory Module Size: 1024 MB
	Maximum Total Memory Size: 2048 MB
	Supported Speeds:
		Other
		70 ns
		60 ns
		50 ns
	Supported Memory Types:
		Standard
		DIMM
		SDRAM
	Memory Module Voltage: 3.3 V
	Associated Memory Slots: 2
		0x0008
		0x0009
	Enabled Error Correcting Capabilities:
		None

Handle 0x0008, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM0
	Bank Connections: 0 1
	Current Speed: Unknown
	Type: Standard DIMM SDRAM
	Installed Size: 1024 MB (Double-bank Connection)
	Enabled Size: 1024 MB (Double-bank Connection)
	Error Status: OK

Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM1
	Bank Connections: 2 3
	Current Speed: Unknown
	Type: Standard DIMM SDRAM
	Installed Size: 2048 MB (Double-bank Connection)
	Enabled Size: 2048 MB (Double-bank Connection)
	Error Status: OK

Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CON18
	Internal Connector Type: None
	External Reference Designator: USB1
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000B, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CON18
	Internal Connector Type: None
	External Reference Designator: USB2
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CON19
	Internal Connector Type: None
	External Reference Designator: USB3
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CON19
	Internal Connector Type: None
	External Reference Designator: USB4
	External Connector Type: Access Bus (USB)
	Port Type: USB

Handle 0x000E, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: BCON1
	Internal Connector Type: None
	External Reference Designator: 1394
	External Connector Type: IEEE 1394
	Port Type: Firewire (IEEE P1394)

Handle 0x000F, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CON28
	Internal Connector Type: None
	External Reference Designator: MODEM
	External Connector Type: RJ-11
	Port Type: Modem Port

Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CON28
	Internal Connector Type: None
	External Reference Designator: LAN
	External Connector Type: RJ-45
	Port Type: Network Port

Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J1
	Internal Connector Type: None
	External Reference Designator: Headphone Out
	External Connector Type: Mini Jack (headphones)
	Port Type: Audio Port

Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: J2
	Internal Connector Type: None
	External Reference Designator: Mic In
	External Connector Type: Mini Jack (headphones)
	Port Type: Audio Port

Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CON4
	Internal Connector Type: None
	External Reference Designator: Video
	External Connector Type: DB-15 female
	Port Type: Video Port

Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CON13
	Internal Connector Type: None
	External Reference Designator: SD/MMC/MS
	External Connector Type: Other
	Port Type: Other

Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CON12
	Internal Connector Type: None
	External Reference Designator: CARD BUS
	External Connector Type: 68 Pin Dual Inline
	Port Type: Cardbus

Handle 0x0016, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: CN12
	Internal Connector Type: None
	External Reference Designator: Multi Port
	External Connector Type: Other
	Port Type: Other

Handle 0x0017, DMI type 9, 13 bytes
System Slot Information
	Designation: PCIE1
	Type: x1 PCI Express
	Current Usage: Available
	Length: Short
	ID: 1
	Characteristics:
		3.3 V is provided
		PME signal is supported

Handle 0x0018, DMI type 10, 6 bytes
On Board Device Information
	Type: Video
	Status: Enabled
	Description: AGP VGA controller

Handle 0x0019, DMI type 10, 6 bytes
On Board Device Information
	Type: Ethernet
	Status: Enabled
	Description: Ethernet controller

Handle 0x001A, DMI type 10, 6 bytes
On Board Device Information
	Type: Sound
	Status: Enabled
	Description: Audio controller

Handle 0x001B, DMI type 10, 6 bytes
On Board Device Information
	Type: Other
	Status: Enabled
	Description: Modem controller

Handle 0x001C, DMI type 13, 22 bytes
BIOS Language Information
	Language Description Format: Abbreviated
	Installable Languages: 1
		en|US|iso8859-1
	Currently Installed Language: en|US|iso8859-1

Handle 0x001D, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 4 GB
	Error Information Handle: Not Provided
	Number Of Devices: 2

Handle 0x001E, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000B80003FF
	Range Size: 2944 MB
	Physical Array Handle: 0x001D
	Partition Width: 4

Handle 0x001F, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x001D
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 1024 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM0
	Bank Locator: BANK0
	Type: SDRAM
	Type Detail: Synchronous
	Speed: Unknown
	Manufacturer: Manufacturer0
	Serial Number: SerNum0
	Asset Tag: AssetTagNum0
	Part Number: PartNum0

Handle 0x0020, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0003FFFFFFF
	Range Size: 1 GB
	Physical Device Handle: 0x001F
	Memory Array Mapped Address Handle: 0x001E
	Partition Row Position: 1
	Interleaved Data Depth: 1

Handle 0x0021, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x001D
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: None
	Locator: DIMM1
	Bank Locator: BANK1
	Type: SDRAM
	Type Detail: Synchronous
	Speed: Unknown
	Manufacturer: Manufacturer1
	Serial Number: SerNum1
	Asset Tag: AssetTagNum1
	Part Number: PartNum1

Handle 0x0022, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00040000000
	Ending Address: 0x000BFFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0021
	Memory Array Mapped Address Handle: 0x001E
	Partition Row Position: 1
	Interleaved Data Depth: 1

Handle 0x0023, DMI type 200, 7 bytes
OEM-specific Type
	Header and Data:
		C8 07 23 00 01 02 03
	Strings:
		1043
		F3J
		305

Handle 0x0024, DMI type 127, 4 bytes
End Of Table


Arvydas

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Hans Verkuil]

On Mon February 11 2013 16:32:58 Arvydas Sidorenko wrote:
> On Mon, Feb 11, 2013 at 2:21 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> >
> > That doesn't make sense either. Arvydas, it worked fine for you before, right?
> > That is, if you use e.g. v3.8-rc7 then your picture is the right side up.
> >
> 
> It is upside down using any v3.7.x or v3.8-rc7. I didn't pay attention
> in the older versions, but I am aware of this issue since pre-v3.
> 
> On Mon, Feb 11, 2013 at 2:41 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> >
> > Arvydas, can you please run "sudo dmidecode > dmi.log", and send me or
> > Hans V. the generated dmi.log file? Then we can add your laptop to the
> > upside-down model list.
> >
> 
> $ sudo dmidecode


Thanks!

I've updated my stkwebcam git branch (note: it was rebased, so you can't just
do a git pull). If you can do a final test?

Regards,

	Hans

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Hans Verkuil]

On Sun February 10 2013 18:52:42 Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
> 
> This resulted in an upside-down picture.
> 
> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
> Tested-by: Arvydas Sidorenko <asido4@gmail.com>

As mentioned in this thread, this patch was wrong. It's now replaced by the
version below which includes the background information given by Hans de Goede.

Regards,

	Hans

[PATCH 01/12] stk-webcam: add ASUS F3JC to upside-down list.

And add an extensive comment relating the history of the upside-down
handling in this driver.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Thanks-to: Hans de Goede <hdegoede@redhat.com>
Thanks-to: Arvydas Sidorenko <asido4@gmail.com>
---
 drivers/media/usb/stkwebcam/stk-webcam.c |   40 +++++++++++++++++++++++++++++-
 1 file changed, 39 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/stkwebcam/stk-webcam.c b/drivers/media/usb/stkwebcam/stk-webcam.c
index 4cbab08..b2a5ee4 100644
--- a/drivers/media/usb/stkwebcam/stk-webcam.c
+++ b/drivers/media/usb/stkwebcam/stk-webcam.c
@@ -63,7 +63,39 @@ static struct usb_device_id stkwebcam_table[] = {
 };
 MODULE_DEVICE_TABLE(usb, stkwebcam_table);
 
-/* The stk webcam laptop module is mounted upside down in some laptops :( */
+/*
+ * The stk webcam laptop module is mounted upside down in some laptops :(
+ *
+ * Some background information (thanks to Hans de Goede for providing this):
+ *
+ * 1) Once upon a time the stkwebcam driver was written
+ *
+ * 2) The webcam in question was used mostly in Asus laptop models, including
+ * the laptop of the original author of the driver, and in these models, in
+ * typical Asus fashion (see the long long list for uvc cams inside v4l-utils),
+ * they mounted the webcam-module the wrong way up. So the hflip and vflip
+ * module options were given a default value of 1 (the correct value for
+ * upside down mounted models)
+ *
+ * 3) Years later I got a bug report from a user with a laptop with stkwebcam,
+ * where the module was actually mounted the right way up, and thus showed
+ * upside down under Linux. So now I was facing the choice of 2 options:
+ *
+ * a) Add a not-upside-down list to stkwebcam, which overrules the default.
+ *
+ * b) Do it like all the other drivers do, and make the default right for
+ *    cams mounted the proper way and add an upside-down model list, with
+ *    models where we need to flip-by-default.
+ *
+ * Despite knowing that going b) would cause a period of pain where we were
+ * building the table I opted to go for option b), since a) is just too ugly,
+ * and worse different from how every other driver does it leading to
+ * confusion in the long run. This change was made in kernel 3.6.
+ *
+ * So for any user report about upside-down images since kernel 3.6 ask them
+ * to provide the output of 'sudo dmidecode' so the laptop can be added in
+ * the table below.
+ */
 static const struct dmi_system_id stk_upside_down_dmi_table[] = {
 	{
 		.ident = "ASUS G1",
@@ -71,6 +103,12 @@ static const struct dmi_system_id stk_upside_down_dmi_table[] = {
 			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
 			DMI_MATCH(DMI_PRODUCT_NAME, "G1")
 		}
+	}, {
+		.ident = "ASUS F3JC",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "F3JC")
+		}
 	},
 	{}
 };
-- 
1.7.10.4

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Hans Verkuil]

On Tue February 12 2013 09:28:55 Hans Verkuil wrote:
> On Mon February 11 2013 16:32:58 Arvydas Sidorenko wrote:
> > On Mon, Feb 11, 2013 at 2:21 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > >
> > > That doesn't make sense either. Arvydas, it worked fine for you before, right?
> > > That is, if you use e.g. v3.8-rc7 then your picture is the right side up.
> > >
> > 
> > It is upside down using any v3.7.x or v3.8-rc7. I didn't pay attention
> > in the older versions, but I am aware of this issue since pre-v3.
> > 
> > On Mon, Feb 11, 2013 at 2:41 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> > >
> > > Arvydas, can you please run "sudo dmidecode > dmi.log", and send me or
> > > Hans V. the generated dmi.log file? Then we can add your laptop to the
> > > upside-down model list.
> > >
> > 
> > $ sudo dmidecode
> 
> 
> Thanks!
> 
> I've updated my stkwebcam git branch (note: it was rebased, so you can't just
> do a git pull). If you can do a final test?

Arvydas, can you please test this? I'd like to do a git pull tomorrow and I'd
like to know if the upside-down changes are now OK.

Thanks,

	Hans

Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around

[Arvydas Sidorenko]

On Thu, Feb 14, 2013 at 8:12 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> Arvydas, can you please test this? I'd like to do a git pull tomorrow and I'd
> like to know if the upside-down changes are now OK.
>
> Thanks,
>

Hi Hans

Everything is working fine now - dmesg is clean, LED lights on and off
when needed, viewport angle is correct.

Thanks for the fixes.

Arvydas