[PULL] stv06xx and m5602 changes

2009-12-27 Thread Erik Andrén
Mauro,

Change no. 3 is a stable candidate as it fixes an actual bug related
to not needing to physically remove the webcam if multiple
gspca_stv06xx.ko module insert/remove cycles has been done. Thus it
has been flagged with the high priority. All the others are minor
issues.

Please pull from http://linuxtv.org/hg/~eandren/v4l-dvb

for the following 4 changesets:

01/04: gspca - m5602-s5k4aa: Add vflip quirk for the Amilo Xi 2428
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=7bd9ae0d49c2

02/04: gspca - stv06xx: Clean up the dump bridge function
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=1c977c6ea27c

03/04: gspca - stv06xx-vv6410: Ensure register STV_SCAN_RATE is zero
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=c1cd2ba26ab8

04/04: gspca - m5602: Be less verbose during sensor probe
http://linuxtv.org/hg/~eandren/v4l-dvb?cmd=changeset;node=64a49f44c218


 m5602/m5602_mt9m111.c|2 +-
 m5602/m5602_ov9650.c |2 +-
 m5602/m5602_po1030.c |2 +-
 m5602/m5602_s5k4aa.c |8 +++-
 m5602/m5602_s5k83a.c |2 +-
 stv06xx/stv06xx.c|3 ++-
 stv06xx/stv06xx_vv6410.h |1 +
 7 files changed, 14 insertions(+), 6 deletions(-)

Thanks,
Erik
--
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


weird array index in zl10036.c

2009-12-27 Thread Dan Carpenter
drivers/media/dvb/frontends/zl10036.c
   397  /* could also be one block from reg 2 to 13 and additional 
10/11 */
   398  u8 zl10036_init_tab[][2] = {
   399  { 0x04, 0x00 }, /*   2/3: div=0x400 - arbitrary 
value */
   400  { 0x8b, _RDIV_REG },/*   4/5: rfg=0 ba=1 bg=1 len=? 
*/
   401  /*p0=0 c=0 r=_RDIV_REG 
*/
   402  { 0xc0, 0x20 }, /*   6/7: rsd=0 bf=0x10 */
   403  { 0xd3, 0x40 }, /*   8/9: from datasheet */
   404  { 0xe3, 0x5b }, /* 10/11: lock window level */
   405  { 0xf0, 0x28 }, /* 12/13: br=0xa clr=0 tl=0*/
   406  { 0xe3, 0xf9 }, /* 10/11: unlock window level */
   407  };
   408
   409  /* invalid values to trigger writing */
   410  state-br = 0xff;
   411  state-bf = 0xff;
   412
   413  if (!state-config-rf_loop_enable)
   414  zl10036_init_tab[1][2] |= 0x01;
 
This seems like an off by one error.  I think it maybe should say
zl10036_init_tab[1][1] |= 0x01;?

regards,
dan carpenter
--
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


Mantis driver on TechniSat CableStar HD 2

2009-12-27 Thread Wolfgang Denk
I have problems getting a TechniSat CableStar HD 2 DVB-C card
running with the latest Mantis driver on a Fedora 12 system (using
their current standard 2.6.31.9-174.fc12.i686.PAE kernel in
combination with the drivers from the http://linuxtv.org/hg/v4l-dvb
repository). Tests have been done on two different mainboards.

I can run a channel scan (using kaffeine) perfectly fine, also tuning
to channels appears to work. I see a load of some 1,300 interrupts per
sec when I have kaffeine running and tuned, and it seems there is data
transferred between the card and the application.

The problem is: there is no video nor sound.

I have bought this card second-hand on, so I am not really sure if it
is a software issue, or if eventually the hardware is broken.


Can anybody recommend a way how to verify the driver or the hardware?
Or can you recommend a specific kernel version the Mantis driver has
been tested against?

Any help welcome. Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Another megabytes the dust.
--
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: weird array index in zl10036.c

2009-12-27 Thread Matthias Schwarzott
On Sonntag, 27. Dezember 2009, Dan Carpenter wrote:
 drivers/media/dvb/frontends/zl10036.c
