Hi,
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
interface.
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
elegant.
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.
CU
Michael.
