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