397  /* could also be one block from reg 2 to 13 and additional
  10/11 */ 398  u8 zl10036_init_tab[][2] = {
399  { 0x04, 0x00 }, /*   2/3: div=0x400 -
  arbitrary value */ 400  { 0x8b, _RDIV_REG },/*   4/5:
  rfg=0 ba=1 bg=1 len=? */ 401  /*  
   p0=0 c=0 r=_RDIV_REG */ 402  { 0xc0, 0x20 },
  /*   6/7: rsd=0 bf=0x10 */ 403  { 0xd3, 0x40 }, /*
8/9: from datasheet */ 404  { 0xe3, 0x5b }, /*
  10/11: lock window level */ 405  { 0xf0, 0x28 },
  /* 12/13: br=0xa clr=0 tl=0*/ 406  { 0xe3, 0xf9 },
  /* 10/11: unlock window level */ 407  };
408
409  /* invalid values to trigger writing */
410  state-br = 0xff;
411  state-bf = 0xff;
412
413  if (!state-config-rf_loop_enable)
414  zl10036_init_tab[1][2] |= 0x01;
 
 This seems like an off by one error.  I think it maybe should say
 zl10036_init_tab[1][1] |= 0x01;?
 

Good catch!
But according to the datasheet it should be
zl10036_init_tab[1][0] |= 0x01;

Please submit a patch for it.

Regards
Matthias
--
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


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2009-12-27 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Sun Dec 27 19:00:02 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13848:75c97b2d1a2a
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-armv5: OK
linux-2.6.32-armv5-davinci: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-armv5-ixp: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-armv5-omap2: OK
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: ERRORS
linux-2.6.28-i686: ERRORS
linux-2.6.29.1-i686: ERRORS
linux-2.6.30-i686: ERRORS
linux-2.6.31-i686: ERRORS
linux-2.6.32-i686: ERRORS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: OK
linux-2.6.32-mips: OK
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: OK
linux-2.6.32-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: WARNINGS
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: OK
linux-2.6.31-x86_64: WARNINGS
linux-2.6.32-x86_64: WARNINGS
spec: OK
sparse (linux-2.6.32): ERRORS
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
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: Error using PWC on a PS3

2009-12-27 Thread Andrea
On 26/12/09 21:20, Andrea wrote:
 On 26/12/09 21:12, Andrea wrote:
 Hi,

 I've tried to attach my Logitech, Inc. QuickCam Pro 4000 to a PS3 running 
 Fedora 12.

 I get this error in dmesg

 pwc: Failed to set video mode q...@10 fps; return code = -110

 Everything works well on a standard x86 laptop running Fedora 11.

 Anybody has an idea why a different architecture could affect pwc?
 I don't know, problems with little/big endian?

I've recompiled pwc adding some extra logging and this is the output

The first error is

kernel: pwc: Failed to set LED on/off time; error -110 . this 
is the first error

Does anybody know what -110 means?

Moreover, these 2 lines DON'T happen on a x86

kernel: pwc: probe() called [046D 08B2], if 1
kernel: pwc: probe() called [046D 08B2], if 2

any idea?

Thanks

