Power frequency detection.

Power frequency detection.

[Theodore Kilgore]

Does anyone know whether, somewhere in the kernel, there exists a scheme 
for detecting whether the external power supply of the computer is using 
50hz or 60hz?

The reason I ask:

A certain camera is marketed with Windows software which requests the user 
to set up the option of 50hz or 60hz power during the setup.

Judging by what exists in videodev2.h, for example, it is evidently 
possible to set up this as a control setting in a Linux driver. I am not 
aware of any streaming app which knows how to access such an option.

Information about which streaming app ought to be used which could take 
advantage of a setting for line frequency would be welcome, too, of 
course. As I said, I do not know of a single one and would therefore have 
trouble with testing any such control setting unless I could find the 
software which can actually present the choice to the user.

But my main question is whether the kernel already does detect the line 
frequency anywhere else, for whatever reason. For, it occurs to me that a 
far more elegant solution -- if the camera really does need to have the 
line frequency detected -- would be do do the job automatically and not to 
bother the user about such a thing.

In other news, in case anyone has any children who are in love with Lego, 
the "Lego Bionicle" camera which is currently on sale has an SQ905C type 
chip in it. I just added its Product number to the Gphoto driver last 
night. And it works perfectly in webcam mode if one adds its product 
number in gspca/sq905c.c. I will get around to doing that formally, of 
course, when I get time. But if anyone wants just to add the number and 
re-compile the Vendor:Product number for the new camera is 0x2770:0x9051.

Merry Christmas.

Theodore Kilgore

Re: Power frequency detection.

[Paulo Assis]

Hi,

2010/12/18 Theodore Kilgore <kilgota@banach.math.auburn.edu>:
>
> Does anyone know whether, somewhere in the kernel, there exists a scheme
> for detecting whether the external power supply of the computer is using
> 50hz or 60hz?
>
> The reason I ask:
>
> A certain camera is marketed with Windows software which requests the user
> to set up the option of 50hz or 60hz power during the setup.
>
> Judging by what exists in videodev2.h, for example, it is evidently
> possible to set up this as a control setting in a Linux driver. I am not
> aware of any streaming app which knows how to access such an option.
>

Most uvc cameras present this as a control, so any v4l2 control app
should let you access it.
If your camera driver also supports this control then this shouldn't
be a problem for any generci v4l2 app.
here are a couple of ones:

v4l2ucp (control panel)
guvcview ("guvcview --control_only" will work along side other apps
just like v4l2ucp)
uvcdynctrl from libwebcam for command line control utility .

Regards,
Paulo

> Information about which streaming app ought to be used which could take
> advantage of a setting for line frequency would be welcome, too, of
> course. As I said, I do not know of a single one and would therefore have
> trouble with testing any such control setting unless I could find the
> software which can actually present the choice to the user.
>
> But my main question is whether the kernel already does detect the line
> frequency anywhere else, for whatever reason. For, it occurs to me that a
> far more elegant solution -- if the camera really does need to have the
> line frequency detected -- would be do do the job automatically and not to
> bother the user about such a thing.
>
> In other news, in case anyone has any children who are in love with Lego,
> the "Lego Bionicle" camera which is currently on sale has an SQ905C type
> chip in it. I just added its Product number to the Gphoto driver last
> night. And it works perfectly in webcam mode if one adds its product
> number in gspca/sq905c.c. I will get around to doing that formally, of
> course, when I get time. But if anyone wants just to add the number and
> re-compile the Vendor:Product number for the new camera is 0x2770:0x9051.
>
> Merry Christmas.
>
> Theodore Kilgore
> --
> 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
>

Re: Power frequency detection.

[Andy Walls]

Theodore,

Aside from detect measurment of the power line, isn't a camera the best sort of sensor for this measurment anyway?

Just compute the average image luminosity over several frames and look for (10 Hz ?) periodic variation (beats), indicating a mismatch.

Sure you could just ask the user, but where's the challenge in that. ;)

Regards,
Andy

Theodore Kilgore <kilgota@banach.math.auburn.edu> wrote:

