On Sun, Mar 15, 2009 at 9:20 AM, wk <handygewinnsp...@gmx.de> wrote: >> 1. Getting everyone to agree on a standard representation for the >> field, and how to represent certain error conditions (such as when a >> demod doesn't support SNR, or when it cannot return a valid value at a >> given time). >> >> > > Its just straightforward as described in DVB API, chapters > 2.2.3 FE READ STATUS > 2.2.4 FE READ BER > 2.2.5 FE READ SNR > 2.2.6 FE READ SIGNAL STRENGTH > 2.2.7 FE READ UNCORRECTED BLOCKS > > if ioctl suceeds with valid data: 0, if not one of > EBADF no valid fi le descriptor. > EFAULT error condition > ENOSIGNAL not yet, i have no signal.. > ENOSYS not supported by device.
You're right, the error codes are indeed currently documented. I guess I just didn't realize that since I saw many different devices returning zero when the call was unimplemented, and returning garbage when there was no signal lock. In which case, the error codes don't need to be agreed on, they just need to be implemented across all the drivers. Of course, the bigger issue still remains to figure out what format the actual SNR should be in. >> 2. Converting all the drivers to the agreed-upon format. For some >> drivers this is relatively easy as we have specs available for how the >> SNR is represented. For others, the value displayed is entirely >> reverse engineered so the current representations are completely >> arbitrary. > > Since a lot of frontends have no proper docs, probably providing the signal > strength unit with a second ioctl could make sense here. > > a.u. arbitrary units, not exactly known or not perfectly working > dBµV comparable trough all devices, but probably not possible for all > percent technical not understandable, percent relative to what? Assumes > that there is a optimum/hard limit of 100% which is not the case. That was the very first suggestion I put out - to at least provide an ioctl indicating what unit the data was represented in, so applications would know how to show it (as opposed to trying to get every driver to unify it's return format). However, at the time the thinking was to at least get an inventory of all the different formats being used and how many drivers are impacted, and we can then assess how hard it would actually be to get them into a unified format. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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