kernel: usb 1-2.1: new full speed USB device using ps3-ehci-driver and address 4
kernel: usb 1-2.1: New USB device found, idVendor=046d, idProduct=08b2
kernel: usb 1-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
kernel: usb 1-2.1: configuration #1 chosen from 1 choice
kernel: Linux video capture interface: v2.00
kernel: pwc: Philips webcam module version 10.0.13 loaded.
kernel: pwc: Supports Philips PCA645/646, PCVC675/680/690, 
PCVC720[40]/730/740/750  PCVC830/840.
kernel: pwc: Also supports the Askey VC010, various Logitech Quickcams, Samsung 
MPC-C10 and MPC-C30,
kernel: pwc: the Creative WebCam 5  Pro Ex, SOTEC Afina Eye and Visionite 
VCS-UC300 and VCS-UM100.
kernel: pwc: Trace options: 0x01ff
kernel: pwc: Registering driver at address 0xd0ed9cf0.
kernel: pwc: probe() called [046D 08B2], if 0
kernel: pwc: Logitech QuickCam 4000 Pro USB webcam detected.
kernel: pwc: Device serial number is
kernel: pwc: Release: 
kernel: pwc: Registered as video0.
kernel: pwc: probe() function returning struct at 0xc6808400.
kernel: pwc:  video_open called(vdev = 0xc4f2d400).
kernel: pwc: Doing first time initialization.
kernel: pwc: This Logitech QuickCam Pro 4000 camera is equipped with a Sony CCD 
sensor + TDA8787 (32).
kernel: pwc: probe() called [046D 08B2], if 1
kernel: pwc: probe() called [046D 08B2], if 2
kernel: usbcore: registered new interface driver Philips webcam
kernel: pwc:  pwc_allocate_buffers(pdev = 0xc6808400)
kernel: pwc: Allocated iso buffer at cede4000.
kernel: pwc: Allocated iso buffer at ced34000.
kernel: pwc: Allocated frame buffer structure at c6516420.
kernel: pwc: Allocated frame buffer 0 at d0f57000.
kernel: pwc: Allocated frame buffer 1 at d0fca000.
kernel: pwc: Allocated frame buffer 2 at d103d000.
kernel: pwc: Allocated image buffer at d10b.
kernel: pwc:  pwc_allocate_buffers()
kernel: pwc:  pwc_reset_buffers __enter__
kernel: pwc:  pwc_reset_buffers __leaving__
kernel: pwc: set_video_mode(176x144 @ 10, palette 15).
kernel: pwc: decode_size = 1.
kernel: pwc: Using alternate setting 1.
kernel: pwc: frame_size=18900, vframes=10, vsize=1, vsnapshot=0, vbandlength=630
kernel: pwc: Set viewport to 176x144, image size is 160x120.
kernel: pwc: Setting alternate interface 1
kernel: pwc: Allocated URB at 0xc652de00
kernel: pwc: Allocated URB at 0xc652dc00
kernel: pwc: URB 0xc652de00 submitted.
kernel: pwc: URB 0xc652dc00 submitted.
kernel: pwc:  pwc_isoc_init()
kernel: pwc:  video_open() returns 0.
kernel: VIDIOC_QUERYCAP
kernel: pwc: ioctl(VIDIOC_QUERYCAP) This application try to use the v4l2 layer
kernel: pwc:  video_close called(vdev = 0xc4f2d400).
kernel: pwc:  pwc_isoc_cleanup()
kernel: pwc: Unlinking URB c652de00
kernel: pwc: URB (c652de00) unlinked synchronuously.
kernel: pwc: Unlinking URB c652dc00
kernel: pwc: URB (c652dc00) unlinked synchronuously.
kernel: pwc: Freeing URB
kernel: pwc: Freeing URB
kernel: pwc:  pwc_isoc_cleanup()
kernel: pwc: Entering free_buffers(c6808400).
kernel: pwc: Freeing ISO buffer at cede4000.
kernel: pwc: Freeing ISO buffer at ced34000.
kernel: pwc: Freeing frame buffer 0 at d0f57000.
kernel: pwc: Freeing frame buffer 1 at d0fca000.
kernel: pwc: Freeing frame buffer 2 at d103d000.
kernel: pwc: Freeing decompression buffer at c6a4.
kernel: pwc: Freeing image buffer at d10b.
kernel: pwc: Leaving free_buffers().
kernel: pwc: Failed to set LED on/off time; error -110 . this 
is the first error
kernel: pwc:  video_close() vopen=0
kernel: pwc:  video_open called(vdev = 0xc4f2d400).
kernel: pwc: Failed to set LED on/off time.
kernel: pwc:  pwc_allocate_buffers(pdev = 0xc6808400)
kernel: pwc: Allocated iso buffer at ceecc000.
kernel: pwc: Allocated iso buffer at c2af8000.
kernel: pwc: Allocated frame buffer structure at c4f48d80.
kernel: pwc: Allocated frame buffer 0 at d11fc000.
kernel: pwc: Allocated frame buffer 1 at d126f000.
kernel: pwc: Allocated frame 

[PULL] http://linuxtv.org/hg/~ajacquet/v4l-dvb/

2009-12-27 Thread Antoine Jacquet

Mauro,

Please pull from http://linuxtv.org/hg/~ajacquet/v4l-dvb

for the following changeset:

01/01: zr364xx: fix support for Aiptek DV T300
http://linuxtv.org/hg/~ajacquet/v4l-dvb?cmd=changeset;node=f38801e0dfeb


 zr364xx.c |   37 +++--
 1 file changed, 35 insertions(+), 2 deletions(-)

Thanks,
Antoine

--
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: Mantis driver on TechniSat CableStar HD 2

2009-12-27 Thread Manu Abraham
Hello Wolfgang,