>
>
>On Sun, 19 Dec 2010, Paulo Assis wrote:
>
>> Hi,
>> 
>> 2010/12/18 Theodore Kilgore <kilgota@banach.math.auburn.edu>:
>> >
>> > Does anyone know whether, somewhere in the kernel, there exists a scheme
>> > for detecting whether the external power supply of the computer is using
>> > 50hz or 60hz?
>> >
>> > The reason I ask:
>> >
>> > A certain camera is marketed with Windows software which requests the user
>> > to set up the option of 50hz or 60hz power during the setup.
>> >
>> > Judging by what exists in videodev2.h, for example, it is evidently
>> > possible to set up this as a control setting in a Linux driver. I am not
>> > aware of any streaming app which knows how to access such an option.
>> >
>> 
>> Most uvc cameras present this as a control, so any v4l2 control app
>> should let you access it.
>> If your camera driver also supports this control then this shouldn't
>> be a problem for any generci v4l2 app.
>> here are a couple of ones:
>> 
>> v4l2ucp (control panel)
>> guvcview ("guvcview --control_only" will work along side other apps
>> just like v4l2ucp)
>> uvcdynctrl from libwebcam for command line control utility .
>> 
>> Regards,
>> Paulo
>
>Thank you. 
>
>I still think that it would be even more clever to detect the line 
>frequency automatically and then just to set the proper setting, if needed 
>or desirable. That was one of the parts of my question about it, after 
>all. But if nobody has ever had a reason to do such detection already it 
>would perhaps be much more trouble than it is worth just do support a 
>cheap camera.
>
>Theodore Kilgore
>--
>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

Re: Power frequency detection.

[Theodore Kilgore]

On Sun, 19 Dec 2010, Paulo Assis wrote:

> Hi,
> 
> 2010/12/18 Theodore Kilgore <kilgota@banach.math.auburn.edu>:
> >
> > Does anyone know whether, somewhere in the kernel, there exists a scheme
> > for detecting whether the external power supply of the computer is using
> > 50hz or 60hz?
> >
> > The reason I ask:
> >
> > A certain camera is marketed with Windows software which requests the user
> > to set up the option of 50hz or 60hz power during the setup.
> >
> > Judging by what exists in videodev2.h, for example, it is evidently
> > possible to set up this as a control setting in a Linux driver. I am not
> > aware of any streaming app which knows how to access such an option.
> >
> 
> Most uvc cameras present this as a control, so any v4l2 control app
> should let you access it.
> If your camera driver also supports this control then this shouldn't
> be a problem for any generci v4l2 app.
> here are a couple of ones:
> 
> v4l2ucp (control panel)
> guvcview ("guvcview --control_only" will work along side other apps
> just like v4l2ucp)
> uvcdynctrl from libwebcam for command line control utility .
> 
> Regards,
> Paulo

Thank you. 

I still think that it would be even more clever to detect the line 
frequency automatically and then just to set the proper setting, if needed 
or desirable. That was one of the parts of my question about it, after 
all. But if nobody has ever had a reason to do such detection already it 
would perhaps be much more trouble than it is worth just do support a 
cheap camera.

Theodore Kilgore

Re: Power frequency detection.

[Andy Walls]

On Sun, 2010-12-19 at 13:21 -0500, Andy Walls wrote:
> Theodore,

Gah.  I need to learn how to type or wear my glasses more often.

> Aside from detect measurment of the power line, isn't a camera the
             ^^^^^^^^^^^^^^^^^
             direct measurement

>  best sort of sensor for this measurment anyway?
                                ^^^^^^^^^^
                                measurement

> Just compute the average image luminosity over several frames and look
                                            ^^^
                                            for


Regards,
Andy

>  for (10 Hz ?) periodic variation (beats), indicating a mismatch.
>
> Sure you could just ask the user, but where's the challenge in
> that. ;)
> 
> Regards,
> Andy
> 
> Theodore Kilgore <kilgota@banach.math.auburn.edu> wrote:
> 
> >
> >
> >On Sun, 19 Dec 2010, Paulo Assis wrote:
> >
> >> Hi,
> >> 
> >> 2010/12/18 Theodore Kilgore <kilgota@banach.math.auburn.edu>:
> >> >
> >> > Does anyone know whether, somewhere in the kernel, there exists a scheme
> >> > for detecting whether the external power supply of the computer is using
> >> > 50hz or 60hz?
> >> >
> >> > The reason I ask:
> >> >
> >> > A certain camera is marketed with Windows software which requests the user
> >> > to set up the option of 50hz or 60hz power during the setup.
> >> >
> >> > Judging by what exists in videodev2.h, for example, it is evidently
> >> > possible to set up this as a control setting in a Linux driver. I am not
> >> > aware of any streaming app which knows how to access such an option.
> >> >
> >> 
> >> Most uvc cameras present this as a control, so any v4l2 control app
> >> should let you access it.
> >> If your camera driver also supports this control then this shouldn't
> >> be a problem for any generci v4l2 app.
> >> here are a couple of ones:
> >> 
> >> v4l2ucp (control panel)
> >> guvcview ("guvcview --control_only" will work along side other apps
> >> just like v4l2ucp)
> >> uvcdynctrl from libwebcam for command line control utility .
> >> 
> >> Regards,
> >> Paulo
> >
> >Thank you. 
> >
> >I still think that it would be even more clever to detect the line 
> >frequency automatically and then just to set the proper setting, if needed 
> >or desirable. That was one of the parts of my question about it, after 
> >all. But if nobody has ever had a reason to do such detection already it 
> >would perhaps be much more trouble than it is worth just do support a 
> >cheap camera.
> >
> >Theodore Kilgore
> >--
> >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
> NrybXǧv^)޺{.n+{bj)w*\x1fjg\x1eݢj/zޖ2ޙ&)ߡa\x7f\x1eGh\x0fj:+vw٥

