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.
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.
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