On Sun, Dec 27, 2009 at 8:37 PM, Wolfgang Denk w...@denx.de wrote:
 I have problems getting a TechniSat CableStar HD 2 DVB-C card
 running with the latest Mantis driver on a Fedora 12 system (using
 their current standard 2.6.31.9-174.fc12.i686.PAE kernel in
 combination with the drivers from the http://linuxtv.org/hg/v4l-dvb
 repository). Tests have been done on two different mainboards.

 I can run a channel scan (using kaffeine) perfectly fine, also tuning
 to channels appears to work. I see a load of some 1,300 interrupts per
 sec when I have kaffeine running and tuned, and it seems there is data
 transferred between the card and the application.


From what i understand without much deeper look is that you have a
successful LOCK and hence the transfer.


 The problem is: there is no video nor sound.


The generic budget DVB cards do not have an onboard hardware decoder
and what we have is a DVR device from which the Transport stream is
being read out. A Software decoder is used to process the TS.


 I have bought this card second-hand on, so I am not really sure if it
 is a software issue, or if eventually the hardware is broken.


 Can anybody recommend a way how to verify the driver or the hardware?
 Or can you recommend a specific kernel version the Mantis driver has
 been tested against?


If you can successfully tune and get a valid TS from the DVR device,
you can rule out issues with the card and the driver.
You can verify the functionality of the hardware and driver with the
command line applications from the dvb-apps repository.

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: Which modules for the VP-2033? Where is the module mantis.ko?

2009-12-27 Thread Manu Abraham
Hello Aljaz,

On Thu, Dec 24, 2009 at 8:51 PM, Aljaž Prusnik prus...@gmail.com wrote:
 On čet, 2009-12-24 at 17:45 +0100, Ruediger Dohmhardt wrote:
 Aljaž, thanks for the reply. As Manu said above there was a build problem.
 As said already in this Thread, I downloaded version 2315248f648c, which
 compiles fine and
 has all modules for the 2033 DVB-C.

 I have the same version and it doesn't work for me. I have a 2040
 module.

Can you please do a lspci -vn for the Mantis card you have ? Also try
loading the mantis.ko module with verbose=5 module parameter, to get
more debug information.

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: [linux-dvb] Acoustical mode for femon

2009-12-27 Thread Manu Abraham
On Thu, Dec 24, 2009 at 1:20 AM, Maximilian Seesslen m...@seesslen.net wrote:
 Hi List,

 find attached a patch that adds a Acoustical mode to femon.
 The monitoring application produces a sound indicating the signal quality. The
 higher the beep the better the signal quality.
 This is useful while mounting the antenna for finding the best position 
 without
 having to look at the monitor or without even having a monitor.

Thanks, applied.

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: How to know which camera is /dev/videoX

2009-12-27 Thread Kuninori Morimoto

Dear Guennadi, Andy

Thank you for your help !!

It is possible to identify it by this method.

check videoX
/sys/bus/soc-camera/devices/0-0/video4linux:video0
/sys/bus/soc-camera/devices/1-0/video4linux:video1

get name
/sys/bus/soc-camera/devices/0-0/control/name  - mt9t112
/sys/bus/soc-camera/devices/1-0/control/name  - tw9910

 $ v4l2-ctl --list-devices
 $ v4l2-ctl -d /dev/video0 -D
 $ v4l2-ctl -d /dev/video0 --log-status
 $ v4l2-ctl -d /dev/video1 -D
 $ v4l2-ctl -d /dev/video1 --log-status

wow... I didn't know this way.
Thank you for your nice advice !!
It will be good help for me

Thanks again !!

Best regards
--
Kuninori Morimoto
 
--
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: [RFC] dvb-apps ported for ISDB-T

2009-12-27 Thread Mauro Carvalho Chehab
Manu Abraham wrote:
 Hello Mauro,
 
 
 On Fri, Dec 25, 2009 at 7:09 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu:
 I wrote several patches those days in order to allow dvb-apps to properly
 parse ISDB-T channel.conf.

 On ISDB-T, there are several new parameters, so the parsing is more complex
 than all the other currently supported video standards.

 I've added the changes at:

 http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/

 I've merged there Patrick's dvb-apps-isdbt tree.

 While there, I fixed a few bugs I noticed on the parser and converted it
 to work with the DVB API v5 headers that are bundled together with dvb-apps.
 This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones
 there can now be removed.

 TODO:
 =

 The new ISDB-T parameters are parsed, but I haven't add yet a code to make
 them to be used;

 There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the
 segment parameters. Currently, the parser will fail if those parameters are 
 found.

 gnutv is still reporting ISDB-T as DVB-T.

 I've just fixed the issues on the TODO list. The DVB v5 code is now working 
 fine
 for ISDB-T.

 Pending stuff (patches are welcome):
