On 12/15/2013 02:55 PM, Luca Risolia wrote: > Hi Hans, > > thanks for your reply. I understand your point of view. Since the sn9c102 will > be removed from the kernel soon, I am considering another option, that is to > move the driver to UV4L, which is a transparent, ~100% userspace > implementation of V4L2-compliant drivers for input devices. While it may not be the ideal solution from my point of view, one of the wonders of open source is that, hey, it's free! :-) If I may make a suggestion: use the v4l2-compliance tool for these drivers as well. Today it covers about 85% of all ioctls (main missing ones are the streaming ioctls and cropping/selection ioctls). Regards, Hans > So, for those who are still interested in good support for the sn9cxxx, I'll > be porting all the code to userspace. Users will not notice any difference > from a kernel driver. Fore more informations: > > http://linux-projects.org > > Regards, > Luca > > In data domenica 15 dicembre 2013 12:18:17, Hans Verkuil ha scritto: >> Hi Luca, >> >> On 12/14/2013 06:13 PM, Luca Risolia wrote: >>>> From: Hans Verkuil <hans.verkuil@xxxxxxxxx> >>>> >>>> During the last media summit meeting it was decided to move this driver >>>> to >>>> staging as the first step to removing it altogether. >>>> >>>> Most webcams covered by this driver are now supported by gspca. Nobody >>>> has >>>> the hardware to convert the remaining devices to gspca. >>> >>> I have all the boards given by the manufacturer. Last time I tried the >>> gspca driver it certainly did not work with most of the sn9c1xx-based >>> models the gspca driver claims to be supporting (which were a subset of >>> the devices actually supported by sn9c102). >>> >>>> This driver needs a major overhaul to have it conform to the latest >>>> frameworks and compliancy tests. >>> >>> What is not compliant? I will offer my help to update the driver in case >>> but cannot give my help to fix or test all the boards again with the >>> gspca, as it would be a considerable amount of extra work. >> >> Work is ongoing to move all drivers to the latest V4L2 frameworks (control >> framework, using v4l2_fh, v4l2_device, video_ioctl2 & unlocked_ioctl, >> videobuf2 were possible). This reduces code complexity of the drivers and >> will eventually allow us to get rid of old core legacy code. In addition, >> using these frameworks will help drivers to pass the v4l2-compliance test >> tool (part of v4l-utils.git). >> >> For most drivers not yet converted I have hardware myself that I can use to >> do the conversion and testing, but not for the sn9c102. >> >> Given the fact that that driver caters to very old webcams that few people >> use, and for which cheap modern webcam replacements are easily available, >> it is the opinion of the core v4l2 developers that it is not worth the >> effort for us to convert the driver. >> >> The first step in that process is to move it to staging to signal that >> unless something is done this driver will be removed. >> >> There are a number of options: >> >> 1) Nothing is done. In that case the driver will be removed, probably end of >> next year. >> 2) You convert the driver to the various frameworks, make it pass >> v4l2-compliance, etc. In that case there is no reason to remove it. >> 3) My estimate is that option 2) is time consuming. It might be easier for >> you to add support for the webcams to gspca instead. >> 4) Send the webcams that are not (or not correctly) supported by gscpa to >> Hans de Goede, and let him add support for them to gspca. I don't know if >> he wants to, though. He may well decide that it is not worth it, although I >> assume he would be willing to at least fix gspca for webcams that are not >> correctly supported. >> >>>> Without hardware, however, this is next to impossible. Given the fact >>>> that >>>> this driver seems to be pretty much unused (it has been removed from >>>> Fedora >>>> several versions ago and nobody complained about that), we decided to >>>> drop >>>> this driver. >>> >>> As no one has the hardware, what is the reason why the sn9c102 has been >>> moved into gspca, although the sn9c102 driver has been already present in >>> the kernel since years before? >> >> Frankly because sn9c102 isn't very good code. In all fairness, none of >> todays frameworks existed when sn9c102 was first created. It would be done >> quite differently today. Note that AFAIK HdG has some of the webcams >> supported by both gspca and sn9c102, I'm assuming those are working fine >> with gspca. >>> In my opinion the fact that the module has been removed from Fedora does >>> not imply that the driver is unused. For sure that does not mean the >>> sn9c102 driver is unuseful, since gspca does not work properly with all >>> the devices, as I mentioned. >> >> The fact that nobody has been complaining about the removal from Fedora >> indicates that very few people still use the webcams supported by sn9c102. >> >> That in itself is not a problem, but the fact that the code is really old >> and needs a lot of work is. Within 1-2 years I am going to require that all >> V4L2 drivers use at least some of the core frameworks in order to enforce >> consistent API behavior. sn9c102 is one of the very few drivers that has >> the unlucky combination of being too complex to easily/quickly convert, is >> only rarely used, and for which there is a cheap and easy upgrade path for >> the few remaining users (if any) of that driver (i.e. buy a uvc webcam). >> >> We have removed drivers in the past as well for similar reasons. It's done >> very rarely: only if they start blocking progress, there is nobody >> motivated to convert them, and they are only rarely (if ever) used. >> >> Regards, >> >> Hans > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
