On Mon, 2009-02-16 at 16:03 -0800, VDR User wrote: > On Mon, Feb 16, 2009 at 1:39 PM, wk <handygewinnspiel@xxxxxx> wrote: > > Devin, > > > > can you please explain, how others should contribute to an dvb api if > > - the only DVB API file to be found is a pdf file, and therefore not > > editable. Which files exactly to be edited you are writing of? > > - one doesn't know which ioctls exist for what function, which return codes > > and arguments, how to understand and to use..? > > > > What you suggest is almost impossible to someone not perfectly familiar with > > the drivers, only for dvb experts who have written at least a bunch of > > drivers. > > Its something different than sending patches for one single driver where > > some bug/improvement was found. > > > > On the other hand, in principle a driver without existing api doc is > > useless. Nobody can use it, the same for drivers with undocumented new > > features. > > Exactly! Should be entertaining to hear the answers to everything but > the first 'what files do you edit', though the rest of the questions > will likely continue to be ignored. It's actually not that hard. I was unfamiliar and looked at the header file and the code that processed the requests. I whipped up a little tuning app in a short time: http://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg00734.html (but of course longer than it would have taken if an up to date document were available.) > It seems some think those not > familiar with s2api technical structure should reverse engineer it and > write the documentation rather then the people who actually created > it. Actually, I had been toying with the idea since it should be a simple addition to the v3 spec, but I got too busy (day job). V5 is only a single ioctl() for mucking with the frontend IIRC. The rest is the same as the DVB V3 API unmodified, again IIRC. With V5, you issue a list of frontend properties to set and/or a command to do the tune in that list and submit it via ioctl(). This list is returned with a return status for each item in the list you submitted. It reminded me of database transactions. It was actually more complex to extract the current frontend status with the DVB V3 API events and whatnot, but the documentation spares some of the headache there. Regards, Andy > To even suggest such a thing is absurd in my humble opinion. > Talk about counter-productive... -- 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
