From patchwork Tue Nov 17 19:46:44 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 60777 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id nAHJlQV6007492 for ; Tue, 17 Nov 2009 19:47:27 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754236AbZKQTrT (ORCPT ); Tue, 17 Nov 2009 14:47:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754535AbZKQTrT (ORCPT ); Tue, 17 Nov 2009 14:47:19 -0500 Received: from bombadil.infradead.org ([18.85.46.34]:51682 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753639AbZKQTrS (ORCPT ); Tue, 17 Nov 2009 14:47:18 -0500 Received: from 201-13-170-39.dial-up.telesp.net.br ([201.13.170.39] helo=pedra.chehab.org) by bombadil.infradead.org with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1NAU1J-0003NM-El; Tue, 17 Nov 2009 19:47:22 +0000 Message-ID: <4B02FDA4.5030508@infradead.org> Date: Tue, 17 Nov 2009 17:46:44 -0200 From: Mauro Carvalho Chehab User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Manu Abraham CC: Jean Delvare , LMML Subject: Re: Details about DVB frontend API References: <20091022211330.6e84c6e7@hyperion.delvare> <20091023051025.597c05f4@caramujo.chehab.org> <1a297b360910221329o4b832f4ewaee08872120bfea0@mail.gmail.com> In-Reply-To: <1a297b360910221329o4b832f4ewaee08872120bfea0@mail.gmail.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org diff -r b5505a985f24 linux/include/linux/dvb/frontend.h --- a/linux/include/linux/dvb/frontend.h Sat Feb 21 01:12:09 2009 +0400 +++ b/linux/include/linux/dvb/frontend.h Tue Apr 07 18:19:22 2009 +0400 @@ -645,4 +645,118 @@ }; #define DVBFE_GET_EVENT _IOR('o', 86, struct dvbfe_event) +/* Frontend General Statistics + * General parameters + * FE_*_UNKNOWN: + * Parameter is unknown to the frontend and doesn't really + * make any sense for an application. + * + * FE_*_RELATIVE: + * Parameter is relative on the basis of a ceil - floor basis + * Format is based on empirical test to determine + * the floor and ceiling values. This format is exactly the + * same format as the existing statistics implementation. + */ +enum fecap_quality_params { + FE_QUALITY_UNKNOWN = 0, + FE_QUALITY_SNR = (1 << 0), + FE_QUALITY_CNR = (1 << 1), + FE_QUALITY_EsNo = (1 << 2), + FE_QUALITY_EbNo = (1 << 3), + FE_QUALITY_RELATIVE = (1 << 31), +}; + +enum fecap_scale_params { + FE_SCALE_UNKNOWN = 0, + FE_SCALE_dB = (1 << 0), + FE_SCALE_RELATIVE = (1 << 31), +}; + +enum fecap_error_params { + FE_ERROR_UNKNOWN = 0, + FE_ERROR_BER = (1 << 0), + FE_ERROR_PER = (1 << 1), + FE_ERROR_RELATIVE = (1 << 31), +}; + +enum fecap_unc_params { + FE_UNC_UNKNOWN = 0, + FE_UNC_RELATIVE = (1 << 31), +}; + +/* General parameters + * width: + * Specifies the width of the field + * + * exponent: + * Specifies the multiplier for the respective field + * MSB:1bit indicates the signdness of the parameter + */ +struct fecap_quality { + enum fecap_quality_params params; + enum fecap_scale_params scale; + + __u32 width; + __s32 exponent; +}; + +struct fecap_strength { + enum fecap_scale_params params; + __u32 width; + __s32 exponent; +}; + +struct fecap_error { + enum fecap_error_params params; + __u32 width; + __s32 exponent; +}; + +struct fecap_statistics { + struct fecap_quality quality; + struct fecap_strength strength; + struct fecap_error error; + enum fecap_unc_params unc; +}; I don't like the idea of creating structs grouping those parameters. While for certain devices this may mean a more direct approach, for others, this may not make sense, due to the way their API's were implemented (for example, devices with firmware may need several calls to get all those info). +#define FE_STATISTICS_CAPS _IOR('o', 84, struct fecap_statistics) +#define FE_SIGNAL_LEVEL _IOR('o', 85, __u32) +#define FE_SIGNAL_STATS _IOR('o', 86, struct fesignal_stat) Instead of defining 3 new ioctls, the better is to use the DVBS2API, maybe extending it to allow receiving more than one parameter at the same time (with an approach similar to what we did with V4L extended CTRLs API). We are already redefining some existing ioctls there, so it would be clearer for the userspace developers what would be the new way to retrieve frontend stats, as we can simply say that DVBS2API features superseeds the equivalent DVB v3 ioctls. Comments? Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html