Possible problem with stk1160 driver

Possible problem with stk1160 driver

[Sergey 'Jin' Bostandzhyan]

Hi,

I am not quite sure if the problem is in the driver or if the user space
applications are doing something in a weird or wrong way, I hope you can
help me.

I have one of those easycap 4x-input devices with a Syntek chip:
Bus 001 Device 002: ID 05e1:0408 Syntek Semiconductor Co., Ltd STK1160 Video Capture Device

I'm on 3.9.9-201.fc18.i686.PAE kernel, using the stk1160 driver.

It generally works fine, I can, for example, open the video device using VLC,
select one of the inputs and get the picture.

However, programs like motion or zoneminder fail, I am not quite sure if it
is something that they might be doing or if it is a problem in the driver.

Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails
with EBUSY.

I do not see any errors in the message log, only:
Jul 16 21:27:24 localhost kernel: [ 9477.574448] stk1160: queue_setup: buffer
+count 8, each 829440 bytes
Jul 16 21:27:24 localhost kernel: [ 9477.595667] stk1160: setting alternate 5

I somewhat assume that it works with VLC because when switching the input you
more or less "open a new device", while zoneminder/motion might try to
change the input while actually streaming.

I'd appreciate any help or hint, also in case if you think that it's not the
driver issue, maybe you have an idea what I should be looking for (i.e.
what other operations might cause the VIDIOC_S_INPUT ioctl to fail?).

Kind regards,
Sergey

Re: Possible problem with stk1160 driver

[Ezequiel Garcia]

Hi Sergei,

On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote:
> 
> I am not quite sure if the problem is in the driver or if the user space
> applications are doing something in a weird or wrong way, I hope you can
> help me.
> 
> I have one of those easycap 4x-input devices with a Syntek chip:
> Bus 001 Device 002: ID 05e1:0408 Syntek Semiconductor Co., Ltd STK1160 Video Capture Device
> 
> I'm on 3.9.9-201.fc18.i686.PAE kernel, using the stk1160 driver.
> 
> It generally works fine, I can, for example, open the video device using VLC,
> select one of the inputs and get the picture.
> 
> However, programs like motion or zoneminder fail, I am not quite sure if it
> is something that they might be doing or if it is a problem in the driver.
> 
> Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails
> with EBUSY.
> 
> I do not see any errors in the message log, only:
> Jul 16 21:27:24 localhost kernel: [ 9477.574448] stk1160: queue_setup: buffer
> +count 8, each 829440 bytes
> Jul 16 21:27:24 localhost kernel: [ 9477.595667] stk1160: setting alternate 5
> 
> I somewhat assume that it works with VLC because when switching the input you
> more or less "open a new device", while zoneminder/motion might try to
> change the input while actually streaming.
> 
> I'd appreciate any help or hint, also in case if you think that it's not the
> driver issue, maybe you have an idea what I should be looking for (i.e.
> what other operations might cause the VIDIOC_S_INPUT ioctl to fail?).
> 

Let me try those applications and see what I find. From what you
describe I believe your suspicious might be accurate, but let me check
first.

Thanks,
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: Possible problem with stk1160 driver

[Ezequiel Garcia]

Hi Sergey,

On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote:
> 
> It generally works fine, I can, for example, open the video device using VLC,
> select one of the inputs and get the picture.
> 
> However, programs like motion or zoneminder fail, I am not quite sure if it
> is something that they might be doing or if it is a problem in the driver.
> 
> Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails
> with EBUSY.
> 

I've just sent a patch to fix this issue.

Could you try it and let me know if it solves your issue?

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: Possible problem with stk1160 driver

[Sergey 'Jin' Bostandzhyan]

Hi Ezequiel,

On Wed, Jul 17, 2013 at 05:44:29AM -0300, Ezequiel Garcia wrote:
> On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote:
> > 
> > It generally works fine, I can, for example, open the video device using VLC,
> > select one of the inputs and get the picture.
> > 
> > However, programs like motion or zoneminder fail, I am not quite sure if it
> > is something that they might be doing or if it is a problem in the driver.
> > 
> > Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails
> > with EBUSY.
> > 
> 
> I've just sent a patch to fix this issue.
> 
> Could you try it and let me know if it solves your issue?

thanks a lot! Just tried it, same fix is needed for vidioc_s_std(), then
the errors in motion and zoneminder are gone!

Motion seems to work now, with zoneminder I get a lot of these messages:
Jul 17 23:28:27 localhost kernel: [20641.931990] stk1160_copy_video: 5563 callbacks suppressed
Jul 17 23:28:27 localhost kernel: [20641.931998] stk1160: buffer overflow detected
Jul 17 23:28:27 localhost kernel: [20641.932000] stk1160: buffer overflow detected