Re: Power frequency detection.

[Theodore Kilgore]

On Sun, 19 Dec 2010, Andy Walls wrote:

> Theodore,
> 
> Aside from detect measurment of the power line, isn't a camera the best sort of sensor for this measurment anyway?
> 
> Just compute the average image luminosity over several frames and look for (10 Hz ?) periodic variation (beats), indicating a mismatch.
> 
> Sure you could just ask the user, but where's the challenge in that. ;)
> 
> Regards,
> Andy

Well, if it is "established policy" to go with doing this as a control, I 
guess we can just go ahead instead of doing something fancy.

But it is nice to hear from you. Here is why.

The camera in question is another jeilinj camera. Its OEM software for 
that other OS does present the option to choose line frequency. It also 
asks for the user to specify an image quality index. I can not recall that 
the software I got with my camera did any such thing. As I recall, it 
merely let the camera to start streaming. Bur at the moment I have no idea 
where I put that old CD.

So, while I have you on the line, do you recall whether or not the OEM 
software for the camera you bought for your daughter present any such 
setup options?


The new camera may be different in some particulars from the ones we have. 
It does have a new Product number, so apparently Jeilin might not have 
thought it is identical to the other ones. It does use a slightly 
different initialization sequence. Therefore, the quick-and-dirty way to 
support it would be just to introduce a patch which has switch statements 
or conditionals all over the place, and just to support whatever the 
camera was observed to do. However, that is obviously dirty as well as 
quick.

While playing around with the code a bit, I have managed to make my 
old camera work with essentially the same init sequence that the new 
one is using. If this can be done right, it would clear a lot of crud out 
of the driver code. Unfortunately, doing it right involves testing...

Finally, one concern that I have in the back of my mind is the question of 
control settings for a camera which streams in bulk mode and requires the 
setup of a workqueue. The owner of the camera says that he has 
"encountered no problems" with running the two controls mentioned above. 
Clearly, that is not a complete answer which overcomes all possible 
objections. Rather, things are OK if and only if we can ensure that these 
controls can be run only while the workqueue that does the streaming is 
inactive. Somehow, I suspect that the fact that a sensible user would only 
run such commands at camera setup is an insufficient guarantee that no 
problems will ever be encountered.

So, as I said, the question of interaction of a control and a workqueue is 
another problem interesting little problem. Your thoughts on this 
interesting little problem would be appreciated.

As I said, Merry Christmas :-)

Theodore Kilgore

Re: Power frequency detection.

[Theodore Kilgore]

On Sun, 19 Dec 2010, Andy Walls wrote:

> On Sun, 2010-12-19 at 13:21 -0500, Andy Walls wrote:
> > Theodore,
> 
> Gah.  I need to learn how to type or wear my glasses more often.
> 
> > Aside from detect measurment of the power line, isn't a camera the
>              ^^^^^^^^^^^^^^^^^
>              direct measurement
> 
> >  best sort of sensor for this measurment anyway?
>                                 ^^^^^^^^^^
>                                 measurement
> 
> > Just compute the average image luminosity over several frames and look
>                                             ^^^
>                                             for

Hey, never mind. My eyes are not what they used to be, either.

Theodore Kilgore

Re: Power frequency detection.

[Andy Walls]

On Sun, 2010-12-19 at 14:51 -0600, Theodore Kilgore wrote:
> 
> On Sun, 19 Dec 2010, Andy Walls wrote:
> 
> > Theodore,
> > 
> > Aside from detect measurment of the power line, isn't a camera the best sort of sensor for this measurment anyway?
> > 
> > Just compute the average image luminosity over several frames and look for (10 Hz ?) periodic variation (beats), indicating a mismatch.
> > 
> > Sure you could just ask the user, but where's the challenge in that. ;)
> > 
> > Regards,
> > Andy
> 
> Well, if it is "established policy" to go with doing this as a control, I 
> guess we can just go ahead instead of doing something fancy.

