* [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
@ 2014-11-05 20:11 Andrey Utkin
2014-11-14 11:10 ` Hans Verkuil
2014-12-12 13:30 ` Hans Verkuil
0 siblings, 2 replies; 8+ messages in thread
From: Andrey Utkin @ 2014-11-05 20:11 UTC (permalink / raw)
To: linux-kernel, linux-media; +Cc: m.chehab, hans.verkuil, Andrey Utkin
Dropping code (introduced in 316d9e84a72069e04e483de0d5934c1d75f6a44c)
which intends to make raising of motion events more "smooth"(?).
It made motion event never appear in my installation.
That code is complicated, so I couldn't figure out quickly how to fix
it, so dropping it seems better to me.
Another justification is that anyway application would implement
"motion signal stabilization" if required, it is not necessarily kernel
driver's job.
Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
---
drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 30 +-------------------------
drivers/media/pci/solo6x10/solo6x10.h | 2 --
2 files changed, 1 insertion(+), 31 deletions(-)
diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
index 30e09d9..866f7b3 100644
--- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
@@ -239,8 +239,6 @@ static int solo_enc_on(struct solo_enc_dev *solo_enc)
if (solo_enc->bw_weight > solo_dev->enc_bw_remain)
return -EBUSY;
solo_enc->sequence = 0;
- solo_enc->motion_last_state = false;
- solo_enc->frames_since_last_motion = 0;
solo_dev->enc_bw_remain -= solo_enc->bw_weight;
if (solo_enc->type == SOLO_ENC_TYPE_EXT)
@@ -555,36 +553,12 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
}
if (!ret) {
- bool send_event = false;
-
vb->v4l2_buf.sequence = solo_enc->sequence++;
vb->v4l2_buf.timestamp.tv_sec = vop_sec(vh);
vb->v4l2_buf.timestamp.tv_usec = vop_usec(vh);
/* Check for motion flags */
- if (solo_is_motion_on(solo_enc)) {
- /* It takes a few frames for the hardware to detect
- * motion. Once it does it clears the motion detection
- * register and it takes again a few frames before
- * motion is seen. This means in practice that when the
- * motion field is 1, it will go back to 0 for the next
- * frame. This leads to motion detection event being
- * sent all the time, which is not what we want.
- * Instead wait a few frames before deciding that the
- * motion has halted. After some experimentation it
- * turns out that waiting for 5 frames works well.
- */
- if (enc_buf->motion == 0 &&
- solo_enc->motion_last_state &&
- solo_enc->frames_since_last_motion++ > 5)
- send_event = true;
- else if (enc_buf->motion) {
- solo_enc->frames_since_last_motion = 0;
- send_event = !solo_enc->motion_last_state;
- }
- }
-
- if (send_event) {
+ if (solo_is_motion_on(solo_enc) && enc_buf->motion) {
struct v4l2_event ev = {
.type = V4L2_EVENT_MOTION_DET,
.u.motion_det = {
@@ -594,8 +568,6 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
},
};
- solo_enc->motion_last_state = enc_buf->motion;
- solo_enc->frames_since_last_motion = 0;
v4l2_event_queue(solo_enc->vfd, &ev);
}
}
diff --git a/drivers/media/pci/solo6x10/solo6x10.h b/drivers/media/pci/solo6x10/solo6x10.h
index 72017b7..dc503fd 100644
--- a/drivers/media/pci/solo6x10/solo6x10.h
+++ b/drivers/media/pci/solo6x10/solo6x10.h
@@ -159,8 +159,6 @@ struct solo_enc_dev {
u16 motion_thresh;
bool motion_global;
bool motion_enabled;
- bool motion_last_state;
- u8 frames_since_last_motion;
u16 width;
u16 height;
--
1.8.5.5
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
2014-11-05 20:11 [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable Andrey Utkin
@ 2014-11-14 11:10 ` Hans Verkuil
2014-12-11 16:08 ` Andrey Utkin
2014-12-12 13:30 ` Hans Verkuil
1 sibling, 1 reply; 8+ messages in thread
From: Hans Verkuil @ 2014-11-14 11:10 UTC (permalink / raw)
To: Andrey Utkin, linux-kernel, linux-media; +Cc: m.chehab, hans.verkuil
Hi Andrew,
FYI: I need to test this myself and understand it better, so it will take some
time before I get to this. It is in my TODO list, so it won't be forgotten.
Regards,
Hans
On 11/05/2014 09:11 PM, Andrey Utkin wrote:
> Dropping code (introduced in 316d9e84a72069e04e483de0d5934c1d75f6a44c)
> which intends to make raising of motion events more "smooth"(?).
>
> It made motion event never appear in my installation.
> That code is complicated, so I couldn't figure out quickly how to fix
> it, so dropping it seems better to me.
>
> Another justification is that anyway application would implement
> "motion signal stabilization" if required, it is not necessarily kernel
> driver's job.
>
> Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
> ---
> drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 30 +-------------------------
> drivers/media/pci/solo6x10/solo6x10.h | 2 --
> 2 files changed, 1 insertion(+), 31 deletions(-)
>
> diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> index 30e09d9..866f7b3 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> @@ -239,8 +239,6 @@ static int solo_enc_on(struct solo_enc_dev *solo_enc)
> if (solo_enc->bw_weight > solo_dev->enc_bw_remain)
> return -EBUSY;
> solo_enc->sequence = 0;
> - solo_enc->motion_last_state = false;
> - solo_enc->frames_since_last_motion = 0;
> solo_dev->enc_bw_remain -= solo_enc->bw_weight;
>
> if (solo_enc->type == SOLO_ENC_TYPE_EXT)
> @@ -555,36 +553,12 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
> }
>
> if (!ret) {
> - bool send_event = false;
> -
> vb->v4l2_buf.sequence = solo_enc->sequence++;
> vb->v4l2_buf.timestamp.tv_sec = vop_sec(vh);
> vb->v4l2_buf.timestamp.tv_usec = vop_usec(vh);
>
> /* Check for motion flags */
> - if (solo_is_motion_on(solo_enc)) {
> - /* It takes a few frames for the hardware to detect
> - * motion. Once it does it clears the motion detection
> - * register and it takes again a few frames before
> - * motion is seen. This means in practice that when the
> - * motion field is 1, it will go back to 0 for the next
> - * frame. This leads to motion detection event being
> - * sent all the time, which is not what we want.
> - * Instead wait a few frames before deciding that the
> - * motion has halted. After some experimentation it
> - * turns out that waiting for 5 frames works well.
> - */
> - if (enc_buf->motion == 0 &&
> - solo_enc->motion_last_state &&
> - solo_enc->frames_since_last_motion++ > 5)
> - send_event = true;
> - else if (enc_buf->motion) {
> - solo_enc->frames_since_last_motion = 0;
> - send_event = !solo_enc->motion_last_state;
> - }
> - }
> -
> - if (send_event) {
> + if (solo_is_motion_on(solo_enc) && enc_buf->motion) {
> struct v4l2_event ev = {
> .type = V4L2_EVENT_MOTION_DET,
> .u.motion_det = {
> @@ -594,8 +568,6 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
> },
> };
>
> - solo_enc->motion_last_state = enc_buf->motion;
> - solo_enc->frames_since_last_motion = 0;
> v4l2_event_queue(solo_enc->vfd, &ev);
> }
> }
> diff --git a/drivers/media/pci/solo6x10/solo6x10.h b/drivers/media/pci/solo6x10/solo6x10.h
> index 72017b7..dc503fd 100644
> --- a/drivers/media/pci/solo6x10/solo6x10.h
> +++ b/drivers/media/pci/solo6x10/solo6x10.h
> @@ -159,8 +159,6 @@ struct solo_enc_dev {
> u16 motion_thresh;
> bool motion_global;
> bool motion_enabled;
> - bool motion_last_state;
> - u8 frames_since_last_motion;
> u16 width;
> u16 height;
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
2014-11-14 11:10 ` Hans Verkuil
@ 2014-12-11 16:08 ` Andrey Utkin
2014-12-11 16:42 ` Hans Verkuil
0 siblings, 1 reply; 8+ messages in thread
From: Andrey Utkin @ 2014-12-11 16:08 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-kernel, Linux Media, m.chehab, hans.verkuil
On Fri, Nov 14, 2014 at 1:10 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Hi Andrew,
>
> FYI: I need to test this myself and understand it better, so it will take some
> time before I get to this. It is in my TODO list, so it won't be forgotten.
>
> Regards,
>
> Hans
>
> On 11/05/2014 09:11 PM, Andrey Utkin wrote:
>> Dropping code (introduced in 316d9e84a72069e04e483de0d5934c1d75f6a44c)
>> which intends to make raising of motion events more "smooth"(?).
>>
>> It made motion event never appear in my installation.
>> That code is complicated, so I couldn't figure out quickly how to fix
>> it, so dropping it seems better to me.
>>
>> Another justification is that anyway application would implement
>> "motion signal stabilization" if required, it is not necessarily kernel
>> driver's job.
>>
>> Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
>> ---
>> drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 30 +-------------------------
>> drivers/media/pci/solo6x10/solo6x10.h | 2 --
>> 2 files changed, 1 insertion(+), 31 deletions(-)
>>
>> diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
>> index 30e09d9..866f7b3 100644
>> --- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
>> +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
>> @@ -239,8 +239,6 @@ static int solo_enc_on(struct solo_enc_dev *solo_enc)
>> if (solo_enc->bw_weight > solo_dev->enc_bw_remain)
>> return -EBUSY;
>> solo_enc->sequence = 0;
>> - solo_enc->motion_last_state = false;
>> - solo_enc->frames_since_last_motion = 0;
>> solo_dev->enc_bw_remain -= solo_enc->bw_weight;
>>
>> if (solo_enc->type == SOLO_ENC_TYPE_EXT)
>> @@ -555,36 +553,12 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
>> }
>>
>> if (!ret) {
>> - bool send_event = false;
>> -
>> vb->v4l2_buf.sequence = solo_enc->sequence++;
>> vb->v4l2_buf.timestamp.tv_sec = vop_sec(vh);
>> vb->v4l2_buf.timestamp.tv_usec = vop_usec(vh);
>>
>> /* Check for motion flags */
>> - if (solo_is_motion_on(solo_enc)) {
>> - /* It takes a few frames for the hardware to detect
>> - * motion. Once it does it clears the motion detection
>> - * register and it takes again a few frames before
>> - * motion is seen. This means in practice that when the
>> - * motion field is 1, it will go back to 0 for the next
>> - * frame. This leads to motion detection event being
>> - * sent all the time, which is not what we want.
>> - * Instead wait a few frames before deciding that the
>> - * motion has halted. After some experimentation it
>> - * turns out that waiting for 5 frames works well.
>> - */
>> - if (enc_buf->motion == 0 &&
>> - solo_enc->motion_last_state &&
>> - solo_enc->frames_since_last_motion++ > 5)
>> - send_event = true;
>> - else if (enc_buf->motion) {
>> - solo_enc->frames_since_last_motion = 0;
>> - send_event = !solo_enc->motion_last_state;
>> - }
>> - }
>> -
>> - if (send_event) {
>> + if (solo_is_motion_on(solo_enc) && enc_buf->motion) {
>> struct v4l2_event ev = {
>> .type = V4L2_EVENT_MOTION_DET,
>> .u.motion_det = {
>> @@ -594,8 +568,6 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
>> },
>> };
>>
>> - solo_enc->motion_last_state = enc_buf->motion;
>> - solo_enc->frames_since_last_motion = 0;
>> v4l2_event_queue(solo_enc->vfd, &ev);
>> }
>> }
>> diff --git a/drivers/media/pci/solo6x10/solo6x10.h b/drivers/media/pci/solo6x10/solo6x10.h
>> index 72017b7..dc503fd 100644
>> --- a/drivers/media/pci/solo6x10/solo6x10.h
>> +++ b/drivers/media/pci/solo6x10/solo6x10.h
>> @@ -159,8 +159,6 @@ struct solo_enc_dev {
>> u16 motion_thresh;
>> bool motion_global;
>> bool motion_enabled;
>> - bool motion_last_state;
>> - u8 frames_since_last_motion;
>> u16 width;
>> u16 height;
>>
>>
>
Hi Hans, how is it proceeding with the subject of this patch?
--
Bluecherry developer.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
2014-12-11 16:08 ` Andrey Utkin
@ 2014-12-11 16:42 ` Hans Verkuil
0 siblings, 0 replies; 8+ messages in thread
From: Hans Verkuil @ 2014-12-11 16:42 UTC (permalink / raw)
To: Andrey Utkin; +Cc: linux-kernel, Linux Media, m.chehab, hans.verkuil
On 12/11/2014 05:08 PM, Andrey Utkin wrote:
> On Fri, Nov 14, 2014 at 1:10 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> Hi Andrew,
>>
>> FYI: I need to test this myself and understand it better, so it will take some
>> time before I get to this. It is in my TODO list, so it won't be forgotten.
>>
>> Regards,
>>
>> Hans
>>
>> On 11/05/2014 09:11 PM, Andrey Utkin wrote:
>>> Dropping code (introduced in 316d9e84a72069e04e483de0d5934c1d75f6a44c)
>>> which intends to make raising of motion events more "smooth"(?).
>>>
>>> It made motion event never appear in my installation.
>>> That code is complicated, so I couldn't figure out quickly how to fix
>>> it, so dropping it seems better to me.
>>>
>>> Another justification is that anyway application would implement
>>> "motion signal stabilization" if required, it is not necessarily kernel
>>> driver's job.
>>>
>>> Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
>>> ---
>>> drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 30 +-------------------------
>>> drivers/media/pci/solo6x10/solo6x10.h | 2 --
>>> 2 files changed, 1 insertion(+), 31 deletions(-)
>>>
<snip>
>>
>
> Hi Hans, how is it proceeding with the subject of this patch?
Still haven't had the time to check this, other than a very quick test run.
Don't worry, it's in my TODO list, so I can't forget, but it has been busier
than usual lately. And this is one patch I really like to test before
committing.
Fingers crossed that I might be able to do it either tomorrow or on Monday.
If that fails, then the next opportunity will be after Christmas as I won't
have access to the hardware for awhile.
Regards,
Hans
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
2014-11-05 20:11 [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable Andrey Utkin
2014-11-14 11:10 ` Hans Verkuil
@ 2014-12-12 13:30 ` Hans Verkuil
2014-12-12 13:53 ` Andrey Utkin
1 sibling, 1 reply; 8+ messages in thread
From: Hans Verkuil @ 2014-12-12 13:30 UTC (permalink / raw)
To: Andrey Utkin, linux-kernel, linux-media; +Cc: m.chehab, hans.verkuil
On 11/05/2014 09:11 PM, Andrey Utkin wrote:
> Dropping code (introduced in 316d9e84a72069e04e483de0d5934c1d75f6a44c)
> which intends to make raising of motion events more "smooth"(?).
>
> It made motion event never appear in my installation.
> That code is complicated, so I couldn't figure out quickly how to fix
> it, so dropping it seems better to me.
>
> Another justification is that anyway application would implement
> "motion signal stabilization" if required, it is not necessarily kernel
> driver's job.
>
> Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
I have tested this and it looks good. I am not sure what problems I had
originally that caused me to write that code, since it is now functioning
as expected.
So you can expect this patch to be part of the next 3.20 pull request I'll
post.
Sorry for the delay.
Regards,
Hans
> ---
> drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 30 +-------------------------
> drivers/media/pci/solo6x10/solo6x10.h | 2 --
> 2 files changed, 1 insertion(+), 31 deletions(-)
>
> diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> index 30e09d9..866f7b3 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> @@ -239,8 +239,6 @@ static int solo_enc_on(struct solo_enc_dev *solo_enc)
> if (solo_enc->bw_weight > solo_dev->enc_bw_remain)
> return -EBUSY;
> solo_enc->sequence = 0;
> - solo_enc->motion_last_state = false;
> - solo_enc->frames_since_last_motion = 0;
> solo_dev->enc_bw_remain -= solo_enc->bw_weight;
>
> if (solo_enc->type == SOLO_ENC_TYPE_EXT)
> @@ -555,36 +553,12 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
> }
>
> if (!ret) {
> - bool send_event = false;
> -
> vb->v4l2_buf.sequence = solo_enc->sequence++;
> vb->v4l2_buf.timestamp.tv_sec = vop_sec(vh);
> vb->v4l2_buf.timestamp.tv_usec = vop_usec(vh);
>
> /* Check for motion flags */
> - if (solo_is_motion_on(solo_enc)) {
> - /* It takes a few frames for the hardware to detect
> - * motion. Once it does it clears the motion detection
> - * register and it takes again a few frames before
> - * motion is seen. This means in practice that when the
> - * motion field is 1, it will go back to 0 for the next
> - * frame. This leads to motion detection event being
> - * sent all the time, which is not what we want.
> - * Instead wait a few frames before deciding that the
> - * motion has halted. After some experimentation it
> - * turns out that waiting for 5 frames works well.
> - */
> - if (enc_buf->motion == 0 &&
> - solo_enc->motion_last_state &&
> - solo_enc->frames_since_last_motion++ > 5)
> - send_event = true;
> - else if (enc_buf->motion) {
> - solo_enc->frames_since_last_motion = 0;
> - send_event = !solo_enc->motion_last_state;
> - }
> - }
> -
> - if (send_event) {
> + if (solo_is_motion_on(solo_enc) && enc_buf->motion) {
> struct v4l2_event ev = {
> .type = V4L2_EVENT_MOTION_DET,
> .u.motion_det = {
> @@ -594,8 +568,6 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
> },
> };
>
> - solo_enc->motion_last_state = enc_buf->motion;
> - solo_enc->frames_since_last_motion = 0;
> v4l2_event_queue(solo_enc->vfd, &ev);
> }
> }
> diff --git a/drivers/media/pci/solo6x10/solo6x10.h b/drivers/media/pci/solo6x10/solo6x10.h
> index 72017b7..dc503fd 100644
> --- a/drivers/media/pci/solo6x10/solo6x10.h
> +++ b/drivers/media/pci/solo6x10/solo6x10.h
> @@ -159,8 +159,6 @@ struct solo_enc_dev {
> u16 motion_thresh;
> bool motion_global;
> bool motion_enabled;
> - bool motion_last_state;
> - u8 frames_since_last_motion;
> u16 width;
> u16 height;
>
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
2014-12-12 13:30 ` Hans Verkuil
@ 2014-12-12 13:53 ` Andrey Utkin
2014-12-17 20:54 ` Andrey Utkin
0 siblings, 1 reply; 8+ messages in thread
From: Andrey Utkin @ 2014-12-12 13:53 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-kernel, Linux Media, m.chehab, hans.verkuil
On Fri, Dec 12, 2014 at 3:30 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
>
> I have tested this and it looks good. I am not sure what problems I had
> originally that caused me to write that code, since it is now functioning
> as expected.
>
> So you can expect this patch to be part of the next 3.20 pull request I'll
> post.
>
> Sorry for the delay.
Thanks.
--
Bluecherry developer.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
2014-12-12 13:53 ` Andrey Utkin
@ 2014-12-17 20:54 ` Andrey Utkin
2014-12-18 7:54 ` Hans Verkuil
0 siblings, 1 reply; 8+ messages in thread
From: Andrey Utkin @ 2014-12-17 20:54 UTC (permalink / raw)
To: Hans Verkuil; +Cc: linux-kernel, Linux Media, m.chehab, hans.verkuil
Hans, is this commit anywhere in any git repository at the moment?
--
Bluecherry developer.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
2014-12-17 20:54 ` Andrey Utkin
@ 2014-12-18 7:54 ` Hans Verkuil
0 siblings, 0 replies; 8+ messages in thread
From: Hans Verkuil @ 2014-12-18 7:54 UTC (permalink / raw)
To: Andrey Utkin; +Cc: linux-kernel, Linux Media, m.chehab, hans.verkuil
On 12/17/2014 09:54 PM, Andrey Utkin wrote:
> Hans, is this commit anywhere in any git repository at the moment?
>
The pull request will go out to Mauro tomorrow.
Regards,
Hans
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-12-18 7:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-05 20:11 [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable Andrey Utkin
2014-11-14 11:10 ` Hans Verkuil
2014-12-11 16:08 ` Andrey Utkin
2014-12-11 16:42 ` Hans Verkuil
2014-12-12 13:30 ` Hans Verkuil
2014-12-12 13:53 ` Andrey Utkin
2014-12-17 20:54 ` Andrey Utkin
2014-12-18 7:54 ` Hans Verkuil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).