Anything to worry about?

The image is also garbled in zoneminder, but since it works fine in motion I
would assume that this is not a driver problem anymore, probably some bug in
the zoneminder application.

Thanks a lot for the quick fix!

Kind regards,
Sergey

Re: Possible problem with stk1160 driver

[Ezequiel Garcia]

Hi Sergey,

On Wed, Jul 17, 2013 at 11:31:39PM +0200, Sergey 'Jin' Bostandzhyan wrote:
> On Wed, Jul 17, 2013 at 05:44:29AM -0300, Ezequiel Garcia wrote:
> > On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote:
> > > 
> > > It generally works fine, I can, for example, open the video device using VLC,
> > > select one of the inputs and get the picture.
> > > 
> > > However, programs like motion or zoneminder fail, I am not quite sure if it
> > > is something that they might be doing or if it is a problem in the driver.
> > > 
> > > Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails
> > > with EBUSY.
> > > 
> > 
> > I've just sent a patch to fix this issue.
> > 
> > Could you try it and let me know if it solves your issue?
> 
> thanks a lot! Just tried it, same fix is needed for vidioc_s_std(), then
> the errors in motion and zoneminder are gone!
> 

Ah... forgot to mention about that. I haven't included the fix for standard
setting, because either the stk1160 chip or the userspace application didn't
seem to behave properly: I got wrongly coloured frames when trying to
change the standard while streaming.

Can't your problem get fixed by setting an initial standard (e.g. at
/etc/motion configuration file)?

> Motion seems to work now, with zoneminder I get a lot of these messages:
> Jul 17 23:28:27 localhost kernel: [20641.931990] stk1160_copy_video: 5563 callbacks suppressed
> Jul 17 23:28:27 localhost kernel: [20641.931998] stk1160: buffer overflow detected
> Jul 17 23:28:27 localhost kernel: [20641.932000] stk1160: buffer overflow detected
> 
> Anything to worry about?
> 

Not sure. If you're changing the standard while streaming then maybe some component
is not doing things right.

I can take a look at the std thing later, but for now the input
fix looks definitely correct.

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: Possible problem with stk1160 driver

[Sergey 'Jin' Bostandzhyan]

Hi Ezequiel,

On Wed, Jul 17, 2013 at 09:17:53PM -0300, Ezequiel Garcia wrote:
> On Wed, Jul 17, 2013 at 11:31:39PM +0200, Sergey 'Jin' Bostandzhyan wrote:
> > On Wed, Jul 17, 2013 at 05:44:29AM -0300, Ezequiel Garcia wrote:
> > > On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote:
> > > > 
> > > > It generally works fine, I can, for example, open the video device using VLC,
> > > > select one of the inputs and get the picture.
> > > > 
> > > > However, programs like motion or zoneminder fail, I am not quite sure if it
> > > > is something that they might be doing or if it is a problem in the driver.
> > > > 
> > > > Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails
> > > > with EBUSY.
> > > > 
> > > 
> > > I've just sent a patch to fix this issue.
> > > 
> > > Could you try it and let me know if it solves your issue?
> > 
> > thanks a lot! Just tried it, same fix is needed for vidioc_s_std(), then
> > the errors in motion and zoneminder are gone!
> > 
> 
> Ah... forgot to mention about that. I haven't included the fix for standard
> setting, because either the stk1160 chip or the userspace application didn't
> seem to behave properly: I got wrongly coloured frames when trying to
> change the standard while streaming.
> 
> Can't your problem get fixed by setting an initial standard (e.g. at
> /etc/motion configuration file)?

Actually it is set, so I do not really know why it attempts to set it
separately for each input. So basically that means, that the version I am
running now may cause some problems (I removed the busy check on vidioc_s_std
in my local module)... it does work however, maybe because it's just
setting the same standard over and over again which probably does not
cause any actual action on the chip?

> > Motion seems to work now, with zoneminder I get a lot of these messages:
> > Jul 17 23:28:27 localhost kernel: [20641.931990] stk1160_copy_video: 5563 callbacks suppressed
> > Jul 17 23:28:27 localhost kernel: [20641.931998] stk1160: buffer overflow detected
> > Jul 17 23:28:27 localhost kernel: [20641.932000] stk1160: buffer overflow detected
> > 
> > Anything to worry about?
> > 
> 
> Not sure. If you're changing the standard while streaming then maybe some component
> is not doing things right.

I only get these messages with zoneminder, with motion things seem to
work fine. One problem with zoneminder is, that it does not cycle the
inputs in a clean way, i.e. if I watch each "virtual" camera separately,
I see the image and then I do see some garbage that comes from the input
switching. But again, since motion handles it just fine, I would assume that
this is some zoneminder problem.. however I do not know if they are doing
anything legal or illegal in their code. I did configure the same standard 
for each input there too, so that part should not be different from
what motion is doing.