My policy is let computers do what computers do well, and let people do
what people do well.  Looking at an image, recognizing flicker, and
twiddling knobs to make it go away (to one's own satisfaction) is much
better left to a person for one time adjustments.



> But it is nice to hear from you. Here is why.
> 
> The camera in question is another jeilinj camera. Its OEM software for 
> that other OS does present the option to choose line frequency. It also 
> asks for the user to specify an image quality index. I can not recall that 
> the software I got with my camera did any such thing. As I recall, it 
> merely let the camera to start streaming. Bur at the moment I have no idea 
> where I put that old CD.

The Software for our Sakar branded Jeilin camera was a little smarter.
I seem to recall image size adjustments.  I also recall the driver
binary contained multiple different MJPEG headers that I guess it could
have tack back on to the incoming stream.

However, the camera suffered such love/abuse at the hands of my 11 year
old daughter that it no longer functions, even with the electrical tape
that still holds the case together. ;)


> So, while I have you on the line, do you recall whether or not the OEM 
> software for the camera you bought for your daughter present any such 
> setup options?

I cannot.


> The new camera may be different in some particulars from the ones we have. 
> It does have a new Product number, so apparently Jeilin might not have 
> thought it is identical to the other ones. It does use a slightly 
> different initialization sequence. Therefore, the quick-and-dirty way to 
> support it would be just to introduce a patch which has switch statements 
> or conditionals all over the place, and just to support whatever the 
> camera was observed to do. However, that is obviously dirty as well as 
> quick.
> 
> While playing around with the code a bit, I have managed to make my 
> old camera work with essentially the same init sequence that the new 
> one is using. If this can be done right, it would clear a lot of crud out 
> of the driver code. Unfortunately, doing it right involves testing...

When researching Jeilin's offerings on their website long ago I recall a
few different chipsets, but only one that matched the MJPEG type camera
application.  It's probably just the difference between different
firmware versions in the camera with the same Jeilin camera chipset.


> Finally, one concern that I have in the back of my mind is the question of 
> control settings for a camera which streams in bulk mode and requires the 
> setup of a workqueue. The owner of the camera says that he has 
> "encountered no problems" with running the two controls mentioned above. 
> Clearly, that is not a complete answer which overcomes all possible 
> objections. Rather, things are OK if and only if we can ensure that these 
> controls can be run only while the workqueue that does the streaming is 
> inactive. Somehow, I suspect that the fact that a sensible user would only 
> run such commands at camera setup is an insufficient guarantee that no 
> problems will ever be encountered.
> 
> So, as I said, the question of interaction of a control and a workqueue is 
> another problem interesting little problem. Your thoughts on this 
> interesting little problem would be appreciated.

I am unfamiliar with:

1. Any USB interface mutual exclusions the kernel USB API and subsystem
provides as well as what the GSPCA framework provides.

2. Any USB transaction buffering and tracking the kernel USB subsystem
provides.

3. Whether the kernel and Jeilin chip allow USB sends and receives to be
interleaved to different bulk endpoints.




So I might not be able to provide too much help.  I have 2 ideas for you
coming from the perspective of me being a USB idiot:


1. Since the jlj_dostream() work handler function is essentially just a
synchronous poll loop on the device, you could just have it process the
ioctl() requests to change a control synchronously. 

a. The ioctl() call for the v4l2 control would submit a command to some
queue you set up for the purpose, and then sleep on a wait queue. 

b. The jlj_dostream() function would check the command queue at its
convenience, process any control command, and then wake up the wait
queue that the ioctl() is waiting on.

For this idea, don't forget to implement the command queue with proper
locking or other mutual exclusion.  You'll also need to think about how
to place ioctl() callers on the wait_queue and how to wake them up in
FIFO order, if you use this idea and allow multiple v4l2 control ioctl()
to be queued.



2. Restructure the workqueue function, jlj_dostream(), to handle a work
object in one pass (e.g. no loop to read more than one frame), handle
two different types of work objects (one for stream polling and one for
control ioctl() requests), and have it automatically reschedule the
stream polling work object.

a. When streaming, the current, single work object would still be used
and jlj_dostream() must be able to check that the work object is the one
indicating streaming work.  jlj_dostream() would only perform work
required to read one whole frame, unless you want to get fancy and deal
with partial frames.  The jlj_dostream() handler would then reschedule
the work object for streaming - maybe with a sensible delay.

b. For a V4L2 control ioctl() that needs to send a command to the
device, the ioctl() fills out the needed parameters in a scratch-pad
location and queues a different work object, associated with those
scratchpad parameters.  The ioctl() then sleeps on a wait queue
associated with that work object.  When the work handler function,
jlj_dostream(), gets called it must be able to determine the work object
is the one associated with an ioctl() control.  jlj_dostream() then
performs the actions required for the ioctl() and the wakes up the
wait_queue on which the ioctl() is waiting.  The work object is not
rescheduled by the work handler function.


