* [RFCv2 PATCH 02/12] stk-webcam: remove bogus STD support.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 03/12] stk-webcam: add support for struct v4l2_device Hans Verkuil
` (11 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 03/12] stk-webcam: add support for struct v4l2_device.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 02/12] stk-webcam: remove bogus STD support Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 04/12] stk-webcam: convert to the control framework Hans Verkuil
` (10 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 04/12] stk-webcam: convert to the control framework.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 02/12] stk-webcam: remove bogus STD support Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 03/12] stk-webcam: add support for struct v4l2_device Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 05/12] stk-webcam: don't use private_data, use video_drvdata Hans Verkuil
` (9 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 05/12] stk-webcam: don't use private_data, use video_drvdata
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (2 preceding siblings ...)
2013-02-10 17:52 ` [RFCv2 PATCH 04/12] stk-webcam: convert to the control framework Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 06/12] stk-webcam: add support for control events and prio handling Hans Verkuil
` (8 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 06/12] stk-webcam: add support for control events and prio handling.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (3 preceding siblings ...)
2013-02-10 17:52 ` [RFCv2 PATCH 05/12] stk-webcam: don't use private_data, use video_drvdata Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 07/12] stk-webcam: fix querycap and simplify s_input Hans Verkuil
` (7 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 07/12] stk-webcam: fix querycap and simplify s_input.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (4 preceding siblings ...)
2013-02-10 17:52 ` [RFCv2 PATCH 06/12] stk-webcam: add support for control events and prio handling Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 08/12] stk-webcam: zero the priv field of v4l2_pix_format Hans Verkuil
` (6 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 08/12] stk-webcam: zero the priv field of v4l2_pix_format.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (5 preceding siblings ...)
2013-02-10 17:52 ` [RFCv2 PATCH 07/12] stk-webcam: fix querycap and simplify s_input Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 09/12] stk-webcam: enable core-locking Hans Verkuil
` (5 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 09/12] stk-webcam: enable core-locking.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (6 preceding siblings ...)
2013-02-10 17:52 ` [RFCv2 PATCH 08/12] stk-webcam: zero the priv field of v4l2_pix_format Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 10/12] stk-webcam: fix read() handling when reqbufs was already called Hans Verkuil
` (4 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 10/12] stk-webcam: fix read() handling when reqbufs was already called.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (7 preceding siblings ...)
2013-02-10 17:52 ` [RFCv2 PATCH 09/12] stk-webcam: enable core-locking Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 11/12] stk-webcam: s_fmt shouldn't grab ownership Hans Verkuil
` (3 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 11/12] stk-webcam: s_fmt shouldn't grab ownership.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (8 preceding siblings ...)
2013-02-10 17:52 ` [RFCv2 PATCH 10/12] stk-webcam: fix read() handling when reqbufs was already called Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-10 17:52 ` [RFCv2 PATCH 12/12] stk-webcam: implement support for count == 0 when calling REQBUFS Hans Verkuil
` (2 subsequent siblings)
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* [RFCv2 PATCH 12/12] stk-webcam: implement support for count == 0 when calling REQBUFS.
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (9 preceding siblings ...)
2013-02-10 17:52 ` [RFCv2 PATCH 11/12] stk-webcam: s_fmt shouldn't grab ownership Hans Verkuil
@ 2013-02-10 17:52 ` Hans Verkuil
2013-02-11 13:08 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans de Goede
2013-02-12 8:30 ` Hans Verkuil
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-10 17:52 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (10 preceding siblings ...)
2013-02-10 17:52 ` [RFCv2 PATCH 12/12] stk-webcam: implement support for count == 0 when calling REQBUFS Hans Verkuil
@ 2013-02-11 13:08 ` Hans de Goede
2013-02-11 13:21 ` Hans Verkuil
2013-02-12 8:30 ` Hans Verkuil
12 siblings, 1 reply; 24+ messages in thread
From: Hans de Goede @ 2013-02-11 13:08 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-media, Hans Verkuil
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-11 13:08 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans de Goede
@ 2013-02-11 13:21 ` Hans Verkuil
2013-02-11 13:41 ` Hans de Goede
0 siblings, 1 reply; 24+ messages in thread
From: Hans Verkuil @ 2013-02-11 13:21 UTC (permalink / raw)
To: Hans de Goede, Arvydas Sidorenko; +Cc: linux-media
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-11 13:21 ` Hans Verkuil
@ 2013-02-11 13:41 ` Hans de Goede
2013-02-11 13:51 ` Hans Verkuil
2013-02-11 15:32 ` Arvydas Sidorenko
0 siblings, 2 replies; 24+ messages in thread
From: Hans de Goede @ 2013-02-11 13:41 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Arvydas Sidorenko, linux-media
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-11 13:41 ` Hans de Goede
@ 2013-02-11 13:51 ` Hans Verkuil
2013-02-11 14:55 ` Hans de Goede
2013-02-11 15:32 ` Arvydas Sidorenko
1 sibling, 1 reply; 24+ messages in thread
From: Hans Verkuil @ 2013-02-11 13:51 UTC (permalink / raw)
To: Hans de Goede; +Cc: Arvydas Sidorenko, linux-media
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-11 13:51 ` Hans Verkuil
@ 2013-02-11 14:55 ` Hans de Goede
2013-02-11 15:11 ` Anca Emanuel
0 siblings, 1 reply; 24+ messages in thread
From: Hans de Goede @ 2013-02-11 14:55 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Arvydas Sidorenko, linux-media
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-11 14:55 ` Hans de Goede
@ 2013-02-11 15:11 ` Anca Emanuel
0 siblings, 0 replies; 24+ messages in thread
From: Anca Emanuel @ 2013-02-11 15:11 UTC (permalink / raw)
To: Hans de Goede; +Cc: Hans Verkuil, Arvydas Sidorenko, linux-media
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-11 13:41 ` Hans de Goede
2013-02-11 13:51 ` Hans Verkuil
@ 2013-02-11 15:32 ` Arvydas Sidorenko
2013-02-12 8:28 ` Hans Verkuil
1 sibling, 1 reply; 24+ messages in thread
From: Arvydas Sidorenko @ 2013-02-11 15:32 UTC (permalink / raw)
To: Hans de Goede; +Cc: Hans Verkuil, linux-media
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-11 15:32 ` Arvydas Sidorenko
@ 2013-02-12 8:28 ` Hans Verkuil
2013-02-14 8:12 ` Hans Verkuil
0 siblings, 1 reply; 24+ messages in thread
From: Hans Verkuil @ 2013-02-12 8:28 UTC (permalink / raw)
To: Arvydas Sidorenko; +Cc: Hans de Goede, linux-media
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-12 8:28 ` Hans Verkuil
@ 2013-02-14 8:12 ` Hans Verkuil
2013-02-14 10:13 ` Arvydas Sidorenko
0 siblings, 1 reply; 24+ messages in thread
From: Hans Verkuil @ 2013-02-14 8:12 UTC (permalink / raw)
To: Arvydas Sidorenko; +Cc: Hans de Goede, linux-media
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-14 8:12 ` Hans Verkuil
@ 2013-02-14 10:13 ` Arvydas Sidorenko
0 siblings, 0 replies; 24+ messages in thread
From: Arvydas Sidorenko @ 2013-02-14 10:13 UTC (permalink / raw)
To: Hans Verkuil; +Cc: Hans de Goede, linux-media
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
2013-02-10 17:52 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans Verkuil
` (11 preceding siblings ...)
2013-02-11 13:08 ` [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around Hans de Goede
@ 2013-02-12 8:30 ` Hans Verkuil
12 siblings, 0 replies; 24+ messages in thread
From: Hans Verkuil @ 2013-02-12 8:30 UTC (permalink / raw)
To: linux-media; +Cc: Hans de Goede, 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
^ permalink raw reply related [flat|nested] 24+ messages in thread