Re: Details about DVB frontend API
Mauro Carvalho Chehab wrote: > Michael Krufky wrote: >> On Fri, Dec 4, 2009 at 3:02 PM, VDR User wrote: >>> No activity in this thread for 2 weeks now. Has there been any progress? > >> I have stated that I like Manu's proposal, but I would prefer that the >> get_property (s2api) interface were used, because it totally provides >> an interface that is sufficient for this feature. > > I've ported Manu's proposal to S2API way of handling it. It is just compiled > only. I haven't test it yet on a real driver. > > Comments? > > --- > > Add support for frontend statistics via S2API > > The current DVB V3 API to handle statistics has two issues: > - Retrieving several values can't be done atomically; > - There's no indication about scale information. > > This patch solves those two issues by adding a group of S2API > that handles the needed statistics operations. It basically ports the > proposal of Manu Abraham To S2API. > > As the original patch, both of the above issues were addressed. > > In order to demonstrate the changes on an existing driver for the new API, > I've > implemented it at the cx24123 driver. > > There are some advantages of using this approach over using the static structs > of the original proposal: > - userspace can select an arbitrary number of parameters on his get > request; > - the latency to retrieve just one parameter is lower than retrieving > several parameters. On the cx24123 example, if user wants just signal > strength, > the latency is the same as reading one register via i2c bus. If using the > original > proposal, the latency would be 6 times worse, since you would need to get 3 > properties > at the same time; > - the latency for reading all 3 parameters at the same time is equal to > the latency of the original proposal; > - if newer statistics parameters will be needed in the future, it is > just > a matter of adding additional S2API command/value pairs; > - the DVB V3 calls can be easily implemented as a call to the new > get_stats ops, > without adding extra latency time. In time: I only wrote the get callback. It could be interesting to implement also the set callback for the DTV_FE*_UNIT parameters if there are some cases where the same driver can provide a different set of units/parameters. This way, it is possible for userspace to negotiate what parameter type he wants, on such drivers. > > Thanks to Manu Abraham for his initial proposal. > Cheers, 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
Re: Details about DVB frontend API
Michael Krufky wrote:
> On Fri, Dec 4, 2009 at 3:02 PM, VDR User wrote:
>> No activity in this thread for 2 weeks now. Has there been any progress?
> I have stated that I like Manu's proposal, but I would prefer that the
> get_property (s2api) interface were used, because it totally provides
> an interface that is sufficient for this feature.
I've ported Manu's proposal to S2API way of handling it. It is just compiled
only. I haven't test it yet on a real driver.
Comments?
---
Add support for frontend statistics via S2API
The current DVB V3 API to handle statistics has two issues:
- Retrieving several values can't be done atomically;
- There's no indication about scale information.
This patch solves those two issues by adding a group of S2API
that handles the needed statistics operations. It basically ports the
proposal of Manu Abraham To S2API.
As the original patch, both of the above issues were addressed.
In order to demonstrate the changes on an existing driver for the new API, I've
implemented it at the cx24123 driver.
There are some advantages of using this approach over using the static structs
of the original proposal:
- userspace can select an arbitrary number of parameters on his get
request;
- the latency to retrieve just one parameter is lower than retrieving
several parameters. On the cx24123 example, if user wants just signal strength,
the latency is the same as reading one register via i2c bus. If using the
original
proposal, the latency would be 6 times worse, since you would need to get 3
properties
at the same time;
- the latency for reading all 3 parameters at the same time is equal to
the latency of the original proposal;
- if newer statistics parameters will be needed in the future, it is
just
a matter of adding additional S2API command/value pairs;
- the DVB V3 calls can be easily implemented as a call to the new
get_stats ops,
without adding extra latency time.
Thanks to Manu Abraham for his initial proposal.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -975,6 +975,16 @@ static struct dtv_cmds_h dtv_cmds[] = {
_DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
_DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
_DTV_CMD(DTV_HIERARCHY, 0, 0),
+
+ /* Statistics API */
+ _DTV_CMD(DTV_FE_QUALITY, 0, 0),
+ _DTV_CMD(DTV_FE_QUALITY_UNIT, 0, 0),
+ _DTV_CMD(DTV_FE_STRENGTH, 0, 0),
+ _DTV_CMD(DTV_FE_STRENGTH_UNIT, 0, 0),
+ _DTV_CMD(DTV_FE_ERROR, 0, 0),
+ _DTV_CMD(DTV_FE_ERROR_UNIT, 0, 0),
+ _DTV_CMD(DTV_FE_SIGNAL, 0, 0),
+ _DTV_CMD(DTV_FE_SIGNAL_UNIT, 0, 0),
};
static void dtv_property_dump(struct dtv_property *tvp)
@@ -1203,16 +1213,59 @@ static int dvb_frontend_ioctl_legacy(str
static int dvb_frontend_ioctl_properties(struct inode *inode, struct file
*file,
unsigned int cmd, void *parg);
+static int dtv_property_prepare_get_stats(struct dvb_frontend *fe,
+ struct dtv_property *tvp,
+ struct inode *inode, struct file *file)
+{
+ switch (tvp->cmd) {
+ case DTV_FE_QUALITY:
+ fe->dtv_property_cache.need_stats |= FE_NEED_QUALITY;
+ break;
+ case DTV_FE_QUALITY_UNIT:
+ fe->dtv_property_cache.need_stats |= FE_NEED_QUALITY_UNIT;
+ break;
+ case DTV_FE_STRENGTH:
+ fe->dtv_property_cache.need_stats |= FE_NEED_STRENGTH;
+ break;
+ case DTV_FE_STRENGTH_UNIT:
+ fe->dtv_property_cache.need_stats |= FE_NEED_STRENGTH_UNIT;
+ break;
+ case DTV_FE_ERROR:
+ fe->dtv_property_cache.need_stats |= FE_NEED_ERROR;
+ break;
+ case DTV_FE_ERROR_UNIT:
+ fe->dtv_property_cache.need_stats |= FE_NEED_ERROR_UNIT;
+ break;
+ case DTV_FE_SIGNAL:
+ fe->dtv_property_cache.need_stats |= FE_NEED_SIGNAL;
+ break;
+ case DTV_FE_SIGNAL_UNIT:
+ fe->dtv_property_cache.need_stats |= FE_NEED_SIGNAL_UNIT;
+ break;
+ case DTV_FE_UNC:
+ fe->dtv_property_cache.need_stats |= FE_NEED_SIGNAL;
+ break;
+ case DTV_FE_UNC_UNIT:
+ fe->dtv_property_cache.need_stats |= FE_NEED_SIGNAL_UNIT;
+ break;
+ default:
+ return 1;
+ };
+
+ return 0;
+}
+
static int dtv_property_process_get(struct dvb_frontend *fe,
struct dtv_property *tvp,
- struct inode *inode, struct file *file)
+ struct inode *inode, struct file *file,
+
Re: Details about DVB frontend API
Michael Krufky wrote: > On Sat, Dec 5, 2009 at 12:30 PM, Mauro Carvalho Chehab > wrote: >> Michael Krufky wrote: >>> On Fri, Dec 4, 2009 at 3:02 PM, VDR User wrote: >>> I have stated that I like Manu's proposal, but I would prefer that the >>> get_property (s2api) interface were used, because it totally provides >>> an interface that is sufficient for this feature. >>> >>> Manu and I agree that these values should all be read at once. >>> >>> I think we all (except Mauro) agree that the behavior within the >>> driver should fetch all statistics at once and return it to userspace >>> as a single structure with all the information as it all relates to >>> each other. >> You're contradicting yourself: by using S2API, the userspace API won't >> be using a single structure, since S2API will break them into pairs of >> attributes/values. > > Incorrect. Userspace would issue a get_property call and kernelspace > would return a block of key/value pairs. If userspace does a call with space for just one key/value pair, where do you expect to store the other key/value pairs? 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
Re: Details about DVB frontend API
On Sat, Dec 5, 2009 at 12:30 PM, Mauro Carvalho Chehab wrote: > Michael Krufky wrote: >> On Fri, Dec 4, 2009 at 3:02 PM, VDR User wrote: >> I have stated that I like Manu's proposal, but I would prefer that the >> get_property (s2api) interface were used, because it totally provides >> an interface that is sufficient for this feature. >> >> Manu and I agree that these values should all be read at once. >> >> I think we all (except Mauro) agree that the behavior within the >> driver should fetch all statistics at once and return it to userspace >> as a single structure with all the information as it all relates to >> each other. > > You're contradicting yourself: by using S2API, the userspace API won't > be using a single structure, since S2API will break them into pairs of > attributes/values. Incorrect. Userspace would issue a get_property call and kernelspace would return a block of key/value pairs. > Nothing limits that the in-kernel API will group those values into a struct, > but the internal API should be smart enough to not return to userspace > the values that weren't requested by the call. The call should be generic, something like get_property_signalstats ... Kernelspace should return all related information, and userspace should pick out what it needs. -Mike -- 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
Re: Details about DVB frontend API
Michael Krufky wrote: > On Fri, Dec 4, 2009 at 3:02 PM, VDR User wrote: > I have stated that I like Manu's proposal, but I would prefer that the > get_property (s2api) interface were used, because it totally provides > an interface that is sufficient for this feature. > > Manu and I agree that these values should all be read at once. > > I think we all (except Mauro) agree that the behavior within the > driver should fetch all statistics at once and return it to userspace > as a single structure with all the information as it all relates to > each other. You're contradicting yourself: by using S2API, the userspace API won't be using a single structure, since S2API will break them into pairs of attributes/values. Nothing limits that the in-kernel API will group those values into a struct, but the internal API should be smart enough to not return to userspace the values that weren't requested by the call. Cheers, 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
Re: Details about DVB frontend API
On Fri, Dec 4, 2009 at 3:02 PM, VDR User wrote: > No activity in this thread for 2 weeks now. Has there been any progress? I think I speak on behalf of most LinuxTV developers, when I say that nobody wants to spend their free personal time working on something that might get shot down with such controversy. I have stated that I like Manu's proposal, but I would prefer that the get_property (s2api) interface were used, because it totally provides an interface that is sufficient for this feature. Manu and I agree that these values should all be read at once. I think we all (except Mauro) agree that the behavior within the driver should fetch all statistics at once and return it to userspace as a single structure with all the information as it all relates to each other. Furthermore, I think we all know that we cant just remove the current structures, and we should do something to normalize the current reporting values. The longer this thread gets, the less likely anybody is to do anything about it. Let me state my opinion again: I would like to see a solution merged, and I think Manu's solution is reasonable, although it may be complicated -- if all drivers are updated to support it, then it will all be worth it. The question is, *will* all drivers update to support this? I don't know. We have the S2API's set / get property API -- In my opinion, we should use this API to fetch statistic information and have it return a single atomic structure. Applications can use only the information that they're interested in. In the meanwhile, as a SEPARATE PROJECT, we should do something to standardize the values reported by the CURRENT API across the entire subsystem. This should not be confused with Manu's initiative to create a better API -- we cant remove the current API, but it should be standardized. I volunteer to work on the standardization of the CURRENT Api, and I am all for seeing a new API introduced for better statistical reporting, provided that the get property method is used as an interface, rather than adding new ioctls. However, if we add a new API, we haev to make sure that all the current drivers are updated to support it -- do we have all the information that we need for this? Do we have the manpower and the drive to get it done? My urge to do this work is a strong urge, but I have no desire to do this if people want to continue arguing about it... In the meanwhile, I am working on new drivers for new devices, and this is *much* more interesting that worrying about how strong a signal is for a device that already works. When you folks stop talking about this, that's when I will push the trees containing all the work that I've done already thus far -- we need to standardize the current API, and that has nothing to do with Manu's proposal. We should not confuse standardization the current reporting units with the introduction of a new API -- both should be done, but the more arguing there is about it, the less of a chance that anybody will volunteer their own time to work on it. ...and just to clarify -- I think I said it twice already, but repeating again -- I (mostly) like Manu's proposal, but if we cant update the drivers to support it, then is it worth the trouble? Regards, Mike Krufky -- 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
Re: Details about DVB frontend API
No activity in this thread for 2 weeks now. Has there been any progress? Regards. -- 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
Re: Details about DVB frontend API
Manu Abraham schrieb Not only is it time critical, but it should also be "atomic", ie it should be all in one go, ie one single snapshot of an event, not events bunched together serially. Things wont seem that "atomic" on a system with a large load. Latency will have a significant effect on the statistics (values) read back, since it is again disjoint events. Right, the values should be treatened as a unique unit... Time stamping would be helpful, prior to any processing by the library such that the time overhead for the calculations is offset, but that can be really useful within the same library alone. I can't imagine how time stamping can be helpful to result a low latency. No, timestamping would of course not be helpful for reducing the latency, it would just allow to correctly interpret values if they are delayed. So that you won't assume the values you receive can be taken as proven for the current moment. If you don't have a low latency, Consider this (even when you are able to ignore the statistics for any general processing, on the thought that "i can always live with those errors and i always had"): The error fedback into the loop for a sat positioner/rotor. The final calculated position will never be the actual position that you wanted the antenna to be at a certain location. The problem would be made worser by the different rotor speeds as well, to add to the nightmare. With the V5 operation, you bunch operations together in a serial manner, it is atomic to the sense that it happens or doesn't happen, but it is not atomic to the sense of any particular time frame. You just keep your fingers crossed that the CPU executes the event in the shortest frame. This won't hold good in all cases when there is a high latency on the system when there is a significant load. eg: You can imagine an IPTV headend streaming data, with a small CPU with multiple tuners and trying to compensate the offset that's introduced. Still worser situation: imagine a gyro stabilized setup, where the base itself is not that stationary. Ok, thanks for the details about how V5 API deals with this. Indeed this is a major issue one has to think of when talking about signal statistics. Some other points to be considered: * As of now, the get/set interface is not used for any signal statistics * Even if one prefers to normalize all parameters into one single standard, even then you wouldn't land with a get/set interface. * The generic get/set interface is good when you have an unknown set of parameters, such that one can keep adding in parameters. Eg: most people favoured this approach when we had a larger set of modulations/ error correction and other parameters. For the case what we have currently, we do not have such a varied set of parameters to consider. Right, the situation about the parameters which will be requested in terms of signal statistics should not change for future frontend types, so it really should be a save approach to have a static API here. I have not yet done a very detailed look into your proposed patch, but I will do so tomorrow. I really would like to see a reliable statistics API in v4l-dvb soon. Regards, Julian -- 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
Re: Details about DVB frontend API
On Fri, Nov 20, 2009 at 3:37 PM, Julian Scheel wrote: > Am Freitag, 20. November 2009 10:29:34 schrieb Manu Abraham: >> Let me explain a bit. The current issue that persists as Devin explained in >> another email explains things to a certain extend, but still i think it >> might be better to detail further. >> >> Generally a request can be classified to 3 basic types. >> >> 1. Request to acquire, retrieve acquisition details >> 2. Get information (device state, device info) >> 3. Get information (channel statistics) >> >> >> The first one for example is a request to say tune to a channel, get tuned >> channel details, or even other frontend specific commands such as SEC >> operations. These operations are not very critical with regards on a time >> scale, just that things could be shifted all along on the time scale, the >> worser the implementation, the larger the time "taken to carry around a >> larger set of information to handle the operation". Currently, the V3.x and >> the V5 implementation handles this. The V3 implementation is small and >> fast, while the V5 implementation is "sluggish". >> >> >> The second one gets basic device information. The V3 implementation handled >> this to a certain extend, but the V5 implementation hardly handles this and >> the implementation is rather crude rather than being "sophisticated". >> >> >> The third aspect which is basically needed in most cases for debugging the >> channel properties. If all things were ideal, one wouldn't need to know the >> details on what's going on inside. So being in the far from ideal thing, >> the requisite to know what happens internally is very much a need in all >> cases. Another point to be noted is that this category of information is >> very much critical on a timescale as these parameters are valid for a very >> certain instances of time only. The more this information gets out of >> sync, the more these values are meaningless. Also another point to be >> noted is that all these values when read back together at the very same >> instance only does make sense. It is indeed very hard to achieve this very >> short timespan between each of the values being monitored. The larger the >> bandwidth associated, the larger the error introduced in the readback of >> the values within the same timeframe in between the reads. So the >> timeframe has to be the very least possible in between this operation to >> the device driver internals too.. >> >> >> Although, i have pointed out with this patch what happens at the driver >> level and at the userspace level, There needs additions to the libdvb parts >> to handle whatever conversions from format x to y. This needs to be handled >> since it might not be very easy to be handled consistsently by all >> applications. So in this concept, the application can choose the format >> conversion from the library as well, such that the application can provide >> the statistics in either the the driver native format, or a unified format >> (conversion done by the library) if the user prefers it. >> >> > 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. >> >> As i have noted above, the statistics related calls have a meaning, if and >> only if it is hanled very fast and properly with no caching. Having a >> genarlized datastructure to handle this event, breaks up the whole meaning >> of having this call itself in this position. >> >> What an API generally does is to make things generalized. When one makes >> things "the most generalized way" an overhead is also associated with it in >> terms of performance. If things were possible, i would directly read from >> memory from an application from the hardware itself for processing data in >> such a scenario, rather than to make things very generalized. This is an >> area where concepts like data caching can be ruled out completely. We are >> already at a disadvantage with the kernel driver doing a copy_to_user >> itself. Ideally, a memory mapped to userspace would have been the ideal >> thing over here. >> >> It is just the question of having yet another set of statistics calls that >> handles the information properly or not. > > Hi Manu, > > thanks for the detailed explanation of your point. Actually I am not > completely familiar with how the S2API calls are handled internally. Still are > there any proven measurements about the timeframe the calls are being executed > within? - I absolutely see that reading signal statistics is a time critical > process, at least it is important to be able to assign the data to a specific > moment so it can be interpreted in conjunction with the data which is being > received in that moment. Not only is it time critical, but it should also be "atomic", ie it should be all in one go, ie one single snap
Re: Details about DVB frontend API
Am Freitag, 20. November 2009 10:29:34 schrieb Manu Abraham: > Let me explain a bit. The current issue that persists as Devin explained in > another email explains things to a certain extend, but still i think it > might be better to detail further. > > Generally a request can be classified to 3 basic types. > > 1. Request to acquire, retrieve acquisition details > 2. Get information (device state, device info) > 3. Get information (channel statistics) > > > The first one for example is a request to say tune to a channel, get tuned > channel details, or even other frontend specific commands such as SEC > operations. These operations are not very critical with regards on a time > scale, just that things could be shifted all along on the time scale, the > worser the implementation, the larger the time "taken to carry around a > larger set of information to handle the operation". Currently, the V3.x and > the V5 implementation handles this. The V3 implementation is small and > fast, while the V5 implementation is "sluggish". > > > The second one gets basic device information. The V3 implementation handled > this to a certain extend, but the V5 implementation hardly handles this and > the implementation is rather crude rather than being "sophisticated". > > > The third aspect which is basically needed in most cases for debugging the > channel properties. If all things were ideal, one wouldn't need to know the > details on what's going on inside. So being in the far from ideal thing, > the requisite to know what happens internally is very much a need in all > cases. Another point to be noted is that this category of information is > very much critical on a timescale as these parameters are valid for a very > certain instances of time only. The more this information gets out of > sync, the more these values are meaningless. Also another point to be > noted is that all these values when read back together at the very same > instance only does make sense. It is indeed very hard to achieve this very > short timespan between each of the values being monitored. The larger the > bandwidth associated, the larger the error introduced in the readback of > the values within the same timeframe in between the reads. So the > timeframe has to be the very least possible in between this operation to > the device driver internals too.. > > > Although, i have pointed out with this patch what happens at the driver > level and at the userspace level, There needs additions to the libdvb parts > to handle whatever conversions from format x to y. This needs to be handled > since it might not be very easy to be handled consistsently by all > applications. So in this concept, the application can choose the format > conversion from the library as well, such that the application can provide > the statistics in either the the driver native format, or a unified format > (conversion done by the library) if the user prefers it. > > > 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. > > As i have noted above, the statistics related calls have a meaning, if and > only if it is hanled very fast and properly with no caching. Having a > genarlized datastructure to handle this event, breaks up the whole meaning > of having this call itself in this position. > > What an API generally does is to make things generalized. When one makes > things "the most generalized way" an overhead is also associated with it in > terms of performance. If things were possible, i would directly read from > memory from an application from the hardware itself for processing data in > such a scenario, rather than to make things very generalized. This is an > area where concepts like data caching can be ruled out completely. We are > already at a disadvantage with the kernel driver doing a copy_to_user > itself. Ideally, a memory mapped to userspace would have been the ideal > thing over here. > > It is just the question of having yet another set of statistics calls that > handles the information properly or not. Hi Manu, thanks for the detailed explanation of your point. Actually I am not completely familiar with how the S2API calls are handled internally. Still are there any proven measurements about the timeframe the calls are being executed within? - I absolutely see that reading signal statistics is a time critical process, at least it is important to be able to assign the data to a specific moment so it can be interpreted in conjunction with the data which is being received in that moment. If this would be the only point where the delay is important one might be able to overcome this by adding timestamps into the retrieved data, although I am not sure if this would be feasible at all. Anyway having a very good and low- delay
Re: Details about DVB frontend API
On Tue, Nov 17, 2009 at 11:46 PM, Mauro Carvalho Chehab
wrote:
>
> Manu Abraham escreveu:
> > On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
> > wrote:
> >> Em Thu, 22 Oct 2009 21:13:30 +0200
> >> Jean Delvare escreveu:
> >>
> >>> Hi folks,
> >>>
> >>> I am looking for details regarding the DVB frontend API. I've read
> >>> linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
> >>> FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
> >>> commands return, however it does not give any information about how the
> >>> returned values should be interpreted (or, seen from the other end, how
> >>> the frontend kernel drivers should encode these values.) If there
> >>> documentation available that would explain this?
> >>>
> >>> For example, the signal strength. All I know so far is that this is a
> >>> 16-bit value. But then what? Do greater values represent stronger
> >>> signal or weaker signal? Are 0x and 0x special values? Is the
> >>> returned value meaningful even when FE_HAS_SIGNAL is 0? When
> >>> FE_HAS_LOCK is 0? Is the scale linear, or do some values have
> >>> well-defined meanings, or is it arbitrary and each driver can have its
> >>> own scale? What are the typical use cases by user-space application for
> >>> this value?
> >>>
> >>> That's the kind of details I'd like to know, not only for the signal
> >>> strength, but also for the SNR, BER and UB. Without this information,
> >>> it seems a little difficult to have consistent frontend drivers.
> >> We all want to know about that ;)
> >>
> >> Seriously, the lack of a description of the meaning of the ranges for those
> >> read values were already widely discussed at LMML and at the legacy dvb ML.
> >> We should return this discussion again and decide what would be the better
> >> way to describe those values.
> >>
> >> My suggestion is that someone summarize the proposals we had and give some
> >> time
> >> for people vote. After that, we just commit the most voted one, and commit
> >> the
> >> patches for it. A pending question that should also be discussed is what
> >> we will
> >> do with those dvb devices where we simply don't know what scale it uses.
> >> There
> >> are several of them.
> >
> >
> > Sometime back, (some time in April) i proposed a patch which addressed
> > the issue to scale "even those devices which have a weird scale or
> > none". Though based on an older tree of mine, here is the patch again.
> > If it looks good enough, i can port the patch to accomodate other
> > devices as well.
> >
> >
> > Regards,
> > Manu
> >
>
> Manu,
>
> Sorry for not answering earlier. Due to my travels, I had a very big backlog
> here
> to handle.
>
> I prefer a solution like you've proposed of creating a new set of API calls
> for
> it, instead of re-defining the current calls.
I have been unable to respond earlier on this, being out of station.
Sorry, my previous mail failed to reach the Mailing list due to HTML
part being existant. Hopefully it is fixed this time.
> Yet, I have a few comments:
>
> 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
Re: Details about DVB frontend API
On Wed, Nov 18, 2009 at 9:04 AM, Mauro Carvalho Chehab
wrote:
> Devin Heitmueller wrote:
>> On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
>> wrote:
>>> We shouldn't write API's thinking on some specific use case or aplication.
>>> If there's a problem with zap, the fix should be there, not at the kernel.
>>
>> Your response suggests I must have poorly described the problem. Zap
>> is just one example where having an "inconsistent" view of the various
>> performance counters is easily visible. If you're trying to write
>> something like an application to control antenna orientation, the fact
>> that you cannot ask for a single view of all counters can be a real
>> problem. Having to make separate ioctl calls for each field can cause
>> real problems here.
>>
>> I disagree strongly with your assertion that we should not considering
>> specific use cases when writing an API.
>
> That's not what I've said (or maybe I haven't said it clear enough).
> I'm saying that we shouldn't look for one particular use case only.
> In other words, the API should cover all use cases that makes sense.
>
>>In this case, Manu's
>> approach provides the ability to get a single consistent view of all
>> the counters (for those drivers which can support it)
>
> No. To get all counters, you'll need to call 3 ioctls. The status were
> grouped around 3 groups of counters on his proposal. I'm sure Manu has some
> explanation why he thinks that 3 is better then 2 or 4 calls, but the point
> is: should we really group them on a fixed way?
>
> Btw, by using S2API, we'll break it into different commands. Yet, we can
> call all of them at once, if needed, as the API defines it as:
>
> struct dtv_property {
> __u32 cmd;
> __u32 reserved[3];
> union {
> __u32 data;
> struct {
> __u8 data[32];
> __u32 len;
> __u32 reserved1[3];
> void *reserved2;
> } buffer;
> } u;
> int result;
> } __attribute__ ((packed));
>
> struct dtv_properties {
> __u32 num;
> struct dtv_property *props;
> };
>
> #define FE_SET_PROPERTY _IOW('o', 82, struct dtv_properties)
> #define FE_GET_PROPERTY _IOR('o', 83, struct dtv_properties)
>
> So, all needed commands can be grouped together to provide an atomic read.
>
>>> Also, the above mentioned problem can happen even if there's just one API
>>> call from userspace to kernel or if the driver needs to do separate,
>>> serialized calls to firmware (or a serialized calculus) to get the
>>> three measures.
>>
>> True, the accuracy in which a given driver can provide accurate data
>> is tied to the quality of the hardware implementation. However, for
>> well engineered hardware, Manu's proposed API affords the ability to
>> accurately report a consistent view of the information. The existing
>> implementation restricts all drivers to working as well as the
>> worst-case hardware implementation.
>
> Imagining that some application will need to retrieve all quality indicators
> at the same time, as they were grouped into 3 groups, even on a perfect
> hardware, you won't be able to get all of them at the sime time,
> since you'll need to call 3 ioctls.
>
For what it's worth, we have solved this problem in hwmon driver the
following way: we cache related values (read from the same register or
set of registers) for ~1 second. When user-space requests the
information, if the cache is fresh it is used, otherwise the cache is
first refreshed. That way we ensure that data returned to nearby
user-space calls are taken from the same original register value. One
advantage is that we thus did not have to map the API to the hardware
register constraints and thus have the guarantee that all hardware
designs fit.
I don't know if a similar logic would help for DVB.
>>> This could be an alternative, if implemented at the right way. However,
>>> I suspect that it would be better to do such things at libdvb.
>>>
>>> For example, caching measures for 1 second may be too much, if userspace is
>>> doing a scan, while, when streaming, this timeout can be fine.
>>
>> Jean's caching approach for hwmon is fine for something like the
>> chassis temperature, which doesn't change that rapidly. However, it's
>> probably not appropriate for things like SNR and strength counters,
>> where near real-time feedback can be useful in things like controlling
>> a rotor.
>
> I agree.
>
> Yet, you won't have this feedback in real-time, since calculating
> QoS indicators require some time. So, after moving the rotor, you'll need
> to wait for some time, in order to allow the frontend to recalculate the
> QoS after the movement. There's a problem here, not addressed by none of
> the proposals: when the QoS indicators will reflect the rotor movement?
>
> If you just read the QoS indicator in a
Re: Details about DVB frontend API
On Wed, Nov 18, 2009 at 10:17 AM, Devin Heitmueller
wrote:
> On Wed, Nov 18, 2009 at 9:04 AM, Mauro Carvalho Chehab
> wrote:
>> Devin Heitmueller wrote:
>>> On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
>>> wrote:
We shouldn't write API's thinking on some specific use case or aplication.
If there's a problem with zap, the fix should be there, not at the kernel.
>>>
>>> Your response suggests I must have poorly described the problem. Zap
>>> is just one example where having an "inconsistent" view of the various
>>> performance counters is easily visible. If you're trying to write
>>> something like an application to control antenna orientation, the fact
>>> that you cannot ask for a single view of all counters can be a real
>>> problem. Having to make separate ioctl calls for each field can cause
>>> real problems here.
>>>
>>> I disagree strongly with your assertion that we should not considering
>>> specific use cases when writing an API.
>>
>> That's not what I've said (or maybe I haven't said it clear enough).
>> I'm saying that we shouldn't look for one particular use case only.
>> In other words, the API should cover all use cases that makes sense.
>>
>>>In this case, Manu's
>>> approach provides the ability to get a single consistent view of all
>>> the counters (for those drivers which can support it)
>>
>> No. To get all counters, you'll need to call 3 ioctls. The status were
>> grouped around 3 groups of counters on his proposal. I'm sure Manu has some
>> explanation why he thinks that 3 is better then 2 or 4 calls, but the point
>> is: should we really group them on a fixed way?
>>
>> Btw, by using S2API, we'll break it into different commands. Yet, we can
>> call all of them at once, if needed, as the API defines it as:
>>
>> struct dtv_property {
>> __u32 cmd;
>> __u32 reserved[3];
>> union {
>> __u32 data;
>> struct {
>> __u8 data[32];
>> __u32 len;
>> __u32 reserved1[3];
>> void *reserved2;
>> } buffer;
>> } u;
>> int result;
>> } __attribute__ ((packed));
>>
>> struct dtv_properties {
>> __u32 num;
>> struct dtv_property *props;
>> };
>>
>> #define FE_SET_PROPERTY _IOW('o', 82, struct dtv_properties)
>> #define FE_GET_PROPERTY _IOR('o', 83, struct dtv_properties)
>>
>> So, all needed commands can be grouped together to provide an atomic read.
>>
Also, the above mentioned problem can happen even if there's just one API
call from userspace to kernel or if the driver needs to do separate,
serialized calls to firmware (or a serialized calculus) to get the
three measures.
>>>
>>> True, the accuracy in which a given driver can provide accurate data
>>> is tied to the quality of the hardware implementation. However, for
>>> well engineered hardware, Manu's proposed API affords the ability to
>>> accurately report a consistent view of the information. The existing
>>> implementation restricts all drivers to working as well as the
>>> worst-case hardware implementation.
>>
>> Imagining that some application will need to retrieve all quality indicators
>> at the same time, as they were grouped into 3 groups, even on a perfect
>> hardware, you won't be able to get all of them at the sime time,
>> since you'll need to call 3 ioctls.
>>
> For what it's worth, we have solved this problem in hwmon driver the
> following way: we cache related values (read from the same register or
> set of registers) for ~1 second. When user-space requests the
> information, if the cache is fresh it is used, otherwise the cache is
> first refreshed. That way we ensure that data returned to nearby
> user-space calls are taken from the same original register value. One
> advantage is that we thus did not have to map the API to the hardware
> register constraints and thus have the guarantee that all hardware
> designs fit.
>
> I don't know if a similar logic would help for DVB.
This could be an alternative, if implemented at the right way. However,
I suspect that it would be better to do such things at libdvb.
For example, caching measures for 1 second may be too much, if userspace is
doing a scan, while, when streaming, this timeout can be fine.
>>>
>>> Jean's caching approach for hwmon is fine for something like the
>>> chassis temperature, which doesn't change that rapidly. However, it's
>>> probably not appropriate for things like SNR and strength counters,
>>> where near real-time feedback can be useful in things like controlling
>>> a rotor.
>>
>> I agree.
>>
>> Yet, you won't have this feedback in real-time, since calculating
>> QoS indicators require some time. So, after moving the rotor, you'll need
>> to wait for some time, in order to allow the frontend to recalculate the
>> QoS after the movement
Re: Details about DVB frontend API
On Wed, Nov 18, 2009 at 9:04 AM, Mauro Carvalho Chehab
wrote:
> Devin Heitmueller wrote:
>> On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
>> wrote:
>>> We shouldn't write API's thinking on some specific use case or aplication.
>>> If there's a problem with zap, the fix should be there, not at the kernel.
>>
>> Your response suggests I must have poorly described the problem. Zap
>> is just one example where having an "inconsistent" view of the various
>> performance counters is easily visible. If you're trying to write
>> something like an application to control antenna orientation, the fact
>> that you cannot ask for a single view of all counters can be a real
>> problem. Having to make separate ioctl calls for each field can cause
>> real problems here.
>>
>> I disagree strongly with your assertion that we should not considering
>> specific use cases when writing an API.
>
> That's not what I've said (or maybe I haven't said it clear enough).
> I'm saying that we shouldn't look for one particular use case only.
> In other words, the API should cover all use cases that makes sense.
>
>>In this case, Manu's
>> approach provides the ability to get a single consistent view of all
>> the counters (for those drivers which can support it)
>
> No. To get all counters, you'll need to call 3 ioctls. The status were
> grouped around 3 groups of counters on his proposal. I'm sure Manu has some
> explanation why he thinks that 3 is better then 2 or 4 calls, but the point
> is: should we really group them on a fixed way?
>
> Btw, by using S2API, we'll break it into different commands. Yet, we can
> call all of them at once, if needed, as the API defines it as:
>
> struct dtv_property {
> __u32 cmd;
> __u32 reserved[3];
> union {
> __u32 data;
> struct {
> __u8 data[32];
> __u32 len;
> __u32 reserved1[3];
> void *reserved2;
> } buffer;
> } u;
> int result;
> } __attribute__ ((packed));
>
> struct dtv_properties {
> __u32 num;
> struct dtv_property *props;
> };
>
> #define FE_SET_PROPERTY _IOW('o', 82, struct dtv_properties)
> #define FE_GET_PROPERTY _IOR('o', 83, struct dtv_properties)
>
> So, all needed commands can be grouped together to provide an atomic read.
>
>>> Also, the above mentioned problem can happen even if there's just one API
>>> call from userspace to kernel or if the driver needs to do separate,
>>> serialized calls to firmware (or a serialized calculus) to get the
>>> three measures.
>>
>> True, the accuracy in which a given driver can provide accurate data
>> is tied to the quality of the hardware implementation. However, for
>> well engineered hardware, Manu's proposed API affords the ability to
>> accurately report a consistent view of the information. The existing
>> implementation restricts all drivers to working as well as the
>> worst-case hardware implementation.
>
> Imagining that some application will need to retrieve all quality indicators
> at the same time, as they were grouped into 3 groups, even on a perfect
> hardware, you won't be able to get all of them at the sime time,
> since you'll need to call 3 ioctls.
>
For what it's worth, we have solved this problem in hwmon driver the
following way: we cache related values (read from the same register or
set of registers) for ~1 second. When user-space requests the
information, if the cache is fresh it is used, otherwise the cache is
first refreshed. That way we ensure that data returned to nearby
user-space calls are taken from the same original register value. One
advantage is that we thus did not have to map the API to the hardware
register constraints and thus have the guarantee that all hardware
designs fit.
I don't know if a similar logic would help for DVB.
>>> This could be an alternative, if implemented at the right way. However,
>>> I suspect that it would be better to do such things at libdvb.
>>>
>>> For example, caching measures for 1 second may be too much, if userspace is
>>> doing a scan, while, when streaming, this timeout can be fine.
>>
>> Jean's caching approach for hwmon is fine for something like the
>> chassis temperature, which doesn't change that rapidly. However, it's
>> probably not appropriate for things like SNR and strength counters,
>> where near real-time feedback can be useful in things like controlling
>> a rotor.
>
> I agree.
>
> Yet, you won't have this feedback in real-time, since calculating
> QoS indicators require some time. So, after moving the rotor, you'll need
> to wait for some time, in order to allow the frontend to recalculate the
> QoS after the movement. There's a problem here, not addressed by none of
> the proposals: when the QoS indicators will reflect the rotor movement?
>
> If you just read the QoS indicator in a
Re: Details about DVB frontend API
Devin Heitmueller wrote:
> On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
> wrote:
>> We shouldn't write API's thinking on some specific use case or aplication.
>> If there's a problem with zap, the fix should be there, not at the kernel.
>
> Your response suggests I must have poorly described the problem. Zap
> is just one example where having an "inconsistent" view of the various
> performance counters is easily visible. If you're trying to write
> something like an application to control antenna orientation, the fact
> that you cannot ask for a single view of all counters can be a real
> problem. Having to make separate ioctl calls for each field can cause
> real problems here.
>
> I disagree strongly with your assertion that we should not considering
> specific use cases when writing an API.
That's not what I've said (or maybe I haven't said it clear enough).
I'm saying that we shouldn't look for one particular use case only.
In other words, the API should cover all use cases that makes sense.
>In this case, Manu's
> approach provides the ability to get a single consistent view of all
> the counters (for those drivers which can support it)
No. To get all counters, you'll need to call 3 ioctls. The status were
grouped around 3 groups of counters on his proposal. I'm sure Manu has some
explanation why he thinks that 3 is better then 2 or 4 calls, but the point
is: should we really group them on a fixed way?
Btw, by using S2API, we'll break it into different commands. Yet, we can
call all of them at once, if needed, as the API defines it as:
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
__u8 data[32];
__u32 len;
__u32 reserved1[3];
void *reserved2;
} buffer;
} u;
int result;
} __attribute__ ((packed));
struct dtv_properties {
__u32 num;
struct dtv_property *props;
};
#define FE_SET_PROPERTY_IOW('o', 82, struct dtv_properties)
#define FE_GET_PROPERTY_IOR('o', 83, struct dtv_properties)
So, all needed commands can be grouped together to provide an atomic read.
>> Also, the above mentioned problem can happen even if there's just one API
>> call from userspace to kernel or if the driver needs to do separate,
>> serialized calls to firmware (or a serialized calculus) to get the
>> three measures.
>
> True, the accuracy in which a given driver can provide accurate data
> is tied to the quality of the hardware implementation. However, for
> well engineered hardware, Manu's proposed API affords the ability to
> accurately report a consistent view of the information. The existing
> implementation restricts all drivers to working as well as the
> worst-case hardware implementation.
Imagining that some application will need to retrieve all quality indicators
at the same time, as they were grouped into 3 groups, even on a perfect
hardware, you won't be able to get all of them at the sime time,
since you'll need to call 3 ioctls.
>>> For what it's worth, we have solved this problem in hwmon driver the
>>> following way: we cache related values (read from the same register or
>>> set of registers) for ~1 second. When user-space requests the
>>> information, if the cache is fresh it is used, otherwise the cache is
>>> first refreshed. That way we ensure that data returned to nearby
>>> user-space calls are taken from the same original register value. One
>>> advantage is that we thus did not have to map the API to the hardware
>>> register constraints and thus have the guarantee that all hardware
>>> designs fit.
>>>
>>> I don't know if a similar logic would help for DVB.
>> This could be an alternative, if implemented at the right way. However,
>> I suspect that it would be better to do such things at libdvb.
>>
>> For example, caching measures for 1 second may be too much, if userspace is
>> doing a scan, while, when streaming, this timeout can be fine.
>
> Jean's caching approach for hwmon is fine for something like the
> chassis temperature, which doesn't change that rapidly. However, it's
> probably not appropriate for things like SNR and strength counters,
> where near real-time feedback can be useful in things like controlling
> a rotor.
I agree.
Yet, you won't have this feedback in real-time, since calculating
QoS indicators require some time. So, after moving the rotor, you'll need
to wait for some time, in order to allow the frontend to recalculate the
QoS after the movement. There's a problem here, not addressed by none of
the proposals: when the QoS indicators will reflect the rotor movement?
If you just read the QoS indicator in a register, you're likely getting a
cached value from the last time the hardware did the calculus.
So, if you really need to know the QoS value after changing the antenna
position, you'll nee
Re: Details about DVB frontend API
On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab wrote: > We shouldn't write API's thinking on some specific use case or aplication. > If there's a problem with zap, the fix should be there, not at the kernel. Your response suggests I must have poorly described the problem. Zap is just one example where having an "inconsistent" view of the various performance counters is easily visible. If you're trying to write something like an application to control antenna orientation, the fact that you cannot ask for a single view of all counters can be a real problem. Having to make separate ioctl calls for each field can cause real problems here. I disagree strongly with your assertion that we should not considering specific use cases when writing an API. That's *EXACTLY* what you want to do - when designing an API, you should be asking yourself what use cases is it actually going to be used for, and strive to build an API that accommodates all the use cases. In this case, Manu's approach provides the ability to get a single consistent view of all the counters (for those drivers which can support it), which solves a specific use case that cannot be accomplished with the existing API. Building abstract APIs without considering all use cases is how we end up with APIs that nobody uses because they don't actually work in the real world. The fact that the existing SNR and strength counters never had their format explicitly defined is a really good example of how nobody must have considered how applications would be expected to actually use the API and represent the information to users in a useful manner. On the other hand, this issue has been beaten to death so badly and the existing API has been broken/useless for so long that I have lowered my expectations to the point where I would accept just about *any* proposal that actually provides a uniform representation of SNR across drivers. (/rant mode off) > Also, the above mentioned problem can happen even if there's just one API > call from userspace to kernel or if the driver needs to do separate, > serialized calls to firmware (or a serialized calculus) to get the > three measures. True, the accuracy in which a given driver can provide accurate data is tied to the quality of the hardware implementation. However, for well engineered hardware, Manu's proposed API affords the ability to accurately report a consistent view of the information. The existing implementation restricts all drivers to working as well as the worst-case hardware implementation. >> For what it's worth, we have solved this problem in hwmon driver the >> following way: we cache related values (read from the same register or >> set of registers) for ~1 second. When user-space requests the >> information, if the cache is fresh it is used, otherwise the cache is >> first refreshed. That way we ensure that data returned to nearby >> user-space calls are taken from the same original register value. One >> advantage is that we thus did not have to map the API to the hardware >> register constraints and thus have the guarantee that all hardware >> designs fit. >> >> I don't know if a similar logic would help for DVB. > > This could be an alternative, if implemented at the right way. However, > I suspect that it would be better to do such things at libdvb. > > For example, caching measures for 1 second may be too much, if userspace is > doing a scan, while, when streaming, this timeout can be fine. Jean's caching approach for hwmon is fine for something like the chassis temperature, which doesn't change that rapidly. However, it's probably not appropriate for things like SNR and strength counters, where near real-time feedback can be useful in things like controlling a rotor. One more point worth noting - the approach of returning all the counters in one ioctl can actually be cheaper in terms of the number of register read operations. I've seen a number of drivers where we hit the same register three or four times, since all of various fields are based on the same register. Having a single call actually allows all the duplicate register reads to be eliminated in those cases, the driver reads the register once and then populates all the fields in one shot based on the result. I was actually against Manu's proposal the last time it was put out there, as I felt just normalizing the existing API would be *good enough* for the vast majority of applications. However, if we have decided to give up on the existing API entirely and write a whole new API, we might as well do it right this time and build an API that satisfies all the people who plan to make use of it. 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
Re: Details about DVB frontend API
Devin Heitmueller escreveu: > On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab > wrote: >> 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). > > There is some value in providing grouping the results in a single > request - in many cases the data is based off of the same internal > registers, and Manu's proposed approach allows for a more "atomic" > response. The fact that we currently do the status, SNR, strength, > and UNC/BER in separate calls is one reason that people sometimes see > inconsistent results in the output of tools like zap. As an example, > they can see lines in the zap output where the lock is lost but SNR > appears fine. > > In the case where the driver servicing the query needs to do three > calls, it could be slightly more expensive, but only if we believe > that it is commonplace to ask for a subset of the stats. We shouldn't write API's thinking on some specific use case or aplication. If there's a problem with zap, the fix should be there, not at the kernel. Also, the above mentioned problem can happen even if there's just one API call from userspace to kernel or if the driver needs to do separate, serialized calls to firmware (or a serialized calculus) to get the three measures. > For what it's worth, we have solved this problem in hwmon driver the > following way: we cache related values (read from the same register or > set of registers) for ~1 second. When user-space requests the > information, if the cache is fresh it is used, otherwise the cache is > first refreshed. That way we ensure that data returned to nearby > user-space calls are taken from the same original register value. One > advantage is that we thus did not have to map the API to the hardware > register constraints and thus have the guarantee that all hardware > designs fit. > > I don't know if a similar logic would help for DVB. This could be an alternative, if implemented at the right way. However, I suspect that it would be better to do such things at libdvb. For example, caching measures for 1 second may be too much, if userspace is doing a scan, while, when streaming, this timeout can be fine. Cheers, 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
Re: Details about DVB frontend API
On Tue, 17 Nov 2009 14:55:51 -0500, Devin Heitmueller wrote: > On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab > wrote: > > 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). > > There is some value in providing grouping the results in a single > request - in many cases the data is based off of the same internal > registers, and Manu's proposed approach allows for a more "atomic" > response. The fact that we currently do the status, SNR, strength, > and UNC/BER in separate calls is one reason that people sometimes see > inconsistent results in the output of tools like zap. As an example, > they can see lines in the zap output where the lock is lost but SNR > appears fine. > > In the case where the driver servicing the query needs to do three > calls, it could be slightly more expensive, but only if we believe > that it is commonplace to ask for a subset of the stats. For what it's worth, we have solved this problem in hwmon driver the following way: we cache related values (read from the same register or set of registers) for ~1 second. When user-space requests the information, if the cache is fresh it is used, otherwise the cache is first refreshed. That way we ensure that data returned to nearby user-space calls are taken from the same original register value. One advantage is that we thus did not have to map the API to the hardware register constraints and thus have the guarantee that all hardware designs fit. I don't know if a similar logic would help for DVB. -- Jean Delvare -- 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
Re: Details about DVB frontend API
On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab wrote: > 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). There is some value in providing grouping the results in a single request - in many cases the data is based off of the same internal registers, and Manu's proposed approach allows for a more "atomic" response. The fact that we currently do the status, SNR, strength, and UNC/BER in separate calls is one reason that people sometimes see inconsistent results in the output of tools like zap. As an example, they can see lines in the zap output where the lock is lost but SNR appears fine. In the case where the driver servicing the query needs to do three calls, it could be slightly more expensive, but only if we believe that it is commonplace to ask for a subset of the stats. 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
Re: Details about DVB frontend API
Manu Abraham escreveu:
> On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
> wrote:
>> Em Thu, 22 Oct 2009 21:13:30 +0200
>> Jean Delvare escreveu:
>>
>>> Hi folks,
>>>
>>> I am looking for details regarding the DVB frontend API. I've read
>>> linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
>>> FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
>>> commands return, however it does not give any information about how the
>>> returned values should be interpreted (or, seen from the other end, how
>>> the frontend kernel drivers should encode these values.) If there
>>> documentation available that would explain this?
>>>
>>> For example, the signal strength. All I know so far is that this is a
>>> 16-bit value. But then what? Do greater values represent stronger
>>> signal or weaker signal? Are 0x and 0x special values? Is the
>>> returned value meaningful even when FE_HAS_SIGNAL is 0? When
>>> FE_HAS_LOCK is 0? Is the scale linear, or do some values have
>>> well-defined meanings, or is it arbitrary and each driver can have its
>>> own scale? What are the typical use cases by user-space application for
>>> this value?
>>>
>>> That's the kind of details I'd like to know, not only for the signal
>>> strength, but also for the SNR, BER and UB. Without this information,
>>> it seems a little difficult to have consistent frontend drivers.
>> We all want to know about that ;)
>>
>> Seriously, the lack of a description of the meaning of the ranges for those
>> read values were already widely discussed at LMML and at the legacy dvb ML.
>> We should return this discussion again and decide what would be the better
>> way to describe those values.
>>
>> My suggestion is that someone summarize the proposals we had and give some
>> time
>> for people vote. After that, we just commit the most voted one, and commit
>> the
>> patches for it. A pending question that should also be discussed is what we
>> will
>> do with those dvb devices where we simply don't know what scale it uses.
>> There
>> are several of them.
>
>
> Sometime back, (some time in April) i proposed a patch which addressed
> the issue to scale "even those devices which have a weird scale or
> none". Though based on an older tree of mine, here is the patch again.
> If it looks good enough, i can port the patch to accomodate other
> devices as well.
>
>
> Regards,
> Manu
>
Manu,
Sorry for not answering earlier. Due to my travels, I had a very big backlog
here
to handle.
I prefer a solution like you've proposed of creating a new set of API calls for
it, instead of re-defining the current calls.
Yet, I have a few comments:
diff -r b5505a985f24 linux/include/linux/dvb/frontend.h
--- a/linux/include/linux/dvb/frontend.hSat Feb 21 01:12:09 2009 +0400
+++ b/linux/include/linux/dvb/frontend.hTue 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 {
+
Re: Details about DVB frontend API
Jean Delvare wrote: Hi folks, I am looking for details regarding the DVB frontend API. I've read linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS commands return, however it does not give any information about how the returned values should be interpreted (or, seen from the other end, how the frontend kernel drivers should encode these values.) If there documentation available that would explain this? For example, the signal strength. All I know so far is that this is a 16-bit value. But then what? Do greater values represent stronger signal or weaker signal? Are 0x and 0x special values? Is the returned value meaningful even when FE_HAS_SIGNAL is 0? When FE_HAS_LOCK is 0? Is the scale linear, or do some values have well-defined meanings, or is it arbitrary and each driver can have its own scale? What are the typical use cases by user-space application for this value? That's the kind of details I'd like to know, not only for the signal strength, but also for the SNR, BER and UB. Without this information, it seems a little difficult to have consistent frontend drivers. Thanks, Hi all, I am a bit late in this discussion. I just want to raise out a problem of the current architecture of FE + tuner. Indeed, the actual "Signal Strength" can only be get from tuner. Tuner has amplifier internally and AGC. So demod can never know the accurate signal strength. Demod only roughly knows signal-to-noise ratio. Correct me if I am wrong that I found FE == Demod in current code. Thus, asking FE to report the signal strength is not appropriate. To achieve reporting actual signal strength, in commercial proprietary code, it is a combination of readings from tuner + demod. Which in turn, should sit in card/dongle specific code. Regards, David T.L. Wong -- 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
Re: Details about DVB frontend API
On Fri, Oct 23, 2009 at 9:02 PM, VDR User wrote: > On Thu, Oct 22, 2009 at 1:29 PM, Manu Abraham wrote: >> Sometime back, (some time in April) i proposed a patch which addressed >> the issue to scale "even those devices which have a weird scale or >> none". Though based on an older tree of mine, here is the patch again. >> If it looks good enough, i can port the patch to accomodate other >> devices as well. > > Thanks for posting your patch. How about people get some discussion > going about the pros/cons instead of ignoring it? The best method for > the most devices needs to be the deciding factor here, not > accepting/disregarding based on who "your" friends are. For once it > would be nice if the childish politics could get throw out and what's > best for v4l be the highest priority. > > And a thanks to anyone else that would like to submit a recommendation > on how to deal with this. Hopefully there will be a few "solid" > proposals to consider. > it would be good to have a table what statistics can be returned, obviously the API implementation doesn't matter so much. Manu, Mike can you start a wiki site on linuxtv.org addressing this topic? Please work out a proper API definition first, afterwards think about the implementation. The correct implementation in the enduser applications is by far more important. Best Regards, Markus -- 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
Re: Details about DVB frontend API
On Thu, Oct 22, 2009 at 1:29 PM, Manu Abraham wrote: > Sometime back, (some time in April) i proposed a patch which addressed > the issue to scale "even those devices which have a weird scale or > none". Though based on an older tree of mine, here is the patch again. > If it looks good enough, i can port the patch to accomodate other > devices as well. Thanks for posting your patch. How about people get some discussion going about the pros/cons instead of ignoring it? The best method for the most devices needs to be the deciding factor here, not accepting/disregarding based on who "your" friends are. For once it would be nice if the childish politics could get throw out and what's best for v4l be the highest priority. And a thanks to anyone else that would like to submit a recommendation on how to deal with this. Hopefully there will be a few "solid" proposals to consider. Regards. -- 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
Re: Details about DVB frontend API
On Fri, Oct 23, 2009 at 11:47 AM, Jean Delvare wrote: > On Thu, 22 Oct 2009 21:13:30 +0200, Jean Delvare wrote: >> For example, the signal strength. All I know so far is that this is a >> 16-bit value. But then what? Do greater values represent stronger >> signal or weaker signal? Are 0x and 0x special values? Is the >> returned value meaningful even when FE_HAS_SIGNAL is 0? When >> FE_HAS_LOCK is 0? Is the scale linear, or do some values have >> well-defined meanings, or is it arbitrary and each driver can have its >> own scale? What are the typical use cases by user-space application for >> this value? > > To close the chapter on signal strength... I understand now that we > don't have strict rules about the exact values. But do we have at least > a common agreement that greater values mean stronger signal? I am > asking because the DVB-T adapter model I have here behaves very > strangely in this respect. I get values of: > * 0x when there's no signal at all > * 0x2828 to 0x2e2e when signal is OK > * greater values as signal weakens (I have an amplified antenna with > manual gain control) up to 0x7272 > > I would have expected it the other way around: 0x for no signal and > greater values as signal strengthens. I think the frontend driver > (cx22702) needs to be fixed. > > -- > Jean Delvare > -- > 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 > I have a solution for this across the entire DVB subsystem, but I haven't had time to write up a formal explanation. I will follow up with better info when I have time. Regards, Mike Krufky -- 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
Re: Details about DVB frontend API
On Thu, 22 Oct 2009 21:13:30 +0200, Jean Delvare wrote: > For example, the signal strength. All I know so far is that this is a > 16-bit value. But then what? Do greater values represent stronger > signal or weaker signal? Are 0x and 0x special values? Is the > returned value meaningful even when FE_HAS_SIGNAL is 0? When > FE_HAS_LOCK is 0? Is the scale linear, or do some values have > well-defined meanings, or is it arbitrary and each driver can have its > own scale? What are the typical use cases by user-space application for > this value? To close the chapter on signal strength... I understand now that we don't have strict rules about the exact values. But do we have at least a common agreement that greater values mean stronger signal? I am asking because the DVB-T adapter model I have here behaves very strangely in this respect. I get values of: * 0x when there's no signal at all * 0x2828 to 0x2e2e when signal is OK * greater values as signal weakens (I have an amplified antenna with manual gain control) up to 0x7272 I would have expected it the other way around: 0x for no signal and greater values as signal strengthens. I think the frontend driver (cx22702) needs to be fixed. -- Jean Delvare -- 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
Re: Details about DVB frontend API
On Fri, 23 Oct 2009 05:10:25 +0900, Mauro Carvalho Chehab wrote: > Em Thu, 22 Oct 2009 21:13:30 +0200 > Jean Delvare escreveu: > > > Hi folks, > > > > I am looking for details regarding the DVB frontend API. I've read > > linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, > > FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS > > commands return, however it does not give any information about how the > > returned values should be interpreted (or, seen from the other end, how > > the frontend kernel drivers should encode these values.) If there > > documentation available that would explain this? > > > > For example, the signal strength. All I know so far is that this is a > > 16-bit value. But then what? Do greater values represent stronger > > signal or weaker signal? Are 0x and 0x special values? Is the > > returned value meaningful even when FE_HAS_SIGNAL is 0? When > > FE_HAS_LOCK is 0? Is the scale linear, or do some values have > > well-defined meanings, or is it arbitrary and each driver can have its > > own scale? What are the typical use cases by user-space application for > > this value? > > > > That's the kind of details I'd like to know, not only for the signal > > strength, but also for the SNR, BER and UB. Without this information, > > it seems a little difficult to have consistent frontend drivers. > > We all want to know about that ;) > > Seriously, the lack of a description of the meaning of the ranges for those > read values were already widely discussed at LMML and at the legacy dvb ML. > We should return this discussion again and decide what would be the better > way to describe those values. > > My suggestion is that someone summarize the proposals we had and give some > time > for people vote. After that, we just commit the most voted one, and commit the > patches for it. A pending question that should also be discussed is what we > will > do with those dvb devices where we simply don't know what scale it uses. There > are several of them. > > Btw, the new official documentation is the media infrastructure docbook that > can be found at the Kernel and at: > http://linuxtv.org/downloads/v4l-dvb-apis > > This covers both DVB and V4L API's. Ah, thank you. So I was reading old documentation. Too bad that googling for "linux dvb api" points to the old documents. Maybe the new document needs some more keywords so that search engines index it properly? Also, on http://linuxtv.org/docs.php, I can see links to http://linuxtv.org/downloads/linux-dvb-api-1.0.0.pdf for DVB and http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec-single/v4l2.html for V4L... but no link to http://linuxtv.org/downloads/v4l-dvb-apis . Shouldn't the links be updated? -- Jean Delvare -- 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
Re: Details about DVB frontend API
Hi Devin, On Thu, 22 Oct 2009 15:27:20 -0400, Devin Heitmueller wrote: > On Thu, Oct 22, 2009 at 3:13 PM, Jean Delvare wrote: > > Hi folks, > > > > I am looking for details regarding the DVB frontend API. I've read > > linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, > > FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS > > commands return, however it does not give any information about how the > > returned values should be interpreted (or, seen from the other end, how > > the frontend kernel drivers should encode these values.) If there > > documentation available that would explain this? > > > > For example, the signal strength. All I know so far is that this is a > > 16-bit value. But then what? Do greater values represent stronger > > signal or weaker signal? Are 0x and 0x special values? Is the > > returned value meaningful even when FE_HAS_SIGNAL is 0? When > > FE_HAS_LOCK is 0? Is the scale linear, or do some values have > > well-defined meanings, or is it arbitrary and each driver can have its > > own scale? What are the typical use cases by user-space application for > > this value? > > > > That's the kind of details I'd like to know, not only for the signal > > strength, but also for the SNR, BER and UB. Without this information, > > it seems a little difficult to have consistent frontend drivers. > > > > Thanks, > > -- > > Jean Delvare > > I try to raise this every six months or so. Check the mailing list > archive for "SNR" in the subject line. > > Yes, it's all screwed up and inconsistent across demods. I took a > crack at fixing it a few months ago by proposing a standard (and even > offering to fix up all the demods to be consistent), and those efforts > were derailed by some individuals who wanted what I would consider a > "perfect interface" at the cost of something that worked for 98% of > the userbase (I'm not going to point any fingers). And what did we > get as a result? Nothing. > > I could have had this problem solved six months ago for 98% of the > community, and instead we are right where we have been since the > beginning of the project. > > /me stops thinking about this and goes and gets some coffee Sorry, I didn't mean to restart a war. I really expected a standard to exist but be possibly undocumented. I did not expect all these values to not be standardized at all :( Thanks to all who answered anyway. I sincerely hope that we can improve the situation in a near future. I am not too familiar with DVB driver development, but I believe that even loose standards would be much better than no standards at all. And strict standards might not be possible to implement properly anyway, in case we do not have detailed specifications of the hardware (which is relatively frequent as I understand it.) Taking the example of the signal strength, I think I would be fine with the following description: 16-bit value, 0 means weakest signal (possibly no signal at all), 0x means strongest signal. I suspect user-space applications would already be able to do something about this. Thanks, -- Jean Delvare -- 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
Re: Details about DVB frontend API
On Friday 23 October 2009 06:13:30 Jean Delvare wrote: > Hi folks, > > I am looking for details regarding the DVB frontend API. I've read > linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, > FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS > commands return, however it does not give any information about how the > returned values should be interpreted (or, seen from the other end, how > the frontend kernel drivers should encode these values.) If there > documentation available that would explain this? > > For example, the signal strength. All I know so far is that this is a > 16-bit value. But then what? Do greater values represent stronger > signal or weaker signal? Are 0x and 0x special values? Is the > returned value meaningful even when FE_HAS_SIGNAL is 0? When > FE_HAS_LOCK is 0? Is the scale linear, or do some values have > well-defined meanings, or is it arbitrary and each driver can have its > own scale? What are the typical use cases by user-space application for > this value? > > That's the kind of details I'd like to know, not only for the signal > strength, but also for the SNR, BER and UB. Without this information, > it seems a little difficult to have consistent frontend drivers. > > Thanks, I have tried on two occasions to engage the the author of my particular driver as to how to implement a patch and use femon with no response. Its good that there is some movement at last which might get a result. I've said before I don't really care too much about spot on accuracy but rather a scale that increases as you get closer to a lock. I can imagine there are loads of users out there who rely on the output of things like femon and vdr-rotor to tune their equipment and with S2 cards like both of mine they are knackered so to speak. Mike -- 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
Re: Details about DVB frontend API
> We did discuss this briefly during the v4l-dvb mini-summit and I know Mike > Krufky knew what to do about this, but for the life of me I can't remember > what it was. I should have made a note of it... > > Mike, can you refresh my memory? You are correct Hans. Mike has some patches that begin to address this for the ATSC products, standardizing some of the unit measurements. Very clean, easy to review and merge. -- Steven Toth - 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
Re: Details about DVB frontend API
On Fri, Oct 23, 2009 at 4:12 AM, Markus Rechberger
wrote:
> On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham wrote:
>> On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
>> wrote:
>>> Em Thu, 22 Oct 2009 21:13:30 +0200
>>> Jean Delvare escreveu:
>>>
Hi folks,
I am looking for details regarding the DVB frontend API. I've read
linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
commands return, however it does not give any information about how the
returned values should be interpreted (or, seen from the other end, how
the frontend kernel drivers should encode these values.) If there
documentation available that would explain this?
For example, the signal strength. All I know so far is that this is a
16-bit value. But then what? Do greater values represent stronger
signal or weaker signal? Are 0x and 0x special values? Is the
returned value meaningful even when FE_HAS_SIGNAL is 0? When
FE_HAS_LOCK is 0? Is the scale linear, or do some values have
well-defined meanings, or is it arbitrary and each driver can have its
own scale? What are the typical use cases by user-space application for
this value?
That's the kind of details I'd like to know, not only for the signal
strength, but also for the SNR, BER and UB. Without this information,
it seems a little difficult to have consistent frontend drivers.
>>>
>>> We all want to know about that ;)
>>>
>>> Seriously, the lack of a description of the meaning of the ranges for those
>>> read values were already widely discussed at LMML and at the legacy dvb ML.
>>> We should return this discussion again and decide what would be the better
>>> way to describe those values.
>>>
>>> My suggestion is that someone summarize the proposals we had and give some
>>> time
>>> for people vote. After that, we just commit the most voted one, and commit
>>> the
>>> patches for it. A pending question that should also be discussed is what we
>>> will
>>> do with those dvb devices where we simply don't know what scale it uses.
>>> There
>>> are several of them.
>>
>>
>> Sometime back, (some time in April) i proposed a patch which addressed
>> the issue to scale "even those devices which have a weird scale or
>> none". Though based on an older tree of mine, here is the patch again.
>> If it looks good enough, i can port the patch to accomodate other
>> devices as well.
>>
>
> A few of our customers were requiring additional statistic
> information, so we added follwing
> command to our DVB API:
>
> FE_GET_SIGQUALITY
>
> struct media_sigquality {
> uint16_t MER; /**< in steps of 0.1 dB
> */
> uint32_t preViterbiBER ; /**< in steps of 1/scaleFactorBER
> */
> uint32_t postViterbiBER ; /**< in steps of 1/scaleFactorBER
> */
> uint32_t scaleFactorBER; /**< scale factor for BER
> */
> uint32_t packetError ; /**< number of packet errors
> */
> uint32_t postReedSolomonBER ; /**< in steps of 1/scaleFactorBER
> */
> uint32_t indicator; /**< indicative signal quality
> low=0..100=high */
> }
>
> It's a one shot request.
> it might be good to standardize this, although we can live with that
> additional command too.
Based on the above data structure, since UNC is calculated from pre -
post viterbi, any good reason why you need it explicit ? Which
otherwise is redundant. Still when simplified, it looks exactly the
same as the version 3.2 frontend statistic information alone except
for the BER scale, isn't it ?
Regards,
Manu
--
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
Re: Details about DVB frontend API
On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham wrote:
> On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
> wrote:
>> Em Thu, 22 Oct 2009 21:13:30 +0200
>> Jean Delvare escreveu:
>>
>>> Hi folks,
>>>
>>> I am looking for details regarding the DVB frontend API. I've read
>>> linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
>>> FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
>>> commands return, however it does not give any information about how the
>>> returned values should be interpreted (or, seen from the other end, how
>>> the frontend kernel drivers should encode these values.) If there
>>> documentation available that would explain this?
>>>
>>> For example, the signal strength. All I know so far is that this is a
>>> 16-bit value. But then what? Do greater values represent stronger
>>> signal or weaker signal? Are 0x and 0x special values? Is the
>>> returned value meaningful even when FE_HAS_SIGNAL is 0? When
>>> FE_HAS_LOCK is 0? Is the scale linear, or do some values have
>>> well-defined meanings, or is it arbitrary and each driver can have its
>>> own scale? What are the typical use cases by user-space application for
>>> this value?
>>>
>>> That's the kind of details I'd like to know, not only for the signal
>>> strength, but also for the SNR, BER and UB. Without this information,
>>> it seems a little difficult to have consistent frontend drivers.
>>
>> We all want to know about that ;)
>>
>> Seriously, the lack of a description of the meaning of the ranges for those
>> read values were already widely discussed at LMML and at the legacy dvb ML.
>> We should return this discussion again and decide what would be the better
>> way to describe those values.
>>
>> My suggestion is that someone summarize the proposals we had and give some
>> time
>> for people vote. After that, we just commit the most voted one, and commit
>> the
>> patches for it. A pending question that should also be discussed is what we
>> will
>> do with those dvb devices where we simply don't know what scale it uses.
>> There
>> are several of them.
>
>
> Sometime back, (some time in April) i proposed a patch which addressed
> the issue to scale "even those devices which have a weird scale or
> none". Though based on an older tree of mine, here is the patch again.
> If it looks good enough, i can port the patch to accomodate other
> devices as well.
>
A few of our customers were requiring additional statistic
information, so we added follwing
command to our DVB API:
FE_GET_SIGQUALITY
struct media_sigquality {
uint16_t MER; /**< in steps of 0.1 dB
*/
uint32_t preViterbiBER ; /**< in steps of 1/scaleFactorBER
*/
uint32_t postViterbiBER ; /**< in steps of 1/scaleFactorBER
*/
uint32_t scaleFactorBER; /**< scale factor for BER
*/
uint32_t packetError ; /**< number of packet errors
*/
uint32_t postReedSolomonBER ; /**< in steps of 1/scaleFactorBER
*/
uint32_t indicator;/**< indicative signal quality
low=0..100=high */
}
It's a one shot request.
it might be good to standardize this, although we can live with that
additional command too.
Best Regards,
Markus
--
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
Re: Details about DVB frontend API
> Em Thu, 22 Oct 2009 21:13:30 +0200 > Jean Delvare escreveu: > >> Hi folks, >> >> I am looking for details regarding the DVB frontend API. I've read >> linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, >> FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS >> commands return, however it does not give any information about how the >> returned values should be interpreted (or, seen from the other end, how >> the frontend kernel drivers should encode these values.) If there >> documentation available that would explain this? >> >> For example, the signal strength. All I know so far is that this is a >> 16-bit value. But then what? Do greater values represent stronger >> signal or weaker signal? Are 0x and 0x special values? Is the >> returned value meaningful even when FE_HAS_SIGNAL is 0? When >> FE_HAS_LOCK is 0? Is the scale linear, or do some values have >> well-defined meanings, or is it arbitrary and each driver can have its >> own scale? What are the typical use cases by user-space application for >> this value? >> >> That's the kind of details I'd like to know, not only for the signal >> strength, but also for the SNR, BER and UB. Without this information, >> it seems a little difficult to have consistent frontend drivers. > > We all want to know about that ;) > > Seriously, the lack of a description of the meaning of the ranges for > those > read values were already widely discussed at LMML and at the legacy dvb > ML. > We should return this discussion again and decide what would be the better > way to describe those values. > > My suggestion is that someone summarize the proposals we had and give some > time > for people vote. After that, we just commit the most voted one, and commit > the > patches for it. A pending question that should also be discussed is what > we will > do with those dvb devices where we simply don't know what scale it uses. > There > are several of them. > > Btw, the new official documentation is the media infrastructure docbook > that > can be found at the Kernel and at: > http://linuxtv.org/downloads/v4l-dvb-apis > > This covers both DVB and V4L API's. We did discuss this briefly during the v4l-dvb mini-summit and I know Mike Krufky knew what to do about this, but for the life of me I can't remember what it was. I should have made a note of it... Mike, can you refresh my memory? Thanks, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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
Re: Details about DVB frontend API
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
wrote:
> Em Thu, 22 Oct 2009 21:13:30 +0200
> Jean Delvare escreveu:
>
>> Hi folks,
>>
>> I am looking for details regarding the DVB frontend API. I've read
>> linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER,
>> FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS
>> commands return, however it does not give any information about how the
>> returned values should be interpreted (or, seen from the other end, how
>> the frontend kernel drivers should encode these values.) If there
>> documentation available that would explain this?
>>
>> For example, the signal strength. All I know so far is that this is a
>> 16-bit value. But then what? Do greater values represent stronger
>> signal or weaker signal? Are 0x and 0x special values? Is the
>> returned value meaningful even when FE_HAS_SIGNAL is 0? When
>> FE_HAS_LOCK is 0? Is the scale linear, or do some values have
>> well-defined meanings, or is it arbitrary and each driver can have its
>> own scale? What are the typical use cases by user-space application for
>> this value?
>>
>> That's the kind of details I'd like to know, not only for the signal
>> strength, but also for the SNR, BER and UB. Without this information,
>> it seems a little difficult to have consistent frontend drivers.
>
> We all want to know about that ;)
>
> Seriously, the lack of a description of the meaning of the ranges for those
> read values were already widely discussed at LMML and at the legacy dvb ML.
> We should return this discussion again and decide what would be the better
> way to describe those values.
>
> My suggestion is that someone summarize the proposals we had and give some
> time
> for people vote. After that, we just commit the most voted one, and commit the
> patches for it. A pending question that should also be discussed is what we
> will
> do with those dvb devices where we simply don't know what scale it uses. There
> are several of them.
Sometime back, (some time in April) i proposed a patch which addressed
the issue to scale "even those devices which have a weird scale or
none". Though based on an older tree of mine, here is the patch again.
If it looks good enough, i can port the patch to accomodate other
devices as well.
Regards,
Manu
diff -r b5505a985f24 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Sat Feb 21 01:12:09 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Tue Apr 07 18:19:22 2009 +0400
@@ -1004,8 +1004,8 @@
*/
/* Legacy */
if (fe->legacy) {
- if ((fepriv->state & FESTATE_LOSTLOCK) &&
- (fe->ops.info.caps & FE_CAN_RECOVER) &&
+ if ((fepriv->state & FESTATE_LOSTLOCK) &&
+ (fe->ops.info.caps & FE_CAN_RECOVER) &&
(fepriv->max_drift == 0)) {
dvb_frontend_swzigzag_update_delay(fepriv, s & FE_HAS_LOCK);
@@ -1487,6 +1487,13 @@
break;
}
+ case FE_STATISTICS_CAPS: {
+ struct fecap_statistics *stats_cap = parg;
+ memcpy(stats_cap, &fe->ops.statistics_caps, sizeof (struct fecap_statistics));
+ err = 0;
+ break;
+ }
+
case FE_READ_STATUS: {
fe_status_t* status = parg;
@@ -1502,6 +1509,17 @@
err = fe->ops.read_status(fe, status);
break;
}
+
+ case FE_SIGNAL_LEVEL:
+ if (fe->ops.read_level)
+ err = fe->ops.read_level(fe, (__u32 *) parg);
+ break;
+
+ case FE_SIGNAL_STATS:
+ if (fe->ops.read_stats)
+ err = fe->ops.read_stats(fe, (struct fesignal_stat *) parg);
+ break;
+
case FE_READ_BER:
if (fe->ops.read_ber)
err = fe->ops.read_ber(fe, (__u32*) parg);
@@ -1645,7 +1663,7 @@
break;
}
- memcpy(&fepriv->parameters, parg, sizeof (struct dvb_frontend_parameters));
+ memcpy(&fepriv->parameters, parg, sizeof (struct dvb_frontend_parameters));
memset(&fetunesettings, 0, sizeof(struct dvb_frontend_tune_settings));
memcpy(&fetunesettings.parameters, parg, sizeof (struct dvb_frontend_parameters));
diff -r b5505a985f24 linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Sat Feb 21 01:12:09 2009 +0400
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Tue Apr 07 18:19:22 2009 +0400
@@ -72,7 +72,7 @@
unsigned int audmode;
u64 std;
};
-
+
enum dvbfe_modcod {
DVBFE_MODCOD_DUMMY_PLFRAME = 0,
DVBFE_MODCOD_QPSK_1_4,
@@ -250,6 +250,7 @@
struct dvb_frontend_ops {
struct dvb_frontend_info info;
+ struct fecap_statistics statistics_caps;
void (*release)(struct dvb_frontend* fe);
void (*release_sec)(struct dvb_frontend* fe);
@@ -304,6 +305,9 @@
enum dvbfe_search (*search)(struct dvb_frontend *fe, struct dvbfe_params *fe_params);
int (*track)(struct dvb_frontend *fe, struct dvbfe_params *fe_params, int *delay);
+ int (*read_level)(struct dvb_frontend *fe, u32 *signal); /* Raw AGC level */
+ int (*read_stats)(struct dvb_frontend *fe, struct fesignal_stat *stat);
+
struct dvb_tuner_ops tuner_ops;
struct analog_demod_ops analog_ops;
Re: Details about DVB frontend API
Em Thu, 22 Oct 2009 21:13:30 +0200 Jean Delvare escreveu: > Hi folks, > > I am looking for details regarding the DVB frontend API. I've read > linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, > FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS > commands return, however it does not give any information about how the > returned values should be interpreted (or, seen from the other end, how > the frontend kernel drivers should encode these values.) If there > documentation available that would explain this? > > For example, the signal strength. All I know so far is that this is a > 16-bit value. But then what? Do greater values represent stronger > signal or weaker signal? Are 0x and 0x special values? Is the > returned value meaningful even when FE_HAS_SIGNAL is 0? When > FE_HAS_LOCK is 0? Is the scale linear, or do some values have > well-defined meanings, or is it arbitrary and each driver can have its > own scale? What are the typical use cases by user-space application for > this value? > > That's the kind of details I'd like to know, not only for the signal > strength, but also for the SNR, BER and UB. Without this information, > it seems a little difficult to have consistent frontend drivers. We all want to know about that ;) Seriously, the lack of a description of the meaning of the ranges for those read values were already widely discussed at LMML and at the legacy dvb ML. We should return this discussion again and decide what would be the better way to describe those values. My suggestion is that someone summarize the proposals we had and give some time for people vote. After that, we just commit the most voted one, and commit the patches for it. A pending question that should also be discussed is what we will do with those dvb devices where we simply don't know what scale it uses. There are several of them. Btw, the new official documentation is the media infrastructure docbook that can be found at the Kernel and at: http://linuxtv.org/downloads/v4l-dvb-apis This covers both DVB and V4L API's. Cheers, 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
Re: Details about DVB frontend API
On Thu, Oct 22, 2009 at 12:27 PM, Devin Heitmueller wrote: > I could have had this problem solved six months ago for 98% of the > community, and instead we are right where we have been since the > beginning of the project. This is really a shame too considering the enormous amount of people, both users & devs, who would really like to see this happen. You've got to start somewhere and build/improve from there. Simply sitting back and doing nothing is of absolutely no benefit what-so-ever. Maybe you should release your patch(es) and when/if enough people use them, there will be some pressure to actually have progress. Then again, the same ugly monster that is linux dvb politics might prevent that progress from ever happening. Regards, Derek -- 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
Re: Details about DVB frontend API
On Thu, Oct 22, 2009 at 3:13 PM, Jean Delvare wrote: > Hi folks, > > I am looking for details regarding the DVB frontend API. I've read > linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, > FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS > commands return, however it does not give any information about how the > returned values should be interpreted (or, seen from the other end, how > the frontend kernel drivers should encode these values.) If there > documentation available that would explain this? > > For example, the signal strength. All I know so far is that this is a > 16-bit value. But then what? Do greater values represent stronger > signal or weaker signal? Are 0x and 0x special values? Is the > returned value meaningful even when FE_HAS_SIGNAL is 0? When > FE_HAS_LOCK is 0? Is the scale linear, or do some values have > well-defined meanings, or is it arbitrary and each driver can have its > own scale? What are the typical use cases by user-space application for > this value? > > That's the kind of details I'd like to know, not only for the signal > strength, but also for the SNR, BER and UB. Without this information, > it seems a little difficult to have consistent frontend drivers. > > Thanks, > -- > Jean Delvare Hi Jean, I try to raise this every six months or so. Check the mailing list archive for "SNR" in the subject line. Yes, it's all screwed up and inconsistent across demods. I took a crack at fixing it a few months ago by proposing a standard (and even offering to fix up all the demods to be consistent), and those efforts were derailed by some individuals who wanted what I would consider a "perfect interface" at the cost of something that worked for 98% of the userbase (I'm not going to point any fingers). And what did we get as a result? Nothing. I could have had this problem solved six months ago for 98% of the community, and instead we are right where we have been since the beginning of the project. /me stops thinking about this and goes and gets some coffee 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
Details about DVB frontend API
Hi folks, I am looking for details regarding the DVB frontend API. I've read linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS commands return, however it does not give any information about how the returned values should be interpreted (or, seen from the other end, how the frontend kernel drivers should encode these values.) If there documentation available that would explain this? For example, the signal strength. All I know so far is that this is a 16-bit value. But then what? Do greater values represent stronger signal or weaker signal? Are 0x and 0x special values? Is the returned value meaningful even when FE_HAS_SIGNAL is 0? When FE_HAS_LOCK is 0? Is the scale linear, or do some values have well-defined meanings, or is it arbitrary and each driver can have its own scale? What are the typical use cases by user-space application for this value? That's the kind of details I'd like to know, not only for the signal strength, but also for the SNR, BER and UB. Without this information, it seems a little difficult to have consistent frontend drivers. Thanks, -- Jean Delvare -- 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