For this idea, you'll be relying on the single-threaded workqueue to
provide mutual exclusion between processing of the two different types
of work objects (streaming and v4l2 control ioctl).  You can structure
things to have more than 1 work object for V4L2 control ioctl()
processing, if you like, since the workqueue can queue any number of
work objects.  But if you allow more than one ioctl() related work
object to be queued, you'll have to be careful about how things are
placed on the wait_queue and how they are awakened.



> As I said, Merry Christmas :-)


Merry Christmas.

Regards,
Andy

> Theodore Kilgore

Re: Power frequency detection.

[Andy Walls]

On Sun, 2010-12-19 at 17:00 -0500, Andy Walls wrote:
> On Sun, 2010-12-19 at 14:51 -0600, Theodore Kilgore wrote:

Just a few more details...

> So I might not be able to provide too much help.  I have 2 ideas for you
> coming from the perspective of me being a USB idiot:
> 
> 
> 1. Since the jlj_dostream() work handler function is essentially just a
> synchronous poll loop on the device, you could just have it process the
> ioctl() requests to change a control synchronously. 
> 
> a. The ioctl() call for the v4l2 control would submit a command to some
> queue you set up for the purpose, and then sleep on a wait queue. 
> 
> b. The jlj_dostream() function would check the command queue at its
> convenience, process any control command, and then wake up the wait
> queue that the ioctl() is waiting on.
> 
> For this idea, don't forget to implement the command queue with proper
> locking or other mutual exclusion.  You'll also need to think about how
> to place ioctl() callers on the wait_queue and how to wake them up in
> FIFO order, if you use this idea and allow multiple v4l2 control ioctl()
> to be queued.
> 
> 
> 
> 2. Restructure the workqueue function, jlj_dostream(), to handle a work
> object in one pass (e.g. no loop to read more than one frame), handle
> two different types of work objects (one for stream polling and one for
> control ioctl() requests), and have it automatically reschedule the
> stream polling work object.
> 
> a. When streaming, the current, single work object would still be used
> and jlj_dostream() must be able to check that the work object is the one
> indicating streaming work.  jlj_dostream() would only perform work
> required to read one whole frame, unless you want to get fancy and deal
> with partial frames.  The jlj_dostream() handler would then reschedule
> the work object for streaming - maybe with a sensible delay.
> 
> b. For a V4L2 control ioctl() that needs to send a command to the
> device, the ioctl() fills out the needed parameters in a scratch-pad
> location and queues a different work object, associated with those
> scratchpad parameters.  The ioctl() then sleeps on a wait queue
> associated with that work object.  When the work handler function,
> jlj_dostream(), gets called it must be able to determine the work object
> is the one associated with an ioctl() control.  jlj_dostream() then
> performs the actions required for the ioctl() and the wakes up the
> wait_queue on which the ioctl() is waiting.  The work object is not
> rescheduled by the work handler function.
> 
> 
> For this idea, you'll be relying on the single-threaded workqueue to
> provide mutual exclusion between processing of the two different types
> of work objects (streaming and v4l2 control ioctl).  You can structure
> things to have more than 1 work object for V4L2 control ioctl()
> processing, if you like, since the workqueue can queue any number of
> work objects.  But if you allow more than one ioctl() related work
> object to be queued, you'll have to be careful about how things are
> placed on the wait_queue and how they are awakened.
> 
> 

For implementing either of these ideas, you may also wish to investigate
the use of completions instead of wait_queues.  I've never used
completions myself, so I'm not sure if they'll work.

With a quick grep through the kernel, I only find the cx18 driver and
libsas as examples using multiple work objects for a work handler
function.  In both of those, the purpose of the of work object is
indicated with a field in the structure that also contains the work
object.

Regards,
Andy

Re: Power frequency detection.

[Adam Baker]

On Sunday 19 Dec 2010, Theodore Kilgore wrote:
> Finally, one concern that I have in the back of my mind is the question of 
> control settings for a camera which streams in bulk mode and requires the 
> setup of a workqueue. The owner of the camera says that he has 
> "encountered no problems" with running the two controls mentioned above. 
> Clearly, that is not a complete answer which overcomes all possible 
> objections. Rather, things are OK if and only if we can ensure that these 
> controls can be run only while the workqueue that does the streaming is 
> inactive. Somehow, I suspect that the fact that a sensible user would only 
> run such commands at camera setup is an insufficient guarantee that no 
> problems will ever be encountered.
> 
> So, as I said, the question of interaction of a control and a workqueue is 
> another problem interesting little problem. Your thoughts on this 
> interesting little problem would be appreciated.

I don't think you can assume a user won't try to adjust such controls while 
streaming - if I had one I'd certainly want to try swapping the control while 
streaming to see if I could see any affect on the output. Even though sq905.c 
doesn't have any controls on the camera it still ended up needing the locking 
that would make this safe. See the header comment on sq905_dostream