> I can take a look at the std thing later, but for now the input
> fix looks definitely correct.

Yes, thank you, this input fix solved the initial problem :)

Just ping me if you'd like me to test the std fix later, whenever you get to it.

Kind regards,
Sergey

Re: Possible problem with stk1160 driver

[Hans Verkuil]

On 07/18/2013 02:17 AM, Ezequiel Garcia wrote:
> Hi Sergey,
> 
> On Wed, Jul 17, 2013 at 11:31:39PM +0200, Sergey 'Jin' Bostandzhyan wrote:
>> On Wed, Jul 17, 2013 at 05:44:29AM -0300, Ezequiel Garcia wrote:
>>> On Wed, Jul 17, 2013 at 12:04:18AM +0200, Sergey 'Jin' Bostandzhyan wrote:
>>>>
>>>> It generally works fine, I can, for example, open the video device using VLC,
>>>> select one of the inputs and get the picture.
>>>>
>>>> However, programs like motion or zoneminder fail, I am not quite sure if it
>>>> is something that they might be doing or if it is a problem in the driver.
>>>>
>>>> Basically, for both of the above, the problem is that VIDIOC_S_INPUT fails
>>>> with EBUSY.
>>>>
>>>
>>> I've just sent a patch to fix this issue.
>>>
>>> Could you try it and let me know if it solves your issue?
>>
>> thanks a lot! Just tried it, same fix is needed for vidioc_s_std(), then
>> the errors in motion and zoneminder are gone!
>>
> 
> Ah... forgot to mention about that. I haven't included the fix for standard
> setting, because either the stk1160 chip or the userspace application didn't
> seem to behave properly: I got wrongly coloured frames when trying to
> change the standard while streaming.

You generally can't switch standards while streaming. That said, it is OK
to accept the same standard, i.e. return 0 if the standard is unchanged and
EBUSY otherwise.

In the end it is an application bug, though. It shouldn't try to change the
standard while streaming has started.

Regards,

	Hans

> Can't your problem get fixed by setting an initial standard (e.g. at
> /etc/motion configuration file)?
> 
>> Motion seems to work now, with zoneminder I get a lot of these messages:
>> Jul 17 23:28:27 localhost kernel: [20641.931990] stk1160_copy_video: 5563 callbacks suppressed
>> Jul 17 23:28:27 localhost kernel: [20641.931998] stk1160: buffer overflow detected
>> Jul 17 23:28:27 localhost kernel: [20641.932000] stk1160: buffer overflow detected
>>
>> Anything to worry about?
>>
> 
> Not sure. If you're changing the standard while streaming then maybe some component
> is not doing things right.
> 
> I can take a look at the std thing later, but for now the input
> fix looks definitely correct.
> 

Re: Possible problem with stk1160 driver

[Ezequiel Garcia]

Hi Hans,

Thanks for jumping in.

On Thu, Jul 18, 2013 at 08:31:13AM +0200, Hans Verkuil wrote:
> On 07/18/2013 02:17 AM, Ezequiel Garcia wrote:
> > 
> > Ah... forgot to mention about that. I haven't included the fix for standard
> > setting, because either the stk1160 chip or the userspace application didn't
> > seem to behave properly: I got wrongly coloured frames when trying to
> > change the standard while streaming.
> 
> You generally can't switch standards while streaming. That said, it is OK
> to accept the same standard, i.e. return 0 if the standard is unchanged and
> EBUSY otherwise.
> 

Ok, I'll add a check for unchanged standards to overcome this situation.

> In the end it is an application bug, though. It shouldn't try to change the
> standard while streaming has started.
> 

Ok, so that confirms we should not allow it.

Sergey: Hopefully, with these two patches you won't need any further
patching on your side.

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

Re: Possible problem with stk1160 driver

[Sergey 'Jin' Bostandzhyan]

Hi Ezequiel,

On Thu, Jul 18, 2013 at 09:55:59AM -0300, Ezequiel Garcia wrote:
> > You generally can't switch standards while streaming. That said, it is OK
> > to accept the same standard, i.e. return 0 if the standard is unchanged and
> > EBUSY otherwise.
> > 
> 
> Ok, I'll add a check for unchanged standards to overcome this situation.
> 
> > In the end it is an application bug, though. It shouldn't try to change the
> > standard while streaming has started.
> > 
> 
> Ok, so that confirms we should not allow it.
> 
> Sergey: Hopefully, with these two patches you won't need any further
> patching on your side.

thanks a lot! Seems to work fine.

Kind regards,
Sergey