Em Tue, 15 Jan 2013 10:47:50 -0500 Devin Heitmueller <dheitmuel...@kernellabs.com> escreveu:
> 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), As already explained: len = 0 in this case. > 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). FE_SCALE_NOT_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. I'm not sure if we have enough bits for a per-layer error error code, but there is space for a per-stats error code. We can even extend it to the entire DVBv5 API, as there are some reserved space there. Yet, IMHO, this is overkill: userspace just needs to know if a given stats property is not supported by a driver or not available. > 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. I don't object to add it, but IMHO it is overkill for stats. Regards, Mauro -- 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
