Re: Problems with the gspca_ov519 driver
Hi, On 05/22/2012 11:02 PM, Antonio Ospite wrote: snip I feel I can add a: Tested-by: Antonio Ospiteosp...@studenti.unina.it Thanks added to the commit message. I can backport the change to older kernels and even CC linux-stable if you think it is appropriate, that's the least I can do to expiate for knowing about a bug/regression and not hunting its cause hard enough. Hehe, I've CC-ed sta...@kernel.org on the patch, it should apply cleanly to older versions, so no backporting is needed. HdG maybe you could mention f7059ea in the commit message of this fix if you can confirm the problem was introduced there. I can confirm that the problem was introduced there and I've added a reference to that commmit to the commit message thanks for looking that commit up! Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problems with the gspca_ov519 driver
Hello, I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5). As an additional note, pinchartl on irc #v4l says to favour a moving of gspca to vb2. I don't know what it means. Can someone take care of the bug, or should I consider the camera 'non working' in linux? Thank you, Lluís. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the gspca_ov519 driver
Hi, This bug also causes the camera to crash when changing fps in guvcview, uvc devices (at least all the ones I tested) require the stream to be restarted for fps to change, so in the case of this driver after STREAMOFF the camera just becomes unresponsive. Regards, Paulo 2012/5/22 Lluís Batlle i Rossell vi...@viric.name: Hello, I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5). As an additional note, pinchartl on irc #v4l says to favour a moving of gspca to vb2. I don't know what it means. Can someone take care of the bug, or should I consider the camera 'non working' in linux? Thank you, Lluís. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the gspca_ov519 driver
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non working'
in linux?
We talked about this on irc, attached it a patch which should fix this, feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goede hdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void *priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void *priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags = ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
Re: Problems with the gspca_ov519 driver
Is this over linux 3.4 mainline? Because I can't get the patch applied over it.
Regards,
Lluís.
On Tue, May 22, 2012 at 04:39:17PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and
after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF
also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of
gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non
working'
in linux?
We talked about this on irc, attached it a patch which should fix this,
feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goede hdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void
*priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void
*priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags = ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the gspca_ov519 driver
Hi,
On 05/22/2012 05:27 PM, Lluís Batlle i Rossell wrote:
Is this over linux 3.4 mainline? Because I can't get the patch applied over it.
No it is against:
http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.5
But it should be trivial to backport, the patch is only 3 lines.
Regards,
Hans
Regards,
Lluís.
On Tue, May 22, 2012 at 04:39:17PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non working'
in linux?
We talked about this on irc, attached it a patch which should fix this, feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goedehdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goedehdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void *priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void *priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags= ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the gspca_ov519 driver
On Tue, May 22, 2012 at 06:28:18PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 05:27 PM, Lluís Batlle i Rossell wrote:
Is this over linux 3.4 mainline? Because I can't get the patch applied over
it.
No it is against:
http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.5
But it should be trivial to backport, the patch is only 3 lines.
I tried to, but I couldn't find any match for
video_drvdata. I'll check again.
Thank you.
Regards,
Lluís.
On Tue, May 22, 2012 at 04:39:17PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and
after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF
also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of
gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non
working'
in linux?
We talked about this on irc, attached it a patch which should fix this,
feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goedehdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goedehdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void
*priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void
*priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags= ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the gspca_ov519 driver
On Tue, May 22, 2012 at 06:28:18PM +0200, Hans de Goede wrote:
On 05/22/2012 05:27 PM, Lluís Batlle i Rossell wrote:
Is this over linux 3.4 mainline? Because I can't get the patch applied over
it.
No it is against:
http://git.linuxtv.org/media_tree.git/shortlog/refs/heads/staging/for_v3.5
But it should be trivial to backport, the patch is only 3 lines.
Hello,
I ported your patch to 3.4, and it works for me. I can stream off and on as I
can with other cameras.
Thank you,
Lluís.
On Tue, May 22, 2012 at 04:39:17PM +0200, Hans de Goede wrote:
Hi,
On 05/22/2012 04:08 PM, Paulo Assis wrote:
Hi,
This bug also causes the camera to crash when changing fps in
guvcview, uvc devices (at least all the ones I tested) require the
stream to be restarted for fps to change, so in the case of this
driver after STREAMOFF the camera just becomes unresponsive.
Regards,
Paulo
2012/5/22 Lluís Batlle i Rossellvi...@viric.name:
Hello,
I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and
after
STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF
also
fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after
STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5).
As an additional note, pinchartl on irc #v4l says to favour a moving of
gspca to
vb2. I don't know what it means.
Can someone take care of the bug, or should I consider the camera 'non
working'
in linux?
We talked about this on irc, attached it a patch which should fix this,
feedback
appreciated.
Regards,
Hans
From b0eefa00c72e9dfe9eaa5f425c0d346b19ea01cd Mon Sep 17 00:00:00 2001
From: Hans de Goedehdego...@redhat.com
Date: Tue, 22 May 2012 16:24:05 +0200
Subject: [PATCH] gspca-core: Fix buffers staying in queued state after a
stream_off
Signed-off-by: Hans de Goedehdego...@redhat.com
---
drivers/media/video/gspca/gspca.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 137166d..31721ea 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -1653,7 +1653,7 @@ static int vidioc_streamoff(struct file *file, void
*priv,
enum v4l2_buf_type buf_type)
{
struct gspca_dev *gspca_dev = video_drvdata(file);
- int ret;
+ int i, ret;
if (buf_type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -1678,6 +1678,8 @@ static int vidioc_streamoff(struct file *file, void
*priv,
wake_up_interruptible(gspca_dev-wq);
/* empty the transfer queues */
+ for (i = 0; i gspca_dev-nframes; i++)
+ gspca_dev-frame[i].v4l2_buf.flags= ~BUF_ALL_FLAGS;
atomic_set(gspca_dev-fr_q, 0);
atomic_set(gspca_dev-fr_i, 0);
gspca_dev-fr_o = 0;
--
1.7.10
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with the gspca_ov519 driver
On Tue, 22 May 2012 16:39:17 +0200 Hans de Goede hdego...@redhat.com wrote: On 05/22/2012 04:08 PM, Paulo Assis wrote: Hi, This bug also causes the camera to crash when changing fps in guvcview, uvc devices (at least all the ones I tested) require the stream to be restarted for fps to change, so in the case of this driver after STREAMOFF the camera just becomes unresponsive. [...] 2012/5/22 Lluís Batlle i Rossellvi...@viric.name: Hello, I'm trying to get video using v4l2 ioctls from a gspca_ov519 camera, and after STREAMOFF all buffers are still flagged as QUEUED, and QBUF fails. DQBUF also fails (blocking for a 3 sec timeout), after streamoff. So I'm stuck, after STREAMOFF, unable to get pictures coming in again. (Linux 3.3.5). [...] We talked about this on irc, attached it a patch which should fix this, feedback appreciated. Thanks HdG. Paulo, this seems to fix the problem I too was having when changing the framerate on ov534 with guvcview. IIRC, from a previous investigation, I've been experiencing this since commit f7059ea, which in fact removes the lines HdG added back, but I didn't put too much effort in investigating the exact cause, sorry. For the record the guvcview error messages were: VIDIOC_QBUF - Unable to queue buffer: Invalid argument Could not grab image (select timeout): Resource temporarily unavailable I feel I can add a: Tested-by: Antonio Ospite osp...@studenti.unina.it I can backport the change to older kernels and even CC linux-stable if you think it is appropriate, that's the least I can do to expiate for knowing about a bug/regression and not hunting its cause hard enough. HdG maybe you could mention f7059ea in the commit message of this fix if you can confirm the problem was introduced there. Regards, Antonio -- Antonio Ospite http://ao2.it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
