Re: Details about DVB frontend API

2009-12-07 Thread Mauro Carvalho Chehab
Michael Krufky wrote:
 On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com 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 abraham.m...@gmail.com 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 abraham.m...@gmail.com for his initial proposal.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com


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)
+   

Re: Details about DVB frontend API

2009-12-07 Thread Mauro Carvalho Chehab
Mauro Carvalho Chehab wrote:
 Michael Krufky wrote:
 On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com 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 abraham.m...@gmail.com 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 abraham.m...@gmail.com 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

2009-12-05 Thread Mauro Carvalho Chehab
Michael Krufky wrote:
 On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com 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

2009-12-05 Thread Michael Krufky
On Sat, Dec 5, 2009 at 12:30 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Michael Krufky wrote:
 On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com 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

2009-12-05 Thread Mauro Carvalho Chehab
Michael Krufky wrote:
 On Sat, Dec 5, 2009 at 12:30 PM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
 Michael Krufky wrote:
 On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com 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

2009-12-04 Thread VDR User
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

2009-11-20 Thread Manu Abraham
On Tue, Nov 17, 2009 at 11:46 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:

 Manu Abraham escreveu:
  On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
  mche...@infradead.org wrote:
  Em Thu, 22 Oct 2009 21:13:30 +0200
  Jean Delvare kh...@linux-fr.org 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 field
 + *     MSB:1bit indicates the signdness of the parameter
 + */
 +struct fecap_quality {
 +       enum fecap_quality_params       params;
 +       enum fecap_scale_params         scale;
 +
 +     

Re: Details about DVB frontend API

2009-11-20 Thread Julian Scheel
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 statistics approach would allow realtime applications like sat-finders 
to be 

Re: Details about DVB frontend API

2009-11-20 Thread Manu Abraham
On Fri, Nov 20, 2009 at 3:37 PM, Julian Scheel jul...@jusst.de 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 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

Re: Details about DVB frontend API

2009-11-20 Thread Julian Scheel

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

2009-11-18 Thread Devin Heitmueller
On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
mche...@infradead.org 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

2009-11-18 Thread Mauro Carvalho Chehab
Devin Heitmueller wrote:
 On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
 mche...@infradead.org 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 need to wait for some time before reading the QoS.

This time will 

Re: Details about DVB frontend API

2009-11-18 Thread Devin Heitmueller
On Wed, Nov 18, 2009 at 9:04 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Devin Heitmueller wrote:
 On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
 mche...@infradead.org 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 

Re: Details about DVB frontend API

2009-11-18 Thread Michael Krufky
On Wed, Nov 18, 2009 at 10:17 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Wed, Nov 18, 2009 at 9:04 AM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
 Devin Heitmueller wrote:
 On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
 mche...@infradead.org 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 

Re: Details about DVB frontend API

2009-11-18 Thread Devin Heitmueller
On Wed, Nov 18, 2009 at 9:04 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Devin Heitmueller wrote:
 On Tue, Nov 17, 2009 at 5:53 PM, Mauro Carvalho Chehab
 mche...@infradead.org 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 

Re: Details about DVB frontend API

2009-11-17 Thread Mauro Carvalho Chehab
Manu Abraham escreveu:
 On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
 Em Thu, 22 Oct 2009 21:13:30 +0200
 Jean Delvare kh...@linux-fr.org 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 {
+   enum fecap_error_params params;
+   __u32   width;
+   

Re: Details about DVB frontend API

2009-11-17 Thread Devin Heitmueller
On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab
mche...@infradead.org 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

2009-11-17 Thread Jean Delvare
On Tue, 17 Nov 2009 14:55:51 -0500, Devin Heitmueller wrote:
 On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab
 mche...@infradead.org 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

2009-11-17 Thread Mauro Carvalho Chehab
Devin Heitmueller escreveu:
 On Tue, Nov 17, 2009 at 2:46 PM, Mauro Carvalho Chehab
 mche...@infradead.org 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

2009-10-24 Thread David T. L. Wong

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

2009-10-23 Thread Jean Delvare
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 kh...@linux-fr.org 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

2009-10-23 Thread Jean Delvare
On Fri, 23 Oct 2009 05:10:25 +0900, Mauro Carvalho Chehab wrote:
 Em Thu, 22 Oct 2009 21:13:30 +0200
 Jean Delvare kh...@linux-fr.org 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

2009-10-23 Thread Jean Delvare
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

2009-10-23 Thread Michael Krufky
On Fri, Oct 23, 2009 at 11:47 AM, Jean Delvare kh...@linux-fr.org 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

2009-10-23 Thread VDR User
On Thu, Oct 22, 2009 at 1:29 PM, Manu Abraham abraham.m...@gmail.com 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

2009-10-23 Thread Markus Rechberger
On Fri, Oct 23, 2009 at 9:02 PM, VDR User user@gmail.com wrote:
 On Thu, Oct 22, 2009 at 1:29 PM, Manu Abraham abraham.m...@gmail.com 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

2009-10-22 Thread Devin Heitmueller
On Thu, Oct 22, 2009 at 3:13 PM, Jean Delvare kh...@linux-fr.org 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


Re: Details about DVB frontend API

2009-10-22 Thread VDR User
On Thu, Oct 22, 2009 at 12:27 PM, Devin Heitmueller
dheitmuel...@kernellabs.com 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

2009-10-22 Thread Mauro Carvalho Chehab
Em Thu, 22 Oct 2009 21:13:30 +0200
Jean Delvare kh...@linux-fr.org 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

2009-10-22 Thread Manu Abraham
On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Em Thu, 22 Oct 2009 21:13:30 +0200
 Jean Delvare kh...@linux-fr.org 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;
 };
diff -r b5505a985f24 

Re: Details about DVB frontend API

2009-10-22 Thread Markus Rechberger
On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham abraham.m...@gmail.com wrote:
 On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
 Em Thu, 22 Oct 2009 21:13:30 +0200
 Jean Delvare kh...@linux-fr.org 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

2009-10-22 Thread Manu Abraham
On Fri, Oct 23, 2009 at 4:12 AM, Markus Rechberger
mrechber...@gmail.com wrote:
 On Thu, Oct 22, 2009 at 10:29 PM, Manu Abraham abraham.m...@gmail.com wrote:
 On Fri, Oct 23, 2009 at 12:10 AM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
 Em Thu, 22 Oct 2009 21:13:30 +0200
 Jean Delvare kh...@linux-fr.org 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

2009-10-22 Thread Steven Toth
 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

2009-10-22 Thread Mike Booth
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