Greg KH wrote:
On Sat, May 22, 2010 at 10:15:05AM +0100, R.M. Thomas wrote:
Greg KH wrote:
On Fri, May 21, 2010 at 08:33:50PM +0000, Mike Thomas wrote:
I am the unfortunate author/maintainer of the easycapdc60 driver, which targets
a single USB device: the EasyCAP DC60 dongle/stick having USB ID
05e1:0408. This is widely marketed as an inexpensive ($10) means
of digitizing videotapes
and similar sources. The front-end video chip is a SA7113H, the audio chip is
(normally - see below) a VT1612A (or equivalent) and the bridge
is a STK1160. The easycapdc60 driver is an integrated
audio/video driver entirely independent
of the V4L2 videodev module, although it does use the V4L2
protocol for IOCTL. The driver was made publically available in
January 2010 as a GPL Sourceforge
project.
The issue raised in the present thread arises from the fact that a given EasyCAP
responds consistently in one of two different ways when probed. One kind of
EasyCAP always gives the output already posted above:
http://pastebin.com/WPGLZtDA
I call these "slow" EasyCAPs. I do not own any of these, but have been obliged
to recognize their existence following numerous complaints by users on the
Sourceforge project's Open Discussion forum. The second kind of EasyCAP, of
which I possess three, gives different output:
http://pastebin.com/k7MFfkA3
I call these "normal EasyCAPs". The difference between the slow and normal
EasyCAPs is in the isochronous audio interface. The slow EasyCAPs have audio
format PCM8, tSamFreq 8000 and wMaxPacketSize 9. The normal EasyCAPs have audio
format PCM, tSamFreq 48000 and wMaxPacketSize 256.
When originally developing the driver over Christmas 2009/2010 I was unaware of
the slow EasyCAPs, and I hard-coded the URB parameters to give trouble-free
audio streaming on the normal EasyCAP which I was using for testing. The audio
part of the driver in its present form does not expect a wMaxPacketSize of
anything other than 256, and just concedes defeat gracefully when encountering a
different value.
I should like to enhance the driver to cope with the slow EasyCAPs, and I
suppose it will be straightforward in principle to modify the URB parameters to
accommodate slower audio streaming. But the way in which the driver sets the
registers of the VT1612A will not be right if the slow EasyCAPs contain a
different audio chip, in which case the amount of work required will increase
very substantially and my resolve may falter.
Thanks for the very detailed descriptions. How about just removing the
device ids of these devices that don't work well?
Also, if you want, you should get the driver into the main kernel tree.
I'd be glad to add it to the drivers/staging/ portion of the kernel if
you don't think it is ready to merge to the "real" part of the kernel
for this type of driver.
Just let me know.
thanks,
greg k-h
It would be excellent if the driver could be integrated into the
kernel tree. I have taken the development nearly as far as I can on
my own, and the source code would certainly benefit from expert
appraisal and reworking of the weaker parts, for example the locking
procedures (and very probably other things I have not even
recognized as weaknesses). And of course an out-of-tree driver is a
major inconvenience for users.
Great, care to point me to the version of the driver that you want me to
include?
In the development version of the driver here at home I have
recently added some features in response to user requests (most
notably 320x240 and other reduced resolutions) and was about to
start looking at possible solutions to the "slow EasyCAP" issue
prior to releasing version 0.8. It might be more efficient,
however, to defer consideration of the slow EasyCAPs until the
driver has been integrated into the kernel tree, as there is a much
better chance of finding a sensible way forward on this when
guidance from experienced developers is available. I am coming to
the view, therefore, that I should release version 0.8 on
Sourceforge with minimal delay (a couple of weeks is probably the
best I can do), and should then work towards migrating the driver to
drivers/staging/.
I am aware that I shall need to reformat the source code to bring it
into line with the conventional (K&R) kernel coding style, and I
shall do this before submitting the driver for inclusion in
drivers/staging/. I am happy to cooperate in meeting this and any
other requirements which may arise in order that mainstream users
can get ready access to the driver as soon as possible.
Wonderful. I can even clean up the formatting if you need me to, and
lots of other people love doing that as well :)
thanks,
greg k-h
My present plan is to upload the final version 0.8 of the driver to
Sourceforge no later than fifteen days from now, i.e. on or before 6
June. If you are willing to wait until then, version 0.8 is the one
that I would like to see as the candidate for inclusion in
drivers/staging/. It's a lot easier for me to draw a line under the
out-of-tree development at a completed version 0.8 than to apply
substantial patches to a reformatted in-tree version 0.7.1. On the
other hand, version 0.7.1 is a solid road-tested release and you may
prefer to adopt this version as a basis for in-tree development. If so,
I have no objection.
I gratefully accept your offer to do the reformatting for me. Although
I regard it as my responsibility to clean up the code, it's probably a
lot more efficient overall if this is done by somebody who already knows
what's required.
Mike Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