- Implement v5 calls for other video standards;
- Remove the duplicated DVBv5 code on /util/scan/scan.c (the code for 
 calling
 DVBv5 is now at /lib/libdvbapi/v5api.c);
- Test/use the functions to retrieve values via DVBv5 API. The 
 function is
 already there, but I haven't tested.

 With the DVBv5 API implementation, zap is now working properly with ISDB-T.
 gnutv also works (although some outputs - like decoder - may need some 
 changes, in
 order to work with mpeg4/AAC video/audio codecs).
 
 
 Few comments on your changes (that came up on a first glance):

Thank you for your review!

 - dvb-apps don't need a DCO (S-O-B) as for kernel related code (though
 not an issue, whether it is there or not)

I know. It is just easier for me to keep the SOB than to modify my .hgrc just 
for
dvb-apps. If this really bothers you, I'm fine to drop it before merging it.

 - changeset 1334 is a regression:
 
 dvb-apps look at libraries that are shipped with the distribution
 alone. The headers in there are a copy for szap2 alone for test cases
 and szap2 is not a generic application such as zap and hence doesn't
 need to be ported.

It is very confusing to have a copy of the headers there that it is used
by just one application. So, the dvb headers should be either dropped or used
by all compilation.

By using the random header that is found at /usr/include means that
dvb-apps cannot be built with all their capabilities with the stable distros, 
but only with the latest -rc kernels. 

Just for example, in my case, I was running a distro that it was launched
last month (Fedora 12). It was built and running a 2.6.31 kernel, but ISDB-T
API appeared only on 2.6.32. It seems really doubtful that building dvb-apps 
with any current non-alpha distros would enable ISDB-T, since I doubt you'll
find may users with ISDB-T headers on their /usr/include.

On the other hand, if dvb-apps is newer than the driver, there's no problem, 
since
it will fall-back to v3 API calls.

The practical effect of not using the latest headers is that people using 
the latest -hg kernel drivers won't benefit from the API changes, since 
there's no target at the out-of-tree system to update the headers at 
/usr/include.

So, except for kernel developers that know how to update the headers from the 
latest
linus tree, ISDB-T wouldn't work for users currently.

 - get_v5_frontend keeps on malloc with no free .

It is feed at the end by:

+exit:
+   if (dtv_prop_arg)
+   free (dtv_prop_arg);
+   free_props(prop);

Anyway, you're right: there are some cases that it is not freeing. I'll fix it.

 
 - the basic design we have in the libraries is that we don't allow the
 library to do the allocation but allocation is done by the user
 (application)

In this case, it is just a temporary allocation, just like several other libc
routines do. The temporary memory should be freed before returning back to
the caller.

It is used to create a temporary list of data to be sent to the device, and
it is standard-dependent. The current code has only ISDB-T, but I wrote it
thinking on being extended to other standards as well.

The alternative of not using such data struct is very ugly.

The library might provide a callback method to allocate/free such temporary 
memory,
but I see no point on doing it.

 - the library is not meant to handle the basic in-kernel API alone,
 there are others that's the whole intention for the library.

Sorry, but I didn't get what you meant here: the ISDB-T data structs need to be
handled by the scan and the parsers.

All the applications needed to know is that now ISDB-T is supported. All ISDB-T
complexity were let to the API. If you see the diffstat for the 

Re: [linux-dvb] Acoustical mode for femon

2009-12-27 Thread VDR User
On Wed, Dec 23, 2009 at 1:20 PM, Maximilian Seesslen m...@seesslen.net wrote:
 Hi List,

 find attached a patch that adds a Acoustical mode to femon.
 The monitoring application produces a sound indicating the signal quality. The
 higher the beep the better the signal quality.
 This is useful while mounting the antenna for finding the best position 
 without
 having to look at the monitor or without even having a monitor.

Thank you for this!  Very useful since it's hard to be outside aiming
and inside looking at a monitor at the same time.  :)
--
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