* Possible problem with stk1160 driver @ 2013-07-16 22:04 Sergey 'Jin' Bostandzhyan 2013-07-16 22:45 ` Ezequiel Garcia 2013-07-17 8:44 ` Ezequiel Garcia 0 siblings, 2 replies; 9+ messages in thread From: Sergey 'Jin' Bostandzhyan @ 2013-07-16 22:04 UTC (permalink / raw) To: linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible problem with stk1160 driver 2013-07-16 22:04 Possible problem with stk1160 driver Sergey 'Jin' Bostandzhyan @ 2013-07-16 22:45 ` Ezequiel Garcia 2013-07-17 8:44 ` Ezequiel Garcia 1 sibling, 0 replies; 9+ messages in thread From: Ezequiel Garcia @ 2013-07-16 22:45 UTC (permalink / raw) To: Sergey 'Jin' Bostandzhyan; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible problem with stk1160 driver 2013-07-16 22:04 Possible problem with stk1160 driver Sergey 'Jin' Bostandzhyan 2013-07-16 22:45 ` Ezequiel Garcia @ 2013-07-17 8:44 ` Ezequiel Garcia 2013-07-17 21:31 ` Sergey 'Jin' Bostandzhyan 1 sibling, 1 reply; 9+ messages in thread From: Ezequiel Garcia @ 2013-07-17 8:44 UTC (permalink / raw) To: Sergey 'Jin' Bostandzhyan; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible problem with stk1160 driver 2013-07-17 8:44 ` Ezequiel Garcia @ 2013-07-17 21:31 ` Sergey 'Jin' Bostandzhyan 2013-07-18 0:17 ` Ezequiel Garcia 0 siblings, 1 reply; 9+ messages in thread From: Sergey 'Jin' Bostandzhyan @ 2013-07-17 21:31 UTC (permalink / raw) To: Ezequiel Garcia; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible problem with stk1160 driver 2013-07-17 21:31 ` Sergey 'Jin' Bostandzhyan @ 2013-07-18 0:17 ` Ezequiel Garcia 2013-07-18 0:44 ` Sergey 'Jin' Bostandzhyan 2013-07-18 6:31 ` Hans Verkuil 0 siblings, 2 replies; 9+ messages in thread From: Ezequiel Garcia @ 2013-07-18 0:17 UTC (permalink / raw) To: Sergey 'Jin' Bostandzhyan; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible problem with stk1160 driver 2013-07-18 0:17 ` Ezequiel Garcia @ 2013-07-18 0:44 ` Sergey 'Jin' Bostandzhyan 2013-07-18 6:31 ` Hans Verkuil 1 sibling, 0 replies; 9+ messages in thread From: Sergey 'Jin' Bostandzhyan @ 2013-07-18 0:44 UTC (permalink / raw) To: Ezequiel Garcia; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible problem with stk1160 driver 2013-07-18 0:17 ` Ezequiel Garcia 2013-07-18 0:44 ` Sergey 'Jin' Bostandzhyan @ 2013-07-18 6:31 ` Hans Verkuil 2013-07-18 12:55 ` Ezequiel Garcia 1 sibling, 1 reply; 9+ messages in thread From: Hans Verkuil @ 2013-07-18 6:31 UTC (permalink / raw) To: Ezequiel Garcia; +Cc: Sergey 'Jin' Bostandzhyan, linux-media 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. > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible problem with stk1160 driver 2013-07-18 6:31 ` Hans Verkuil @ 2013-07-18 12:55 ` Ezequiel Garcia 2013-07-18 22:19 ` Sergey 'Jin' Bostandzhyan 0 siblings, 1 reply; 9+ messages in thread From: Ezequiel Garcia @ 2013-07-18 12:55 UTC (permalink / raw) To: Hans Verkuil; +Cc: Sergey 'Jin' Bostandzhyan, linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Possible problem with stk1160 driver 2013-07-18 12:55 ` Ezequiel Garcia @ 2013-07-18 22:19 ` Sergey 'Jin' Bostandzhyan 0 siblings, 0 replies; 9+ messages in thread From: Sergey 'Jin' Bostandzhyan @ 2013-07-18 22:19 UTC (permalink / raw) To: Ezequiel Garcia; +Cc: linux-media 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-07-18 22:19 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-07-16 22:04 Possible problem with stk1160 driver Sergey 'Jin' Bostandzhyan 2013-07-16 22:45 ` Ezequiel Garcia 2013-07-17 8:44 ` Ezequiel Garcia 2013-07-17 21:31 ` Sergey 'Jin' Bostandzhyan 2013-07-18 0:17 ` Ezequiel Garcia 2013-07-18 0:44 ` Sergey 'Jin' Bostandzhyan 2013-07-18 6:31 ` Hans Verkuil 2013-07-18 12:55 ` Ezequiel Garcia 2013-07-18 22:19 ` Sergey 'Jin' Bostandzhyan
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.