Adam

Re: Power frequency detection.

[Andy Walls]

On Sun, 2010-12-19 at 18:21 -0600, Theodore Kilgore wrote:

> If the controls are locked while the workqueue is doing the streaming, 
> then probably that does fix the problem? Most likely, that is the simplest 
> thing to do. 

Drivers are allowed to return -EBUSY per the V4L2 spec.

http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-ctrl.html
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-ext-ctrls.html

Regards,
Andy


> Theodore Kilgore

Re: Power frequency detection.

[Theodore Kilgore]

On Sun, 19 Dec 2010, Andy Walls wrote:

> On Sun, 2010-12-19 at 14:51 -0600, Theodore Kilgore wrote:
> > 
> > On Sun, 19 Dec 2010, Andy Walls wrote:
> > 
> > > Theodore,
> > > 
> > > Aside from detect measurment of the power line, isn't a camera the best sort of sensor for this measurment anyway?
> > > 
> > > Just compute the average image luminosity over several frames and look for (10 Hz ?) periodic variation (beats), indicating a mismatch.
> > > 
> > > Sure you could just ask the user, but where's the challenge in that. ;)
> > > 
> > > Regards,
> > > Andy
> > 
> > Well, if it is "established policy" to go with doing this as a control, I 
> > guess we can just go ahead instead of doing something fancy.
> 
> My policy is let computers do what computers do well, and let people do
> what people do well.  Looking at an image, recognizing flicker, and
> twiddling knobs to make it go away (to one's own satisfaction) is much
> better left to a person for one time adjustments.

OK.


> > But it is nice to hear from you. Here is why.
> > 
> > The camera in question is another jeilinj camera. Its OEM software for 
> > that other OS does present the option to choose line frequency. It also 
> > asks for the user to specify an image quality index. I can not recall that 
> > the software I got with my camera did any such thing. As I recall, it 
> > merely let the camera to start streaming. Bur at the moment I have no idea 
> > where I put that old CD.
> 
> The Software for our Sakar branded Jeilin camera was a little smarter.

Oh. So _you_ had a Sakar branded camera. This was one of the things that 
causes problems recently. In gspca.txt we have the supported camera listed 
as 

jeilinj         0979:0280       Sakar 57379

which seemed to me to be quite wrong, as (unless I have made a bad 
mistake) the Sakar 57379 has a Jeilin 2005C or D chip inside (proprietary 
interface camera, Product number 0x227, definitely not one of these guys) 
and AFAICT the Jeilin 2005C-D cameras can not be made to stream at all, 
operating only in stillcam mode. So, when I was contacted about this new 
camera I saw that listing and thought it had to be wrong!

Hoping that you still have some way to check what the Sakar product number 
of your cam really was...


> I seem to recall image size adjustments.  

Yes, the new one does. And these adjustments do seem to work with my old 
one, too. 


I also recall the driver
> binary contained multiple different MJPEG headers that I guess it could
> have tack back on to the incoming stream.

Hmmm. Probably that had something to do with the "quality" setting?

> 
> However, the camera suffered such love/abuse at the hands of my 11 year
> old daughter that it no longer functions, even with the electrical tape
> that still holds the case together. ;)
> 
> 
> > So, while I have you on the line, do you recall whether or not the OEM 
> > software for the camera you bought for your daughter present any such 
> > setup options?
> 
> I cannot.
> 
> 
> > The new camera may be different in some particulars from the ones we have. 
> > It does have a new Product number, so apparently Jeilin might not have 
> > thought it is identical to the other ones. It does use a slightly 
> > different initialization sequence. Therefore, the quick-and-dirty way to 
> > support it would be just to introduce a patch which has switch statements 
> > or conditionals all over the place, and just to support whatever the 
> > camera was observed to do. However, that is obviously dirty as well as 
> > quick.
> > 
> > While playing around with the code a bit, I have managed to make my 
> > old camera work with essentially the same init sequence that the new 
> > one is using. If this can be done right, it would clear a lot of crud out 
> > of the driver code. Unfortunately, doing it right involves testing...
> 
> When researching Jeilin's offerings on their website long ago I recall a
> few different chipsets, but only one that matched the MJPEG type camera
> application.  It's probably just the difference between different
> firmware versions in the camera with the same Jeilin camera chipset.
> 
> 
> > Finally, one concern that I have in the back of my mind is the question of 
> > control settings for a camera which streams in bulk mode and requires the 
> > setup of a workqueue. The owner of the camera says that he has 
> > "encountered no problems" with running the two controls mentioned above. 
> > Clearly, that is not a complete answer which overcomes all possible 
> > objections. Rather, things are OK if and only if we can ensure that these 
> > controls can be run only while the workqueue that does the streaming is 
> > inactive. Somehow, I suspect that the fact that a sensible user would only 
> > run such commands at camera setup is an insufficient guarantee that no 
> > problems will ever be encountered.
> > 
> > So, as I said, the question of interaction of a control and a workqueue is 
> > another problem interesting little problem. Your thoughts on this 
> > interesting little problem would be appreciated.
> 
> I am unfamiliar with:
> 
> 1. Any USB interface mutual exclusions the kernel USB API and subsystem
> provides as well as what the GSPCA framework provides.
> 
> 2. Any USB transaction buffering and tracking the kernel USB subsystem
> provides.
> 
> 3. Whether the kernel and Jeilin chip allow USB sends and receives to be
> interleaved to different bulk endpoints.

