Jon Pennington wrote: > A few weeks ago, Alan Cox suggested that Serguei Miridonov submit the `Unified' Zoran driver he's been working on for inclusion in the Linux kernel proper. Please, forgive me for being quiet so long. Driver programming and maintaining is not my primary job... yet ;-) So, there were a lot of other things to do. I'm sorry... Regarding this topic... Before dedicating time and effort to make proper integration of this driver into the kernel, I would like to see all the pros and cons. The only pro I see right now it that the driver will always be compatible with current kernel without additional effort: is that true? On the cons side there are more points: 1. The driver IMHO is not yet ready for average user. It requires more autodetect features, autoload, etc. 2. It still uses himem interface for large uncompressed captures which must be changed for bootmem interface (is it correct?). 3. I'm not sure how long i2c-old subsystem will be alive in the kernel tree. BTW is it compatible with the new one in case if someone uses other video drivers based on the new i2c subsystem together with the old one? I could write more cons, like need to spend time for fitting the driver into video drivers directory, patching configuration scripts, Configure.help file, etc. So, what do you think? Anyway, this is a GNU licensed code and everybody can take the source and put it into the kernel tree if s/he believes that it worth to do that. > So far, I haven't seen anything to this end being done, so I want to ask some questions to see if this is practical :). There appear to me to be three basic problems with merging the Unified Zoran driver right now: > > 1) There is already a ZR36057 driver, as well as a Buz driver. You mean that one in the kernel tree, right? Does it work? I tried it with LML33 card but no success. > 2) Building the Unified driver takes a bit of messing with the Makefile Well, I've sent the new release to Wolfgang for testing it with Buz card, when he finishes, I will release it. This is just minor release which includes NTSC fixes for Buz from Wolfgang. This release should be compatible with 2.2.16-18 and 2.4.2 kernels, at least, I've compiled it from the same source and with single Makefile with all these kernels and it worked with both DC10plus and LML33 cards. If you are impatient, take it from http://www.cicese.mx/~mirsev/Linux/DC10plus/zoran-driver-0.7b-M.tar.gz Please, let me know if it breaks something. > 3) It seems most practical to use the `update' script in the Unified package to insert the proper modules for your type of card (buz, dc10, lml33). Right now - yes. Later, I think that Wolfgang's approach to autodetect will be more advanced. It would be good idea to attach right driver to specific /dev/videoN device. > Firstly, I'm NOT a programmer, and certainly not a kernel hacker, but this strikes me as workable: What if the code were merged, and buz, dc10, and lml33 were simply `virtual' or `placeholder' modules, that depended on the actual modules to do the work? Great idea! I will think on it. However, is it "number one" thing? It will just replace 'update' script... > This way, someone could have `alias char-major-81 dc10' in the /etc/modules.conf file, or when `modprobe dc10' were typed, all of the other saa*/adv*/zoran* modules were loaded as per the `virtual' modules' specification? > > To address the first problem: > > Dr. Johanni already said that his current (ZR36057/buz) code is a bit out of date, and doesn't have time to really update it. Wolfgang Scherr has said (in so many words) that he wouldn't be ashamed of having the Unified code put into the kernel source tree. As far as I have seen in public forums, Serguei hasn't said anything one way or another about this. In short, if Serguei /were/ to submit the new driver to Alan, Alan would consider it seriously, and the merging process *could* start soon after that, displacing Dr. Johanni's existing code in the tree. Alan, what should I do to prepare the code for submission? > To address the second problem: > > This would cease to be a problem after the code is merged properly. As it stands, the `messing with' I referred to can be fixed by opening the file and typing `:%s/M-OBJS/obj-m/' and saving the bloody file. That can't be too hard... My new Makefile detects the kernel version and does it itself.... > To address the third and most difficult problem: > > As it stands on my system (Linux-2.4.2), there are five modules necessary to run my Pinnacle DC10+; zoran, adv7175, saa7110, i2c-old, and videodev. I've asked repeated times on this and other lists about a more `permanent' solution than using Serguei's update script, but nobody has been able to give me a straight answer. With my trusty Bt878 board, all I had to do was put `alias char-major-81 bttv' in /etc/modules.conf, and it was done for me. By using a placeholder module model, I (or anyone else) could do the same thing, but use `dc10' instead of `bttv'. As I stated at the start of this largely incoherent rant, I'm NOT a programmer and know nothing of the way the Linux kernel and it's modules work. If my idea were sound, though, it could change the way all v4l modules were loaded. > > Am I really the first to think of this, or is this just impossible? I believe that the problem is that I (and Wolfgang?) do not have such problem ;-). If you wish to load specific modules for specific device, you can design pre/post-install entries in /etc/modules.conf. It should be as easy as finding that M_OBJS should be changed for obj-m in the Makefile for 2.4.2 kernel ;-). However, how can you specify minor device numbers to assign dc10 to /dev/video1? -- Serguei Miridonov
