Trent Piepho wrote:
On Sun, 7 May 2006, Manu Abraham wrote:
Trent Piepho wrote:
Basically that takes GET_CAPS with delivery == 0 and makes it a new ioctl.
GET_CAPS is now simpler, but you have another ioctl in the API. For single
standard tuners, the get_caps ioctl's code stays the same, but a new get_info
or get_delsys ioctl needs to be added. So the trade off is more work in the
drivers, for a simpler API. Either way seems reasonable to me.
Originally due to your comments it had to go. Now how can you say either
way is fine with you ?
What?! Which comment was that? When you first added the DELSYS_QUERY, and
struct dvb_frontend_cap in multi_proto2, posted Apr 25th, I thought it was
a good idea. When you posted multi_proto3, I thought it worked the same as
ver 2, except now you had GET_CAPS to get the capabilities, and GET_PARAMS
to get the current settings, which I thought was a good idea too. I
thought QUERY had just been changed to IGNORE so that it would be
consistent with the other enums, and be used in GET_PARAMS.
I didn't make any comments between ver 2 and ver 3. I thought about suggesting
two ioctls(), GET_CAPS and GET_PARAMS, but you posted ver 3 which already had
that before I got around to saying anything.
[..] Wanted to say more, but restricting myself
But any way here is what you said ..
Trent Piepho wrote:
> On Sat, 22 Apr 2006, Manu Abraham wrote:
>> After some rework landed up with a patch like this.
I don't get it, what is 'modcod'? There is one field named modcod,
(dvb_frontend_params).sat.modcod, that's only for DVB-S. Do you mean
(dvb_frontend_params).caps.delivery? So if you set .caps.delivery=0 then
you get the union of "all the available modulation and coding types" inside
.caps.modulation? That doesn't make sense either.
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
