Hi, On 9/18/07, Manu Abraham <abraham.manu@xxxxxxxxx> wrote: > Felix Domke wrote: > > Manu Abraham wrote: > >>> I'm not against mmap, I'm against using development resources for > >>> implementing it. I can't see the big show-stopper in this issue. > >>> So, seriously: Is there anybody here who *needs* this, based on his own > >>> experience? > >>> If yes, I'll might change my mind. > >> I think it would be nice to have it. > > Yes, it would be nice. > > > > But do you NEED it? Is it a show-stopper for you? Do you have a scenario > > which doesn't work because of THIS? > > It is definitely not a show stopper, but as i said: It is a nice feature > to be incorporated in to. > > > >>>> No, not throwing away anything, see my reply to Rainer. The newer > >>>> features will not be available with the older apps, that's all. You can > >>>> use the same drivers too. Backward compatibility is achieved by keeping > >>>> an additional set of ioctl's, so the old stuff will work as it is. > >>> Will older hardware drivers be compatible with a new dvb-core (more than > >>> maybe changing some identifiers)? > >> As it is, without any change. I think Johannes did the great job of > >> confusing people. > > Don't get personal. > > > > Unstable driver APIs are a huge issue for non-mainstream hardware. Let's > > do our best to keep devices without active maintainers supported. V4 > > would have killed them, so i only want to be sure that your "api > > updates" won't. > > > >>> My approach is to add a "DMX_ADD_PID" ioctl, similar to DMX_SET_FILTER. > >>> [...] > >> This sounds fine to me. > > Great. > > > >>> * "The current API doesn't allow you to do simple TS filters." > >>> > >>> Again, in http://www.spinics.net/lists/linux-dvb/msg09258.html I came up > >>> with my solution, however people noted that this might break FF cards > >>> due. This can probably be avoided by using a better value for > DMX_TAP_TS. > >>> > >>> Note that the dvb-core implementation is trivial, as hardware drivers > >>> are already supporting TS filtering. It's just not exposed to userspace. > >> Mostly USB devices, afaik. Any other devices that you would like to > >> mention ? > > I don't understand this sentence. Any device not ignoring (a not-set) > > TS_PAYLOAD_ONLY-flag should be compatible. > > > I was thinking what all hardware would be having builtin hardware filters. > > > >>> * "The current API doesn't allow you to tune into -S2 transponders." > >> We have solved this one already, drivers also exists, people watch S2 > >> What i pushed out last, is out here: > >> http://jusst.de/manu/04-Jul-07/stb0899.tar.bz2 > > ok. I don't like any part of the API (FE_SET_FRONTEND) to be obsoleted, > > but ok, I can live with it. Please specify a bit more explictely which > > parts of the API are mutually exclusive (FE_SET_FRONTEND vs. > > DVBFE_SET_PARAMS). why are some IOCTLs called DVBFE_ and others FE_? > > > > BTW, this doesn't hold my "backward compatibility" request - if an > > application wants to tune a dvb-s transponder with the new api > > (DVBFE_SET_PARAMS), it won't run against an old api (which only > > implements FE_SET_FRONTEND, but could technically tune). But it seems > > that nobody else cares about this. > > The other option what i can think is to do a version check in the "new > app", to selectively call the relevant ioctl. > > Why don't abstract the dvb layer from enduser applications and put a general library infront which does that version check and tries to keep things consistend to the end applications? The enduser applications would have to implement that API one time but it would help to keep unnecessary changes away from those applications and even allow to clean up things lateron without breaking all the applications... it's just a thought though.. Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
