[linux-dvb] DVB API update

Manu Abraham abraham.manu at gmail.com
Tue Sep 18 16:27:37 CEST 2007


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.




More information about the linux-dvb mailing list