On Tue, Jan 15, 2013 at 10:21 AM, Mauro Carvalho Chehab <mche...@redhat.com> wrote: >> Lets say SS, SNR, BER, UCB are queried, but only SS and SNR are ready to >> be returned, whilst rest are not possible? As I remember DVBv5 API is >> broken by design and cannot return error code per request. > > The one(s) not available will have "FE_SCALE_NOT_AVAILABLE" as scale, > and its value is undefined.
We may wish to rethink this approach - it lacks the ability to specify why the data isn't available. It would probably be very useful for userland to know the difference between a statistic not being available because the hardware doesn't ever provide that data (in which case a GUI might do something like not show the option), versus it not being available temporarily due to a lack of signal lock (in which as a GUI might show the option but indicate that the data is not currently available). Likewise I would want to know that data isn't being shown due to some error condition versus it not being supported by the hardware or the data being temporarily unavailable due to a lack of signal lock. See, I've been thinking about it for two minutes, and already found three perfectly reasonable error conditions userland would probably want to differentiate between. Do we really think it's wise to make this field the equivalent of a bool? It might make sense to add something equivalent to errno for a per-stat basis. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