Hmmm. Oh, that is right. The camera is using different endpoints for 
commands from what it uses for data. Good question what the kernel and the 
camera are doing, though.

> 
> 
> 
> 
> So I might not be able to provide too much help.  I have 2 ideas for you
> coming from the perspective of me being a USB idiot:
> 
> 
> 1. Since the jlj_dostream() work handler function is essentially just a
> synchronous poll loop on the device, you could just have it process the
> ioctl() requests to change a control synchronously. 
> 
> a. The ioctl() call for the v4l2 control would submit a command to some
> queue you set up for the purpose, and then sleep on a wait queue. 
> 
> b. The jlj_dostream() function would check the command queue at its
> convenience, process any control command, and then wake up the wait
> queue that the ioctl() is waiting on.
> 
> For this idea, don't forget to implement the command queue with proper
> locking or other mutual exclusion.  You'll also need to think about how
> to place ioctl() callers on the wait_queue and how to wake them up in
> FIFO order, if you use this idea and allow multiple v4l2 control ioctl()
> to be queued.
> 
> 
> 
> 2. Restructure the workqueue function, jlj_dostream(), to handle a work
> object in one pass (e.g. no loop to read more than one frame), handle
> two different types of work objects (one for stream polling and one for
> control ioctl() requests), and have it automatically reschedule the
> stream polling work object.
> 
> a. When streaming, the current, single work object would still be used
> and jlj_dostream() must be able to check that the work object is the one
> indicating streaming work.  jlj_dostream() would only perform work
> required to read one whole frame, unless you want to get fancy and deal
> with partial frames.  The jlj_dostream() handler would then reschedule
> the work object for streaming - maybe with a sensible delay.
> 
> b. For a V4L2 control ioctl() that needs to send a command to the
> device, the ioctl() fills out the needed parameters in a scratch-pad
> location and queues a different work object, associated with those
> scratchpad parameters.  The ioctl() then sleeps on a wait queue
> associated with that work object.  When the work handler function,
> jlj_dostream(), gets called it must be able to determine the work object
> is the one associated with an ioctl() control.  jlj_dostream() then
> performs the actions required for the ioctl() and the wakes up the
> wait_queue on which the ioctl() is waiting.  The work object is not
> rescheduled by the work handler function.
> 
> 
> For this idea, you'll be relying on the single-threaded workqueue to
> provide mutual exclusion between processing of the two different types
> of work objects (streaming and v4l2 control ioctl).  You can structure
> things to have more than 1 work object for V4L2 control ioctl()
> processing, if you like, since the workqueue can queue any number of
> work objects.  But if you allow more than one ioctl() related work
> object to be queued, you'll have to be careful about how things are
> placed on the wait_queue and how they are awakened.
> 
> 
> 
> > As I said, Merry Christmas :-)
> 
> 
> Merry Christmas.
> 
> Regards,
> Andy
> 
> > Theodore Kilgore
> 
> 

I will try to digest the rest of this and the next letter, later.


Theodore Kilgore

Re: Power frequency detection.

[Andy Walls]

On Sun, 2010-12-19 at 18:13 -0600, Theodore Kilgore wrote:
> 
> On Sun, 19 Dec 2010, Andy Walls wrote:

> > The Software for our Sakar branded Jeilin camera was a little smarter.
> 
> Oh. So _you_ had a Sakar branded camera. This was one of the things that 
> causes problems recently. In gspca.txt we have the supported camera listed 
> as 
> 
> jeilinj         0979:0280       Sakar 57379
> 
> which seemed to me to be quite wrong, as (unless I have made a bad 
> mistake) the Sakar 57379 has a Jeilin 2005C or D chip inside (proprietary 
> interface camera, Product number 0x227, definitely not one of these guys) 
> and AFAICT the Jeilin 2005C-D cameras can not be made to stream at all, 
> operating only in stillcam mode. So, when I was contacted about this new 
> camera I saw that listing and thought it had to be wrong!
> 
> Hoping that you still have some way to check what the Sakar product number 
> of your cam really was...

