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. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
