[linux-dvb] [V4] Querying capabilities

hunold at linuxtv.org hunold at linuxtv.org
Thu Sep 15 16:26:13 CEST 2005


Johannes Stezenbach writes:
> I think the current implementation is simpler, more extensible and
> more consistent (same interface for video/audio/demux etc.).

We agreed that some of the enums should be changed to #defines, and that 
other enum should not look like #define by setting them to values manually 
(ie. DVB_DEMUX_FOO = (1 << 2)). 

If I remove these manual settings for the enums, we lose the ability to 
(ab)use the enums as bitfields for querying the capabilities, because the 
values are no longer a power of two and can be distinguished. 

So we either keep these manual settings or we need to change capability 

Simpler in this case means that we annoy C++ users and that the userspace 
code must know the return code of the different capabilities, because they 
are all returned as unsigned int. 

It's more extensible, yes, because adding new capabilities does not break 
binary compatibility. 

More consistent, hmm, I don't know. 

We agreed that capabilities don't reflect any current status, but the device 
capabilities. So it will return the number of PID filters rather than the 
number of filters that can be opened in the current system state. 

With this in mind, I think we can safely return a static structure here, 
because there is no dynamic in here. 

Ok, if we want to keep the current interface, we need to introduce #defines 
for the things we just put into enums to be able to use bitfields. Not very 

I think doing it with explicit structures is ok for the demux part, because 
things are not likely to change or extended any more. 

> But it's not big issue, I don't mind if you change it if you
> think it works better.

Ok, good. 8-) 

I think the biggest problems are in the video and especially audio part. A 
lot of things simply cannot be expressed with capabilities, like decoder 0 
can play MP2, MP3 and AC3, decoder 1 can play MP2 and MP3, but decoder can 
only play AC3 only if decoder 1 does not play MP3. 

In this case, returning -EOPNOTSUPP when setting up a decoder is easier that 
getting this to know in advance with capabilities. 

The question is, if your application is truly generic, ie. if it is compiled 
once and then run on different environments. Or if it is (like in the 
embedded world) targetted to just a few platforms where you know the 
hardware limitations in advance. 


>> struct dvb_demux_capability
>> {
>> 	int num_pes_filters;,      /*!< number of available PES filters 

> should these be unsigned?

Probably yes. 

>> #define DVB_DEMUX_GET_CAPS _IOWR(DVB_IOCTL_BASE, 0x20, struct 
>> dvb_demux_capability)  
>> Comments?
> Word-wrapped code sucks.

Webmailer suck. 

> Johannes

I'm not that lucky with my suggestions so far, so I need to think and 
discuss about this a little more. 


More information about the linux-dvb mailing list