The Internet never forgets:

http://www.spinics.net/lists/linux-media/msg07025.html

http://www.spinics.net/lists/linux-media/msg07127.html

It looks like I hypothesized my camera had a JL2008 chips given the AVI
files it created had "JL2008V2C" in it.

I hope that email thread archive has the information you need.

Also there is this thread where Jean-Francois talked about the contents
of gspca.txt:

http://www.spinics.net/lists/linux-media/msg08477.html


Regards,
Andy

Re: Power frequency detection.

[Theodore Kilgore]

On Sun, 19 Dec 2010, Adam Baker wrote:

> On Sunday 19 Dec 2010, Theodore Kilgore wrote:
> > Finally, one concern that I have in the back of my mind is the question of 
> > control settings for a camera which streams in bulk mode and requires the 
> > setup of a workqueue. The owner of the camera says that he has 
> > "encountered no problems" with running the two controls mentioned above. 
> > Clearly, that is not a complete answer which overcomes all possible 
> > objections. Rather, things are OK if and only if we can ensure that these 
> > controls can be run only while the workqueue that does the streaming is 
> > inactive. Somehow, I suspect that the fact that a sensible user would only 
> > run such commands at camera setup is an insufficient guarantee that no 
> > problems will ever be encountered.
> > 
> > So, as I said, the question of interaction of a control and a workqueue is 
> > another problem interesting little problem. Your thoughts on this 
> > interesting little problem would be appreciated.
> 
> I don't think you can assume a user won't try to adjust such controls while 
> streaming - 

what I said, actually

if I had one I'd certainly want to try swapping the control while 
> streaming to see if I could see any affect on the output. 

Yeah, I tell people that I like to see if I can hook things together and 
make something go "bang." Or, that I do research about locating that 
elusive magic smoke in the hardware, which makes it run. So maybe I 
would try that too, just for the pure hell of it. But I did say 
something about a "sensible user"? Neither of us, apparently. And come 
down to it, if one cannot trust you, and cannot trust me, as much work as 
we did together, then nobody can be trusted at all. :-}

Even though sq905.c 
> doesn't have any controls on the camera it still ended up needing the locking 
> that would make this safe. See the header comment on sq905_dostream

If the controls are locked while the workqueue is doing the streaming, 
then probably that does fix the problem? Most likely, that is the simplest 
thing to do. 

Theodore Kilgore

Re: Power frequency detection.

[Theodore Kilgore]

On Sun, 19 Dec 2010, Andy Walls wrote:

> On Sun, 2010-12-19 at 18:13 -0600, Theodore Kilgore wrote:
> > 
> > On Sun, 19 Dec 2010, Andy Walls wrote:
> 
> > > The Software for our Sakar branded Jeilin camera was a little smarter.
> > 
> > Oh. So _you_ had a Sakar branded camera. This was one of the things that 
> > causes problems recently. In gspca.txt we have the supported camera listed 
> > as 
> > 
> > jeilinj         0979:0280       Sakar 57379
> > 
> > which seemed to me to be quite wrong, as (unless I have made a bad 
> > mistake) the Sakar 57379 has a Jeilin 2005C or D chip inside (proprietary 
> > interface camera, Product number 0x227, definitely not one of these guys) 
> > and AFAICT the Jeilin 2005C-D cameras can not be made to stream at all, 
> > operating only in stillcam mode. So, when I was contacted about this new 
> > camera I saw that listing and thought it had to be wrong!

OK, I looked again more closely in libgphoto2/camlibs/jl2005c/library.c, 
in which one sees 

Sakar no. 75379

If you are my age you _do_ need to look twice. Then three times. Then have 
a friend point out that you did not see something right. In case you are 
missing it, too

57379 != 75379

So, thanks.

At least that is one thing I do not need to fix.

> > 
> > Hoping that you still have some way to check what the Sakar product number 
> > of your cam really was...
> 
> The Internet never forgets:
> 
> http://www.spinics.net/lists/linux-media/msg07025.html
> 
> http://www.spinics.net/lists/linux-media/msg07127.html

Yes, I guess that clears it all up. I _do_ still have those messages 
somewhere, but it is every so much easier to do it this way.

> 
> It looks like I hypothesized my camera had a JL2008 chips given the AVI
> files it created had "JL2008V2C" in it.

This appears to be a very reasonable hypothesis. I never thought the 
camera has a JL2005C chip in it. I just thought I had erroneously listed a 
camera in gspca.txt which was in fact some other kind of camera. But, as I 
said, 57379 != 75379 and they are not the same camera, either.

Thanks again.

Theodore Kilgore