Re: [linux-dvb] Looking for original source of an old DVB tree

[Chris Moore]

Hello,

Thanks for your reply, Antti.

Le 24/01/2010 13:19, Antti Palosaari a écrit :

On 01/24/2010 10:08 AM, Chris Moore wrote:

Hello,

Short version:
I am looking for the original source code of a Linux DVB tree containing
in particular
drivers/media/dvb/dibusb/microtune_mt2060.c
and the directory
drivers/media/dvb/dibusb/mt2060_api

Googling for microtune_mt2060.c and mt2060_api is no help.
Could anyone kindly point me in the right direction, please?


It is mt2060.c, mt2060_priv.h (IIRC) and mt2060.h.



Sorry, I did not explain my problem clearly enough.
The DVB subtree in the Realtek 2.6.12.6-VENUS kernel used on the 
Xtreamer is *very* different from that in mainline 2.6.12.6.

It is also different from anything I have found anywhere else.
Judging from the code it looks as though Realtek got the source code 
from elsewhere and hacked it dirtily for their own chips.

I was trying to find the original unhacked source code.
I *do* have the (hacked) files.
The file and directory I cited seem to be specific to this version.
I gave them to see if they ring a bell with anyone.
(A thought: maybe they could have come directly from a DiBcom SDK?)


Longer version:
I am trying to get my USB DVB-T stick running on my Xtreamer.
Xtreamer uses an old 2.6.12.6 kernel heavily modified by Realtek and
possibly also modified by MIPS.
I have the source code but it would be a tremendous effort to change to
a recent kernel.
The DVB subtree seems to have been dirtily hacked by Realtek to support
their frontends.
In the process they seem to have lost support for other frontends.
I have been trying to find the source code for the original version.
I have found nothing resembling it in kernel.org, linux-mips.org and
linuxtv.org.


I am not sure what kind of device Xtreamer is, but try this:
http://linuxtv.org/hg/~anttip/rtl2831u/

It is for Realtek RTL2831U + MT2060 based USB sticks.



The Xtreamer is a cheap network media player based on the Realtek 
RTD1283 SoC.


I am not looking for support for Realtek DVB chips.
I was trying to get an Artec T14 USB DVB-T stick running on the Xtreamer.
(This looked the most promising of the sticks I have.)

In the end I bit the bullet and backported the current tip of v4l-dvb to 
2.6.12.6.

This was not trivial as many modifications were needed :(

I now have modules that load and which *nearly* work.
Scan outputs ">>> tuning status == 0x02" then  ">>> tuning status == 
0x1a" and sticks there with no further output (for hours; probably 
indefinitely).

This status seems to indicate a problem with FEC.
I guess there are uncorrectable Reed-Solomon errors.

I live in a low signal area and this could be normal.
Is there a LNA on this stick?
I couldn't find a module parameter to activate one.

Anyway I now think the best idea would be to for me to get the stick 
running on x86 first.


Thanks again for your help.

Cheers,
Chris


--
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: [Patch 3/3] Kworld 315U

[Franklin Meng]

Do you need me to resubmit the patches as a file attachment? 

Thanks,
Franklin Meng

--- On Mon, 1/25/10, Mauro Carvalho Chehab  wrote:

> From: Mauro Carvalho Chehab 
> Subject: Re: [Patch 3/3] Kworld 315U
> To: "Franklin Meng" 
> Cc: linux-media@vger.kernel.org, "Douglas Schilling Landgraf" 
> 
> Date: Monday, January 25, 2010, 6:13 AM
> Franklin Meng wrote:
> 
> Also complained about line-wrapping.
> 
> Cheers,
> Mauro
> > Patch to bring device out of power saving mode. 
> 
> >  
> > Signed-off-by: Franklin Meng
> > 
> > diff -r b6b82258cf5e
> linux/drivers/media/video/em28xx/em28xx-core.c   
>            
>    
> > ---
> a/linux/drivers/media/video/em28xx/em28xx-core.c 
>   Thu Dec 31 19:14:54 2009 -0200
> > +++
> b/linux/drivers/media/video/em28xx/em28xx-core.c 
>   Sun Jan 17 22:54:21 2010 -0800
> > @@ -1132,6 +1132,7 @@       
>                
>                
>                
>          
> >   */         
>                
>                
>                
>                
>         
> >  void em28xx_wake_i2c(struct em28xx *dev) 
>                
>                
>            
> >  {           
>                
>                
>                
>                
>         
> > +   
>    v4l2_device_call_all(&dev->v4l2_dev,
> 0, core,  s_power, 1);       
>            
> >     
>    v4l2_device_call_all(&dev->v4l2_dev,
> 0, core,  reset, 0);         
>            
> >     
>    v4l2_device_call_all(&dev->v4l2_dev,
> 0, video, s_routing,         
>            
> >               
>      
>    INPUT(dev->ctl_input)->vmux, 0,
> 0);               
>            
> > 
> > 
> > 
> > 
> >       
> > --
> > 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
> 
> --
> 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
> 


  
--
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: Problems with cx18

[Andy Walls]

On Mon, 2010-01-25 at 10:47 -0500, Devin Heitmueller wrote:
> On Mon, Jan 25, 2010 at 10:06 AM, Mauro Carvalho Chehab
>  wrote:
> > Hi Devin/Andy/Jean,
> >
> > The cx88-alsa and cx18-drivers are broken: the driver depend of 
> > request_modules that doesn't exist
> > when !CONFIG_MODULES, and has some wrong __init annotations.
> >
> > The sq905c has a warning.
> >
> > I'm compiling it with:
> >make ARCH=i386 allmodconfig drivers/media/|grep -v "^  CC" |grep -v 
> > "^  LD"
> >
> > Those are the errors found:
> >
> > drivers/media/video/cx18/cx18-driver.c:252: warning: ‘request_modules’ used 
> > but never defined
> > WARNING: drivers/media/video/cx18/cx18-alsa.o(.text+0x4de): Section 
> > mismatch in reference from the function cx18_alsa_load() to the function 
> > .init.text:snd_cx18_init()
> > The function cx18_alsa_load() references
> > the function __init snd_cx18_init().
> > This is often because cx18_alsa_load lacks a __init
> > annotation or the annotation of snd_cx18_init is wrong.
> >
> > WARNING: drivers/media/video/cx18/built-in.o(.text+0x1c022): Section 
> > mismatch in reference from the function cx18_alsa_load() to the function 
> > .init.text:snd_cx18_init()
> > The function cx18_alsa_load() references
> > the function __init snd_cx18_init().
> > This is often because cx18_alsa_load lacks a __init
> > annotation or the annotation of snd_cx18_init is wrong.
> >
> > drivers/media/video/gspca/sq905c.c: In function ‘sd_config’:
> > drivers/media/video/gspca/sq905c.c:207: warning: unused variable ‘i’
> > WARNING: drivers/media/video/built-in.o(.text+0x28d24e): Section mismatch 
> > in reference from the function cx18_alsa_load() to the function 
> > .init.text:snd_cx18_init()
> > The function cx18_alsa_load() references
> > the function __init snd_cx18_init().
> > This is often because cx18_alsa_load lacks a __init
> > annotation or the annotation of snd_cx18_init is wrong.
> >
> > WARNING: drivers/media/built-in.o(.text+0x2d2a2a): Section mismatch in 
> > reference from the function cx18_alsa_load() to the function 
> > .init.text:snd_cx18_init()
> > The function cx18_alsa_load() references
> > the function __init snd_cx18_init().
> > This is often because cx18_alsa_load lacks a __init
> > annotation or the annotation of snd_cx18_init is wrong.
> 
> This looks like breakage I probably introduced with the cx18 alsa
> support.  I will dig into this tonight.

Devin,

If it's easiest to not treat the cx18-alsa stuff as a module and just
always have the cx18 ALSA device interface available, that's OK by me.
Your call.

Regards,
Andy


> Devin
> 

--
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: Hauppauge Win TV HVR-1300: streaming and grabbing fail after a while, changing resolution renders card inoperable

[Friedrich Delgado Friedrichs]

Reproduced this problem with latest checkout from http://linuxtv.org/hg/v4l-dvb

Friedel wrote:
> I'm sorry, two of the problems described in my mail have nothing to do
> with the driver. There's a daemon running that accesses the tuner and
> vbi (nxtvepg), which causes problems 1 and 2.
> 
> I've failed to notice this because nxtvepg can (normally) detect
> tvtime and xawtv and doesn't interfere with them, so I assumed it
> might have a general mechanism for detecting if the tv driver is in
> use by a different app.
> 
> The third problem remains:
> 
> Friedel wrote:
> > 3) changing resolutions causes mpeg encoder stream to become
> > completely inoperable
> 
> > When I switch resolutions in mythtv recording profile, but also via
> > e.g.
> > 
> > v4l2-ctl -d /dev/video1 --set-fmt-video=width=720,height=568
> > 
> > I seem to totally break the encoder. There's no stream any more,
> > 
> > ~> cat /dev/video1
> > cat: /dev/video1: Input/output error
> > 
> > And switching the resolution back doesn't help. Unloading the modules
> > doesn't help either, I have to reboot the box.
> > 
> > dmesg output pastebinned at http://pastebin.com/f4e27757a
> > 
> > Tests were done with a 2.6.32 kernel from ubuntu.
> 
> Which I assume is a vanilla kernel. I might be wrong about this, too.
> 
> I could test with newer drivers or a newer kernel of course, if you
> suspect that the problem might not be fixed yet.
> 
> > Please ask if there's any information you can't easily infer from this
> > mail or the attached logs.
> 
> 
---Zitatende---

-- 
Friedrich Delgado Friedrichs 
 TauPan on Ircnet and Freenode ;)
--
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: [PATCH v2 1/1] HID: ignore afatech 9016

[Jiri Kosina]

On Wed, 13 Jan 2010, Jiri Slaby wrote:

> Let's ignore the device altogether by the HID layer. It's handled
> by dvb-usb-remote driver already.
> 
> By now, FULLSPEED_INTERVAL quirk was used. It probably made things
> better, but the remote controller was still a perfect X killer.
> This was the last user of the particular quirk. So remove the quirk
> as well.
> 
> With input going through dvb-usb-remote, the remote works
> perfectly.
> 
> The device is 15a4:9016.

Pekka, did you have chance to verify whether it works fine also with your 
version of the remote, or you still need the FULLSPEED_INTERVAL quirk on 
your side?

Thanks.

> Signed-off-by: Jiri Slaby 
> Cc: Jiri Kosina 
> Cc: Pekka Sarnila 
> ---
>  drivers/hid/hid-core.c  |1 +
>  drivers/hid/usbhid/hid-core.c   |8 
>  drivers/hid/usbhid/hid-quirks.c |2 --
>  include/linux/hid.h |1 -
>  4 files changed, 1 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 08f8f23..0ae0bfd 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1534,6 +1534,7 @@ static const struct hid_device_id hid_ignore_list[] = {
>   { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_FLAIR) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_302) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_ADS_TECH, 
> USB_DEVICE_ID_ADS_TECH_RADIO_SI470X) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10) },
>   { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_20) },
> diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
> index e2997a8..36a1561 100644
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -938,14 +938,6 @@ static int usbhid_start(struct hid_device *hid)
>  
>   interval = endpoint->bInterval;
>  
> - /* Some vendors give fullspeed interval on highspeed devides */
> - if (hid->quirks & HID_QUIRK_FULLSPEED_INTERVAL &&
> - dev->speed == USB_SPEED_HIGH) {
> - interval = fls(endpoint->bInterval*8);
> - printk(KERN_INFO "%s: Fixing fullspeed to highspeed 
> interval: %d -> %d\n",
> -hid->name, endpoint->bInterval, interval);
> - }
> -
>   /* Change the polling interval of mice. */
>   if (hid->collection->usage == HID_GD_MOUSE && 
> hid_mousepoll_interval > 0)
>   interval = hid_mousepoll_interval;
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 38773dc..f2ae8a7 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -41,8 +41,6 @@ static const struct hid_blacklist {
>   { USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD, 
> HID_QUIRK_BADPAD },
>   { USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD 
> },
>  
> - { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, 
> HID_QUIRK_FULLSPEED_INTERVAL },
> -
>   { USB_VENDOR_ID_PANTHERLORD, 
> USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT | 
> HID_QUIRK_SKIP_OUTPUT_REPORTS },
>   { USB_VENDOR_ID_PLAYDOTCOM, USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII, 
> HID_QUIRK_MULTI_INPUT },
>  
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 8709365..4a33e16 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -311,7 +311,6 @@ struct hid_item {
>  #define HID_QUIRK_BADPAD 0x0020
>  #define HID_QUIRK_MULTI_INPUT0x0040
>  #define HID_QUIRK_SKIP_OUTPUT_REPORTS0x0001
> -#define HID_QUIRK_FULLSPEED_INTERVAL 0x1000
>  #define HID_QUIRK_NO_INIT_REPORTS0x2000
>  
>  /*
> -- 
> 1.6.5.7
> 

-- 
Jiri Kosina
SUSE Labs, Novell Inc.
--
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: [Bugme-new] [Bug 15087] New: hauppauge nova-t 500 remote controller cause usb halt with Via usb controller

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Mon, 18 Jan 2010 21:06:57 GMT
bugzilla-dae...@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=15087
> 
>Summary: hauppauge nova-t 500 remote controller cause usb halt
> with Via usb controller
>Product: Drivers
>Version: 2.5
> Kernel Version: 2.6.32
>   Platform: All
> OS/Version: Linux
>   Tree: Mainline
> Status: NEW
>   Severity: blocking
>   Priority: P1
>  Component: USB
> AssignedTo: g...@kroah.com
> ReportedBy: fuffi.il.fu...@gmail.com
> Regression: Yes
> 
> 
> This is a know problem with this dvb-t card.
> If the ir receiver is disabled via modprobe option (adding this parameter in
> modprobe.conf: "#options dvb_usb disable_rc_polling=1") I cannot use it but 
> the
> card works perfectly, but if I try to activate it (removing that option) and i
> launch the lircd daemon, I obtain a "usb halt" as described below in this old
> message in the linux-media ml.
> 
> klogd: ehci_hcd :04:00.2: force halt; handhake f8018014 4000
>  -> -110
> 
> Here, the writer find the commit that cause this regression:
> http://osdir.com/ml/linux-media/2009-08/msg00185.html
> Here is explained when it was introduced:
> http://osdir.com/ml/linux-media/2009-08/msg00182.html
> 
> It seems that this problem is present only with a via usb controller,
> unfortunately i have this one:
> 
>  lspci | grep -i via
> 01:08.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
> Controller (rev 62)
> 01:08.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1
> Controller (rev 62)
> 01:08.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65)
> 
> Tell me if you need additional info.
> I'm using a 2.6.32 kernel on arch linux.
> Other relevant modprobe options:
> options dib3000mc buggy_sfn_workaround=1
> options dib7000p buggy_sfn_workaround=1
> alias net-pf-10 off
> 

This is a regression.  You have to chase links a bit, but it was
bisected down to a particular commit in
http://linuxtv.org/hg/v4l-dvb/rev/561b447ade77.
--
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: More details on Hauppauge 930C

[Devin Heitmueller]

On Mon, Jan 25, 2010 at 6:13 PM, Jakob Bohm  wrote:
> Thanks for posting this info on list.  Could someone with access please
> update the relevant pages at wiki.linuxtv.org?

Jakob,

Since you took all the time to do the research, I would suggest that
*you* update the wiki.  All you need to do is create yourself an
account.

Cheers,

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: More details on Hauppauge 930C

[Jakob Bohm]

On Mon, Jan 25, 2010 at 08:58:17AM +0100, Markus Rechberger 
 wrote:
> On Mon, Jan 25, 2010 at 3:11 AM, Jakob Bohm  
> wrote:
> > So far all the posts I have been able to find about this device on
> > wiki.linuxtv.org and in the archives of the linux-tv, linux-dvb
> > and linux-media mailing lists have been unconfirmed guesswork of
> > the form "I think", "Isn't that" etc.  I actually have this device
> > (it was the first DVB-C device to hit the market in Denmark after
> > our biggest cable TV provider offered unencrypted access to their
> > basic packages in DVB-C format for anyone with a paid physical
> > connection to their network).
> >
> > Ok, first the bad news:
> >
> > When looking inside the device I see two Micronas chips,
> > thus *apparantly* confirming the rumors about this device being
> > based on the Micronas chips for which Micronas lawyers blocked
> > release of an already written FOSS driver back in 2008.
> > But to be sure these are the "banned" chips, someone in the know
> > should look closely at the photos I have taken of the actual chips
> > in the 930C.
> >
> > Second bad news: When asking Hauppauge all the response I got was
> > "You need to post on the www.linuxtv.org site, that's where the
> > devlopers are" (and thats all the e-mail said, including the
> > spelling mistake in "devlopers").
> >
> > Now the observable facts:
> >
> > 1. Product name is Hauppauge 930C, model 16009 LF Rev B1F0, USB ID
> > 2040:1605 .  Retail package includes device, a short video cable
> > adapter for the minisocket on the device, an IR remote, a small
> > table-top retractable antenna and a CD with MS-Windows software
> > and drivers.
> >
> > 2. Device is a combined DVB-C/DVB-T receiver with additional
> > inputs for raw analog video as S-VHS or composite (either with
> > separate analog stereo sound).  I do not recall if the device has
> > support for analog TV reception too.
> >
> > 3. Device is not yet listed in the device tables at linuxtv.org
> > with any status (not even "doesn't work").
> >
> > 4. Device is a large (= wide body) USB stick, with a standard size
> > coaxial antenna input at the back, two indicator LEDs and an IR
> > receiver on the right and a proprietary mini-socket for analog
> > video/audio input on the left.  The underside has a sticker with
> > bar code, model number and MAC address.
> >
> > 4. I have taken close up photos of the device with and without the
> > covers off.  The inside of the device holds two circuit boards
> > with some components hidden between them, I have taken photos
> > or the outward facing sides of the two boards.
> >
> > I have posted the photos at these URLs:
> >
> > 
> > 
> > 
> > 
> >
> > (Please copy the photos to your own archives, these are temporary
> > URLs).
> >
> > And finally something worth investigating:
> >
> > Some time has passed since Micronas Lawyers blocked the release of
> > the FOSS driver for their chipset, maybe they have cooled down now
> > and someone from the linuxtv project could approach Hauppauge or
> > Pinacle (who seem FOSS-friendly) to put business pressure on their
> > chipset supplier Micronas to reverse their decision and permit the
> > release of the FOSS driver that was previously developped in
> > cooperation between Pinacle, Micronas techs and Devin Heitmueller
> > (one of the linuxtv developers).
> >
> >
> 
> It hasn't been in Micronas hands for a long time anymore. Micronas had
> financial trouble
> and sold this devision to Trident.
> So far we (Sundtek) found an agreement to publish their propriertary
> work under closed source but with support for
> opensource applications in Linux in userspace not affecting the kernel.
> 

Thanks for posting this info on list.  Could someone with access please
update the relevant pages at wiki.linuxtv.org?

Sincerely

Jakob Bohm

-- 
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
--
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: [PATCH] dvb-apps/util/szap/czap.c "ERROR: cannot parse service data"

[klaas de waal]

On Sun, Jan 24, 2010 at 10:14 PM, Manu Abraham  wrote:
> Hi Klaas,
>
> On Sun, Jan 24, 2010 at 2:58 PM, klaas de waal  
> wrote:
>> The czap utility (dvb-apps/util/szap/czap.c) cannot scan the channel
>> configuration file when compiled on Fedora 12 with gcc-4.4.2.
>>
>> The czap output is:
>>
>> [kl...@myth2 szap]$ ./czap -c ~/.czap/ziggo-channels.conf Cartoon
>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>> reading channels from file '/local/klaas/.czap/ziggo-channels.conf'
>>  1 Cartoon:35600:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:1660:1621
>> ERROR: cannot parse service data
>>
>> Problem is tha the "sscanf" function uses the "%a[^:]" format
>> specifier. According to "man sscanf" you need to define _GNU_SOURCE if
>> you want this to work because it is a gnu-only extension.
>> Adding a first line "#define _GNU_SOURCE" to czap.c and recompiling
>> solves the problem.
>>
>> The czap output is now:
>>
>> [kl...@myth2 szap]$ ./czap -c ~/.czap/ziggo-channels.conf Cartoon
>> using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
>> reading channels from file '/local/klaas/.czap/ziggo-channels.conf'
>>  1 Cartoon:35600:INVERSION_AUTO:6875000:FEC_NONE:QAM_64:1660:1621
>>  1 Cartoon: f 35600, s 6875000, i 2, fec 0, qam 3, v 0x67c, a 0x655
>> status 00 | signal  | snr b7b7 | ber 000f | unc 0098 |
>> status 1f | signal d5d5 | snr f3f3 | ber 06c0 | unc 009b | 
>> FE_HAS_LOCK
>> status 1f | signal d5d5 | snr f4f4 | ber  | unc  | 
>> FE_HAS_LOCK
>>
>> This is done on a Linux 2.6.32.2 kernel with a TT C-1501 DVB-C card.
>>
>> Signed-off-by: Klaas de Waal 
>>
>> ---
>>
>> diff -r 61b72047a995 util/szap/czap.c
>> --- a/util/szap/czap.c  Sun Jan 17 17:03:27 2010 +0100
>> +++ b/util/szap/czap.c  Sun Jan 24 11:40:43 2010 +0100
>> @@ -1,3 +1,4 @@
>> +#define _GNU_SOURCE
>>  #include 
>>  #include 
>>  #include 
>>
>
> There seems to be other instances where _GNU_SOURCE needs to be
> defined, from a quick look. Care to send a patch against the entire
> dvb-apps tree ?
>
> Regards,
> Manu
>

Hi Manu,

I did have a reasonably good look at the code and at the compilation
log created with "-pedantic" added to the CFLAGS but although there
are a lot of GNU extensions used I think they will compile correct. I
do not think that the _GNU_SOURCE definitions need to be added
anywhere.

Having said that, I am not even happy anymore with the _GNU_SOURCE in
czap.c although it does solve the problem.

I have now added "std=gnu99 -Wformat" to the default CFLAGS in
Make.rules. This flags the use of the "a" format specifier as used in
the sscanf statement in czap.c as an error, although it works when
_GNU_SOURCE is defined.
I have now modified the czap.c to use the "m" format specifier which
does just what the 'a" used to do.
This works OK, it does not give compilation messages and it does not
require _GNU_SOURCE so I think it is a better solution. Hope you like
it.

Regards,
Klaas.

Signed-off-by: Klaas de Waal 

---

diff -r 61b72047a995 Make.rules
--- a/Make.rulesSun Jan 17 17:03:27 2010 +0100
+++ b/Make.rulesMon Jan 25 22:27:05 2010 +0100
@@ -1,6 +1,7 @@
 # build rules for linuxtv.org dvb-apps

-CFLAGS ?= -g -Wall -W -Wshadow -Wpointer-arith -Wstrict-prototypes
+CFLAGS ?= -g -Wall -W -Wshadow -Wpointer-arith -Wstrict-prototypes \
+-std=gnu99 -Wformat

 ifneq ($(lib_name),)

diff -r 61b72047a995 util/szap/czap.c
--- a/util/szap/czap.c  Sun Jan 17 17:03:27 2010 +0100
+++ b/util/szap/czap.c  Mon Jan 25 22:27:05 2010 +0100
@@ -141,7 +141,7 @@
}
printf("%3d %s", chan_no, chan);

-   if ((sscanf(chan, "%a[^:]:%d:%a[^:]:%d:%a[^:]:%a[^:]:%d:%d\n",
+   if ((sscanf(chan, "%m[^:]:%d:%m[^:]:%d:%m[^:]:%m[^:]:%d:%d\n",
&name, &frontend->frequency,
&inv, &frontend->u.qam.symbol_rate,
&fec, &mod, vpid, apid) != 8)
--
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: Terratec Cinergy Hybrid XE (TM6010 Mediachip)

[Stefan Ringel]

Am 25.01.2010 20:55, schrieb Mauro Carvalho Chehab:
> Stefan Ringel wrote:
>   
>> Am 25.01.2010 20:29, schrieb Mauro Carvalho Chehab:
>> 
>>> Stefan Ringel wrote:
>>>   
>>>   
 Am 25.01.2010 15:35, schrieb Mauro Carvalho Chehab:
 
 
> Stefan Ringel wrote:
>   
>   
>   
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>  
>> Hi Davin,
>> I have a question. How are loaded the base firmware into xc3028, in
>> once or in a split ? It's importent for TM6010, the USB-Analyzer said
>> that it load it in once and then send a quitting reqeuest.
>> 
>> 
>> 
> The way the original driver for tm6000/tm6010 does varies from firmware
> version to firmware version. That part of the driver works fine for
> both tm6000 and tm6010, with the devices I used here, with firmwares 1.e 
> and 2.7. However, on tm6000, it sends the firmware on packages with
> up to 12 or 13 bytes, and it requires a delay before sending the next
> packet, otherwise the tm6000 hangs.
>
> Another problem is that the firmware load may fail (due to the bad
> implementation of the i2c on tm6000/tm6010). So, the code should ideally
> check if the firmware were loaded, by reading the firmware version at the
> end. However, reading from i2c is very problematic, since it sometimes
> read from the wrong place. On the tests I did here, the original drivers
> weren't reading back the firmware version, probably due to this bug.
>   
>   
>   
 My hybrid-stick with tm6010 chip use a special request ( requests 0x32 +
 0x33) for quitting i2c transfer.
 
 
>>> Someone once commented that there are some procedures to reset I2C bank
>>> on tm6010. Maybe that's the meaning for the requests to 0x32/0x33.
>>>
>>>   
>>>   
 so it can write correct the firmware
 and can read tuner number and versions. Actually I tested next patch for
 sync between tuner and demodulator and I have data by scanning digital
 channels (one time), but  other test dos not data. I've test firmware
 load 13, 64  and 3500 bytes and all works.
 
 
>>> 3500? That's weird! the maximum allowed size for URB control transfer is 80.
>>>   
>>>   
>> from xc3028 send max 3500 byte and then in i2c_xfer function it split to
>> 80 byte.
>> for example
>>
>> xc3028 --> 3500 byte  --> quit (base firmware subaddresse 0x2a 3411 byte)
>> tm6000_i2c_xfer --> 80 byte 80 byte  80 byte ---> quit
>> 
> Well, the better is to limit the size at xc3028 level, just like the other 
> drivers.
> I'm afraid that letting it pass 3500 bytes will cause kernel hangups on some
> drivers that aren't prepared for it.
>
> Cheers,
> Mauro.
>   
Hi,

I found digital channel second time today, Last Saturday I found first
time. But it has over hack demodulator.

Cheers

Stefan Ringel



-- 
Stefan Ringel 

linux-v5dy:/usr/src/src/tm6000/v4l-dvb # scan /usr/share/dvb/dvb-t/de-Berlin 
scanning /usr/share/dvb/dvb-t/de-Berlin  
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'   
initial transponder 17750 1 3 9 1 2 4 0  
initial transponder 19150 1 2 9 1 2 4 0  
initial transponder 50600 0 2 9 1 2 4 0  
initial transponder 52200 0 2 9 1 2 4 0  
initial transponder 57000 0 2 9 1 2 4 0  
initial transponder 61800 0 2 9 3 2 4 0  
initial transponder 65800 0 2 9 1 2 4 0  
initial transponder 75400 0 2 9 1 2 4 0  
initial transponder 77800 0 2 9 1 2 4 0  
initial transponder 61800 0 1 9 1 2 4 0  
>>> tune to: 
>>> 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_16:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE
WARNING: filter timeout pid 0x0011  
   
WARNING: filter timeout pid 0x  
   
WARNING: filter timeout pid 0x0010  
   
>>> tune to: 
>>> 19150:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_NONE
WARNING: filter timeout pid 0x0011  
   
WARNING: filter timeout pid 0x  
   
WA

Re: Remote for Terratec Cinergy C PCI HD (DVB-C)

[MartinG]

On Mon, Jan 25, 2010 at 9:22 PM, MartinG  wrote:
> Hi, I've got the exact same device as you, use the s2-liplianin
> driver, and after reading your post I tried the remote as well.
> But how do I configure it? Some of the keys are working (arrow keys,
> numeric keys, Home, volume, mute), but not all.
> Is the remote handled as an input device by X itself? So what file(s)
> do I need to change/update?
>
> If you have some working config files, or a nice link, I'd appreciate it :)

Replying to myself; I found that 'xev' give the keycodes for most of
the keys, but not eg. the "OK" key, wich is quite important. Is there
a way to add those? Something I can contribute? Where? :)

And by the way - I too really appreciate the work on the mantis driver!

Best,
MartinG
--
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: Remote for Terratec Cinergy C PCI HD (DVB-C)

[MartinG]

On Thu, Jan 21, 2010 at 6:33 PM, Hans-Peter Wolf
 wrote:
> Hi,
>
> I got it finally running! I just took the last s2-liplianin source and it
> was detected automatically:
>
> I: Bus=0001 Vendor= Product= Version=0001
> N: Name="Mantis VP-2040 IR Receiver"
> P: Phys=pci-:01:06.0/ir0
> S: Sysfs=/devices/virtual/input/input5
> U: Uniq=
> H: Handlers=kbd event5
> B: EV=13
> B: KEY=108fc330 2842041 0 200018000 21804801 9e96c0
> ffc
>
> Strange, that it didn't work with v4l-dvb sources.
>
> Thank you very much. I really appreciate your work!


Hi, I've got the exact same device as you, use the s2-liplianin
driver, and after reading your post I tried the remote as well.
But how do I configure it? Some of the keys are working (arrow keys,
numeric keys, Home, volume, mute), but not all.
Is the remote handled as an input device by X itself? So what file(s)
do I need to change/update?

If you have some working config files, or a nice link, I'd appreciate it :)

Best,
MartinG
--
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: Drivers for Eyetv hybrid

[Devin Heitmueller]

On Mon, Jan 25, 2010 at 3:05 PM, Morten Friesgaard  wrote:
> Sound like a lot of work, and it would be easier just to buy a
> functional tuner :)
>
> Guess I'm busy enough. However, I did manage to find some more info,
> for someone to use someday :)
> /Morten
>
> Model: EU 2008
> USB Contoller: Empia EM2884
> Stereo A/V Decoder: Micronas AVF 49x08
> Hybrid Channel Decoder: Micronas DRX-K DRX3926K:A1 0.9.0

Correct, this is an em2884/drx-k/xc5000 design.  The em2884 work is
pretty straightforward, and the xc5000 driver should work "as-is".
The big issue is the drx-k driver, for which there is no currently
driver at all.

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: Drivers for Eyetv hybrid

[Morten Friesgaard]

Sound like a lot of work, and it would be easier just to buy a
functional tuner :)

Guess I'm busy enough. However, I did manage to find some more info,
for someone to use someday :)
/Morten

Model: EU 2008
USB Contoller: Empia EM2884
Stereo A/V Decoder: Micronas AVF 49x08
Hybrid Channel Decoder: Micronas DRX-K DRX3926K:A1 0.9.0

On Fri, Jan 22, 2010 at 5:27 PM, Devin Heitmueller
 wrote:
> On Fri, Jan 22, 2010 at 11:18 AM, Morten Friesgaard
>  wrote:
>> Actually I don't understand why this em28xx driver is the only one
>> being patched, guess that reduces backward compability!? :-P
>
> There are many drivers actively being developed.  What I'm trying to
> say is that the new version of the EyeTV Hybrid is not an em28xx based
> hardware design.
>
>> Well, I haven't given up, but no one has given me any pointers but /dev/null
>> If this em28xx module would be startable with the usb id "0fd9:0018",
>> I could tryout the old driver.
>> If you say the hardware design is completely different, I guess it
>> should still be possible to mount the usb device and fetch anything
>> from the device (e.g. tvtime -d /dev/usbdev). The driver would be a
>> matter of controlling the device to tune to the correct channel etc.
>
> No, that is not how USB drivers work.  You have to know how to program
> the various chips on the device (the bridge, demodulator, decoder,
> tuner), as well as knowing how to decode the packets coming back from
> the device.  If you want to get an understanding as to how complex the
> drivers are then feel free to look at some of them in the v4l-dvb
> source code.  You can get a better understanding as to how these
> devices are designed here:
>
> KernelLabs Blog:  How Tuners Work...
> http://www.kernellabs.com/blog/?p=1045
>
>> When new hardware is introduced, how do you guys break down the task
>> and implement a driver? (how much can be borrow from the mac os x
>> drivers?)
>
> It largely depends on the device.  Usually you start by cracking it
> open and seeing what chips it contains, and from there you can see
> which components currently have a driver and which do not.  Whether
> the various components are already supported usually drives whether a
> whole new driver is required or just a board profile in an existing
> driver.  And whether datasheets are available publicly dictates how
> easy/hard it is to write a driver (the datasheets are usually *not*
> available for modern devices, or only available under NDA).
>
> 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: git problem with uvcvideo

[Németh Márton]

Laurent Pinchart wrote:
> Hi Márton,
> 
> On Sunday 24 January 2010 22:31:29 Németh Márton wrote:
>> Hi,
>>
>> I'm trying to fetch the uvcvideo from
>>  http://linuxtv.org/git/?p=pinchartl/uvcvideo.git;a=summary .
>>
>> I tryied to follow the instructions but at the third step I get fatal error
>> messages:
> 
> [snip]
> 
> The http:// URL seems not to be available at the moment. I don't know if it's 
> a transient error or a deliberate decision not to provide git access through 
> http://
> 
>> I also tried with the git:// link:
>>> v4l-dvb$ git remote rm uvcvideo
>>> v4l-dvb$ git remote add uvcvideo git://linuxtv.org//pinchartl/uvcvideo.git
>>> v4l-dvb$ git remote update
>>> Updating origin
>>> Updating uvcvideo
>>> fatal: The remote end hung up unexpectedly
>>> error: Could not fetch uvcvideo
>> Am I doing something wrong?
> 
> Please try git://linuxtv.org/pinchartl/uvcvideo.git. The URL on the webpage 
> has two / instead of one for some reason. Mauro, could that be fixed ?

It seems removing the extra '/' helps:

v4l-dvb$ git remote rm uvcvideo
v4l-dvb$ git remote add uvcvideo git://linuxtv.org/pinchartl/uvcvideo.git
v4l-dvb$ git remote update
Updating origin
Updating uvcvideo
remote: Counting objects: 1944, done.
remote: Compressing objects: 100% (427/427), done.
remote: Total 1733 (delta 1486), reused 1551 (delta 1306)
Receiving objects: 100% (1733/1733), 312.47 KiB | 164 KiB/s, done.
Resolving deltas: 100% (1486/1486), completed with 169 local objects.
>From git://linuxtv.org/pinchartl/uvcvideo
 * [new branch]  master -> uvcvideo/master
 * [new branch]  uvcvideo   -> uvcvideo/uvcvideo
v4l-dvb$ git branch -r
  origin/HEAD -> origin/master
  origin/master
  uvcvideo/master
  uvcvideo/uvcvideo
v4l-dvb$ git checkout -b test uvcvideo/uvcvideo
Branch test set up to track remote branch uvcvideo from uvcvideo.
Switched to a new branch 'test'


Now I can start to build and test this branch.

Regards,

Márton Németh


--
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: git problem with uvcvideo

[Mauro Carvalho Chehab]

Laurent Pinchart wrote:
> Hi Márton,
> 
> On Sunday 24 January 2010 22:31:29 Németh Márton wrote:
>> Hi,
>>
>> I'm trying to fetch the uvcvideo from
>>  http://linuxtv.org/git/?p=pinchartl/uvcvideo.git;a=summary .
>>
>> I tryied to follow the instructions but at the third step I get fatal error
>> messages:
> 
> [snip]
> 
> The http:// URL seems not to be available at the moment. I don't know if it's 
> a transient error or a deliberate decision not to provide git access through 
> http://

No, it is not a decision. However, using http for -git has some issues.

>> I also tried with the git:// link:
>>> v4l-dvb$ git remote rm uvcvideo
>>> v4l-dvb$ git remote add uvcvideo git://linuxtv.org//pinchartl/uvcvideo.git
>>> v4l-dvb$ git remote update
>>> Updating origin
>>> Updating uvcvideo
>>> fatal: The remote end hung up unexpectedly
>>> error: Could not fetch uvcvideo
>> Am I doing something wrong?
> 
> Please try git://linuxtv.org/pinchartl/uvcvideo.git. The URL on the webpage 
> has two / instead of one for some reason. Mauro, could that be fixed ?

The double bars were causing troubles with the git: url. 
I've fixed it at gitweb.

The git URL is working fine:

$ git clone -l --bare /git/linux-2.6.git/ uvcvideo && cd uvcvideo && git remote 
add uvcvideo git://linuxtv.org/pinchartl/uvcvideo.git && git remote update
Initialized empty Git repository in /home/mchehab/tst/uvcvideo/
Updating uvcvideo
remote: Counting objects: 1944, done.
remote: Compressing objects: 100% (427/427), done.
remote: Total 1733 (delta 1486), reused 1551 (delta 1306)
Receiving objects: 100% (1733/1733), 312.46 KiB, done.
Resolving deltas: 100% (1486/1486), completed with 169 local objects.
>From git://linuxtv.org/pinchartl/uvcvideo
 * [new branch]  master -> uvcvideo/master
 * [new branch]  uvcvideo   -> uvcvideo/uvcvideo

However, the html URL is currently broken:

$ rm -rf uvcvideo/ && git clone -l --bare /git/linux-2.6.git/ uvcvideo && cd 
uvcvideo && git remote add uvcvideo 
http://linuxtv.org/git/pinchartl/uvcvideo.git && git remote update 
Initialized empty Git repository in /home/mchehab/tst/uvcvideo/uvcvideo/
Updating uvcvideo

Probably, the rewrite rules at the server for http are incomplete. I'll see if 
I can fix it.

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

Fwd: Re: FM radio problem with HVR1120

[ftape-jlc]

Hello,

I didn't received any message about radio on HVR1120.
I just want to know if the use /dev/radio0 is deprecated in v4l2 today.
In the mails, I only read messages about video or TV.

Did one user of the mailing list have tested actual v4l2 on /dev/radio0 ?

Thank you for your help,

Regards,

ftape-jlc

Le lundi 11 janvier 2010, ftape-jlc a écrit :
> Hello,
> 
> I am user of Huappuage HVR1120, and I have problem with radio FM use in
>  linux mode.
> 
> Distribution OpenSuse11.2
> Kernel 2.6.31.8-0.1-desktop
> Firmware dvb-fe-tda10048-1.0.fw loaded
> 
> Analog and Digital Television are OK in both Windows and Linux.
> Windows is using Hauppauge WinTV7 v7.027313
> 
> Linux is using Kaffeine v1.0-pre2 for Digital Television
> Linux is using mplayer for analog TV like:
> mplayer tv:// -tv driver=v4l2:freq=495.750:norm=SECAM-
> L:input=0:audiorate=32000:immediatemode=0:alsa:forceaudio:adevice=hw.1,0:wi
> dth=720:height=576:amode=1
> 
> The problem is to listen radio.
> One radio station is OK at 91.5MHz stereo using WintTV7 in Windows.
> With Linux, the command used is
> /usr/bin/radio -c /dev/radio0
> in association with
> sox -t ossdsp -r 32000 -c 2 /dev/dsp1 -t ossdsp /dev/dsp
> to listen the sound.
> 
> The result is an unstable frecuency. The station is not tuned. Stereo is
> permanently switching to mono.
> The 91.5MHz station is mixed permanently with other stations.
> 
> How can I check v4l2 ?
> Do you need dmesg output ?
> Is this mailing list the right place to solve this problem ?
> 
> Thank you for your help.
> 
> Regards,
> 
> ftape-jlc
> 
> 
> --
> 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
> 


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


---

--
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: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes

[Antti Palosaari]

On 01/25/2010 11:12 AM, Jiri Slaby wrote:

On 01/25/2010 12:44 AM, Antti Palosaari wrote:

When I now test this patch with debugs enabled I don't see
.probe and .disconnect be called for this HID interface (interface 1) at
all and thus checks not needed.


What happens if you disable the HID layer? Or at least if you add an
ignore quirk for the device in usbhid?


Looks like Fedora doesn't have usbhid compiled as module. I looked 
hid-quirks.c file and there was only one af9015 device blacklisted 
15a4:9016. I have 15a4:9015, 15a4:9016 and 13d3:3237 devices and no 
difference.


How can I disable HID layer?


I forbid usbhid to attach to the device, as the remote kills X with HID
driver. With dvb-usb-remote it works just fine (with remote=2 for af9015
or the 4 patches I've sent).


In my understanding the cause of the remote problem is chipset bug which 
sets USB2.0 polling interval to 4096ms. Therefore HID remote does not 
work at all or starts repeating. It is possible to implement remote as 
polling from the driver which works very well. But HID problem still 
remains. I have some hacks in my mind to test to kill HID. One is to 
configure HID wrongly to see if it stops outputting characters. Other 
way is try to read remote codes directly from the chip memory.


But all in all, your patch does not break anything, it is safe to add. 
It could be still nice to know if there is better alternatives. And 
there is surely few other devices having HID remote - are those also 
affected.


regards
Antti
--
http://palosaari.fi/
--
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: git problem with uvcvideo

[Laurent Pinchart]

Hi Márton,

On Sunday 24 January 2010 22:31:29 Németh Márton wrote:
> Hi,
> 
> I'm trying to fetch the uvcvideo from
>  http://linuxtv.org/git/?p=pinchartl/uvcvideo.git;a=summary .
> 
> I tryied to follow the instructions but at the third step I get fatal error
> messages:

[snip]

The http:// URL seems not to be available at the moment. I don't know if it's 
a transient error or a deliberate decision not to provide git access through 
http://

> I also tried with the git:// link:
> > v4l-dvb$ git remote rm uvcvideo
> > v4l-dvb$ git remote add uvcvideo git://linuxtv.org//pinchartl/uvcvideo.git
> > v4l-dvb$ git remote update
> > Updating origin
> > Updating uvcvideo
> > fatal: The remote end hung up unexpectedly
> > error: Could not fetch uvcvideo
> 
> Am I doing something wrong?

Please try git://linuxtv.org/pinchartl/uvcvideo.git. The URL on the webpage 
has two / instead of one for some reason. Mauro, could that be fixed ?

-- 
Regards,

Laurent Pinchart
--
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: Problems with cx18

[Devin Heitmueller]

On Mon, Jan 25, 2010 at 11:45 AM, Theodore Kilgore
 wrote:
>
>
> On Mon, 25 Jan 2010, Mauro Carvalho Chehab wrote:
>
>> Hi Devin/Andy/Jean,
>
> 
>
>> The sq905c has a warning.
>
> 
>
>> drivers/media/video/gspca/sq905c.c: In function ?sd_config?:
>> drivers/media/video/gspca/sq905c.c:207: warning: unused variable ?i?
>
> 
>
>> Please fix.
>>
>> Cheers,
>> Mauro.
>
> This one has been fixed, already. A more recent version of sq905c.c is in
> the pipeline somewhere.
>
> Theodore Kilgore

Not intending to hijack this thread, but maybe it would be a good idea
for Hans's nightly rig to do a build with module support disabled on
at least one platform.  I'm not saying we should do it on all
platforms, but if we at least run it on x86 then we would spot this
class of issue earlier.

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: Problems with cx18

[Theodore Kilgore]

On Mon, 25 Jan 2010, Mauro Carvalho Chehab wrote:


Hi Devin/Andy/Jean,





The sq905c has a warning.





drivers/media/video/gspca/sq905c.c: In function ?sd_config?:
drivers/media/video/gspca/sq905c.c:207: warning: unused variable ?i?





Please fix.

Cheers,
Mauro.


This one has been fixed, already. A more recent version of sq905c.c is in 
the pipeline somewhere.


Theodore Kilgore
--
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: Terratec Cinergy Hybrid XE (TM6010 Mediachip)

[Stefan Ringel]

Am 25.01.2010 15:35, schrieb Mauro Carvalho Chehab:
> Stefan Ringel wrote:
>   
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>  
>> Hi Davin,
>> I have a question. How are loaded the base firmware into xc3028, in
>> once or in a split ? It's importent for TM6010, the USB-Analyzer said
>> that it load it in once and then send a quitting reqeuest.
>> 
> The way the original driver for tm6000/tm6010 does varies from firmware
> version to firmware version. That part of the driver works fine for
> both tm6000 and tm6010, with the devices I used here, with firmwares 1.e 
> and 2.7. However, on tm6000, it sends the firmware on packages with
> up to 12 or 13 bytes, and it requires a delay before sending the next
> packet, otherwise the tm6000 hangs.
>
> Another problem is that the firmware load may fail (due to the bad
> implementation of the i2c on tm6000/tm6010). So, the code should ideally
> check if the firmware were loaded, by reading the firmware version at the
> end. However, reading from i2c is very problematic, since it sometimes
> read from the wrong place. On the tests I did here, the original drivers
> weren't reading back the firmware version, probably due to this bug.
>   
My hybrid-stick with tm6010 chip use a special request ( requests 0x32 +
0x33) for quitting i2c transfer. so it can write correct the firmware
and can read tuner number and versions. Actually I tested next patch for
sync between tuner and demodulator and I have data by scanning digital
channels (one time), but  other test dos not data. I've test firmware
load 13, 64  and 3500 bytes and all works.

Cheers,

Stefan Ringel

-- 
Stefan Ringel 

--
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: [ANNOUNCE] git tree repositories & libv4l

[Hans de Goede]

Hi,

On 01/24/2010 01:42 AM, Mauro Carvalho Chehab wrote:

Hans de Goede wrote:

Hi,

On 01/21/2010 08:23 AM, Hans Verkuil wrote:







Yes, but, as we have also non-c code, some rules there don't apply.
For example the rationale for not using // comments don't apply to c++,
since it is there since the first definition.


Most apps are already in 'kernel' style. The main exception being libv4l.


Well... they are "close" to kernel style, but if you run checkpatch over
all files there, I'm sure you'll see lots of violations.



Ack,

which in hind sight may not have been the best choice (I have no personal
coding style, I'm used to adjusting my style to what ever the project
I'm working on uses).

Still I would like to keep libv4l as an exception,


If we're adopting one CodingStyle, this should be done for everything, otherwise
it makes no sense to standardize.



Ok that makes sense. But as said this need to be done in one big bang commit 
then.

Regards,

Hans
--
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: Problems with cx18

[Devin Heitmueller]

On Mon, Jan 25, 2010 at 10:06 AM, Mauro Carvalho Chehab
 wrote:
> Hi Devin/Andy/Jean,
>
> The cx88-alsa and cx18-drivers are broken: the driver depend of 
> request_modules that doesn't exist
> when !CONFIG_MODULES, and has some wrong __init annotations.
>
> The sq905c has a warning.
>
> I'm compiling it with:
>        make ARCH=i386 allmodconfig drivers/media/|grep -v "^  CC" |grep -v "^ 
>  LD"
>
> Those are the errors found:
>
> drivers/media/video/cx18/cx18-driver.c:252: warning: ‘request_modules’ used 
> but never defined
> WARNING: drivers/media/video/cx18/cx18-alsa.o(.text+0x4de): Section mismatch 
> in reference from the function cx18_alsa_load() to the function 
> .init.text:snd_cx18_init()
> The function cx18_alsa_load() references
> the function __init snd_cx18_init().
> This is often because cx18_alsa_load lacks a __init
> annotation or the annotation of snd_cx18_init is wrong.
>
> WARNING: drivers/media/video/cx18/built-in.o(.text+0x1c022): Section mismatch 
> in reference from the function cx18_alsa_load() to the function 
> .init.text:snd_cx18_init()
> The function cx18_alsa_load() references
> the function __init snd_cx18_init().
> This is often because cx18_alsa_load lacks a __init
> annotation or the annotation of snd_cx18_init is wrong.
>
> drivers/media/video/gspca/sq905c.c: In function ‘sd_config’:
> drivers/media/video/gspca/sq905c.c:207: warning: unused variable ‘i’
> WARNING: drivers/media/video/built-in.o(.text+0x28d24e): Section mismatch in 
> reference from the function cx18_alsa_load() to the function 
> .init.text:snd_cx18_init()
> The function cx18_alsa_load() references
> the function __init snd_cx18_init().
> This is often because cx18_alsa_load lacks a __init
> annotation or the annotation of snd_cx18_init is wrong.
>
> WARNING: drivers/media/built-in.o(.text+0x2d2a2a): Section mismatch in 
> reference from the function cx18_alsa_load() to the function 
> .init.text:snd_cx18_init()
> The function cx18_alsa_load() references
> the function __init snd_cx18_init().
> This is often because cx18_alsa_load lacks a __init
> annotation or the annotation of snd_cx18_init is wrong.

This looks like breakage I probably introduced with the cx18 alsa
support.  I will dig into this tonight.

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

[PATCH] Fix VIDIOC_QBUF compat ioctl32

[Arnaud Patard]

When using VIDIOC_QBUF with memory type set to V4L2_MEMORY_MMAP, the
v4l2_buffer buffer gets unmodified on drivers like uvc (well, only
bytesused field is modified). Then some apps like gstreamer are reusing
the same buffer later to call munmap (eg passing the buffer "length"
field as 2nd parameter of munmap).

It's working fine on full 32bits but on 32bits systems with 64bit
kernel, the get_v4l2_buffer32() doesn't copy length/m.offset values and
then copy garbage to userspace in put_v4l2_buffer32().

This has for consequence things like that in the libv4l2 logs:

libv4l2: v4l2 unknown munmap 0x2e2b, -2145144908
libv4l2: v4l2 unknown munmap 0x2e53, -2145144908

The buffer are not unmap'ed and then if the application close and open
again the device, it won't work and logs will show something like:

libv4l2: error setting pixformat: Device or resource busy

The easy solution is to read length and m.offset in get_v4l2_buffer32().


Signed-off-by: Arnaud Patard 
---
---
 drivers/media/video/v4l2-compat-ioctl32.c |5 	5 +	0 -	0 !
 1 file changed, 5 insertions(+)

Index: linux-2.6/drivers/media/video/v4l2-compat-ioctl32.c
===
--- linux-2.6.orig/drivers/media/video/v4l2-compat-ioctl32.c
+++ linux-2.6/drivers/media/video/v4l2-compat-ioctl32.c
@@ -475,6 +475,9 @@ static int get_v4l2_buffer32(struct v4l2
 			return -EFAULT;
 	switch (kp->memory) {
 	case V4L2_MEMORY_MMAP:
+		if (get_user(kp->length, &up->length) ||
+			get_user(kp->m.offset, &up->m.offset))
+			return -EFAULT;
 		break;
 	case V4L2_MEMORY_USERPTR:
 		{

Problems with cx18

[Mauro Carvalho Chehab]

Hi Devin/Andy/Jean,

The cx88-alsa and cx18-drivers are broken: the driver depend of request_modules 
that doesn't exist
when !CONFIG_MODULES, and has some wrong __init annotations.

The sq905c has a warning.

I'm compiling it with:
make ARCH=i386 allmodconfig drivers/media/|grep -v "^  CC" |grep -v "^  
LD"

Those are the errors found:

drivers/media/video/cx18/cx18-driver.c:252: warning: ‘request_modules’ used but 
never defined
WARNING: drivers/media/video/cx18/cx18-alsa.o(.text+0x4de): Section mismatch in 
reference from the function cx18_alsa_load() to the function 
.init.text:snd_cx18_init()
The function cx18_alsa_load() references
the function __init snd_cx18_init().
This is often because cx18_alsa_load lacks a __init 
annotation or the annotation of snd_cx18_init is wrong.

WARNING: drivers/media/video/cx18/built-in.o(.text+0x1c022): Section mismatch 
in reference from the function cx18_alsa_load() to the function 
.init.text:snd_cx18_init()
The function cx18_alsa_load() references
the function __init snd_cx18_init().
This is often because cx18_alsa_load lacks a __init 
annotation or the annotation of snd_cx18_init is wrong.

drivers/media/video/gspca/sq905c.c: In function ‘sd_config’:
drivers/media/video/gspca/sq905c.c:207: warning: unused variable ‘i’
WARNING: drivers/media/video/built-in.o(.text+0x28d24e): Section mismatch in 
reference from the function cx18_alsa_load() to the function 
.init.text:snd_cx18_init()
The function cx18_alsa_load() references
the function __init snd_cx18_init().
This is often because cx18_alsa_load lacks a __init 
annotation or the annotation of snd_cx18_init is wrong.

WARNING: drivers/media/built-in.o(.text+0x2d2a2a): Section mismatch in 
reference from the function cx18_alsa_load() to the function 
.init.text:snd_cx18_init()
The function cx18_alsa_load() references
the function __init snd_cx18_init().
This is often because cx18_alsa_load lacks a __init 
annotation or the annotation of snd_cx18_init is wrong.

Please fix.

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: Terratec Cinergy Hybrid XE (TM6010 Mediachip)

[Mauro Carvalho Chehab]

Stefan Ringel wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>  
> Hi Davin,
> I have a question. How are loaded the base firmware into xc3028, in
> once or in a split ? It's importent for TM6010, the USB-Analyzer said
> that it load it in once and then send a quitting reqeuest.

The way the original driver for tm6000/tm6010 does varies from firmware
version to firmware version. That part of the driver works fine for
both tm6000 and tm6010, with the devices I used here, with firmwares 1.e 
and 2.7. However, on tm6000, it sends the firmware on packages with
up to 12 or 13 bytes, and it requires a delay before sending the next
packet, otherwise the tm6000 hangs.

Another problem is that the firmware load may fail (due to the bad
implementation of the i2c on tm6000/tm6010). So, the code should ideally
check if the firmware were loaded, by reading the firmware version at the
end. However, reading from i2c is very problematic, since it sometimes
read from the wrong place. On the tests I did here, the original drivers
weren't reading back the firmware version, probably due to this bug.

Cheers,
Mauro.

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>  
> iQEcBAEBAgAGBQJLVH6/AAoJEDX/lZlmjdJlA/0H/jkn4I3kELEWPeDDYJvv/+Z0
> LsSLzmDJmQ0WgASjtJQ2QZvsDeuCsbzV9mTHGvI0dOGtOLqcBuMX58ZFTerZodrG
> b/KdwZa2OV0MWXc+5hf2+3wEC1icfMATKiwsT3gLdvP9En4MtUP8ImaXFWwW7ekL
> aH5TD666nGewj4+Ef5eVY0G+FypqzNcs4F04uY5ydBaVDh5XTONhXPaLz/R5JF0K
> ivKT4WL7n8A7bq8iAn6SoMJRV/RbEpGF40m4aApVDd+JdizFIH7xrTGQ4waQO6IN
> mplAcxIhq6bEHhwZRfbbnTNMTWUVPShqqqxC5Z0TxCiUR0RH6JdXagQtw/1/UX0=
> =Qqmr
> -END PGP SIGNATURE-
> 
> --
> 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

--
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: [Patch 2/3] Kworld 315U

[Mauro Carvalho Chehab]

Franklin Meng wrote:
> Patch with updated GPIOs and enable analog inputs for the Kworld 315U
> 
> Signed-off-by: Franklin Meng

Also, didn't apply.

Cheers,
Mauro.

> 
> diff -r b6b82258cf5e linux/drivers/media/video/em28xx/em28xx-cards.c
> --- a/linux/drivers/media/video/em28xx/em28xx-cards.c   Thu Dec 31 19:14:54 
> 2009 -0200
> +++ b/linux/drivers/media/video/em28xx/em28xx-cards.c   Sun Jan 17 22:54:21 
> 2010 -0800
> @@ -122,13 +122,31 @@ 
> 
>  };   
> 
>  #endif   
> 
>   
> 
> +/* Kworld 315U   
> 
> +   GPIO0 - Enable digital power (lgdt3303) - low to enable   
> 
> +   GPIO1 - Enable analog power (saa7113/emp202) - low to enable  
> 
> +   GPIO7 - enables something ?   
> 
> +   GOP2  - ?? some sort of reset ?   
> 
> +   GOP3  - lgdt3303 reset
> 
> + */  
> 
>  /* Board - EM2882 Kworld 315U digital */ 
> 
>  static struct em28xx_reg_seq em2882_kworld_315u_digital[] = {
> 
> -   {EM28XX_R08_GPIO,   0xff,   0xff,   10},  
> 
> -   {EM28XX_R08_GPIO,   0xfe,   0xff,   10},  
> 
> +   {EM28XX_R08_GPIO,   0x7e,   0xff,   10},  
> 
> {EM2880_R04_GPO,0x04,   0xff,   10},  
> 
> {EM2880_R04_GPO,0x0c,   0xff,   10},  
> 
> -   {EM28XX_R08_GPIO,   0x7e,   0xff,   10},  
> 
> +   {  -1,  -1, -1, -1},  
> 
> +};   
> 
> + 
> 
> +/* Board - EM2882 Kworld 315U analog1 analog tv */   
> 
> +static struct em28xx_reg_seq em2882_kworld_315u_analog1[] = {
> 
> +   {EM28XX_R08_GPIO,   0xfd,   0xff,   10},  
> 
> +   {EM28XX_R08_GPIO,   0x7d,   0xff,   10},  
> 
> +   {  -1,  -1, -1, -1},  
> 
> +};   
> 
> + 
> 
> +/* Board - EM2882 Kworld 315U analog2 component/svideo */
> 
> +static struct em28xx_reg_seq em2882_kworld_315u_analog2[] = {
> 
> +   {EM28XX_R08_GPIO,   0xfd,   0xff,   10},  
> 
> {  -1,  -1, -1, -1},  
> 
>  };   
> 
>   
> 
> @@ -140,6 +158,14 @@  
> 
> {  -1,  -1, -1, -1},  
> 
>  };   
> 
>   
> 
> +/* Board - EM2882 Kworld 315U suspend */ 
> 
> +static struct em28xx_reg_seq em2882_kworld_315u_suspend[] = {
> 
> +   {EM28XX_R08_GPIO,   0xff,   0xff,   10},  
> 
> +   {EM2880_R04_GPO,0x08,   0xff,   10},  
> 
> +   {EM2880_R04_GPO,0x0c,   0xff,   10},  
> 
> +   {  -1,  -1, -1, -1},  
> 
> +};   
> 
> + 
> 
>  static struct em28xx_reg_seq kworld_330u_analog[] = {
> 
> {EM28XX_R08_GPIO,   0x6d,   ~EM_GPIO_4, 10},  
> 
> {EM2880_R04_GPO,0x00,   0xff,   10},  

Re: [Patch 3/3] Kworld 315U

[Mauro Carvalho Chehab]

Franklin Meng wrote:

Also complained about line-wrapping.

Cheers,
Mauro
> Patch to bring device out of power saving mode.  
>  
> Signed-off-by: Franklin Meng
> 
> diff -r b6b82258cf5e linux/drivers/media/video/em28xx/em28xx-core.c   
> 
> --- a/linux/drivers/media/video/em28xx/em28xx-core.cThu Dec 31 19:14:54 
> 2009 -0200
> +++ b/linux/drivers/media/video/em28xx/em28xx-core.cSun Jan 17 22:54:21 
> 2010 -0800
> @@ -1132,6 +1132,7 @@ 
> 
>   */  
> 
>  void em28xx_wake_i2c(struct em28xx *dev) 
> 
>  {
> 
> +   v4l2_device_call_all(&dev->v4l2_dev, 0, core,  s_power, 1);   
> 
> v4l2_device_call_all(&dev->v4l2_dev, 0, core,  reset, 0); 
> 
> v4l2_device_call_all(&dev->v4l2_dev, 0, video, s_routing, 
> 
> INPUT(dev->ctl_input)->vmux, 0, 0);   
> 
> 
> 
> 
> 
>   
> --
> 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

--
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: [Patch 1/3] Kworld 315U

[Mauro Carvalho Chehab]

Franklin Meng wrote:
> Patch to add the s_power function to the saa7115.c code.
> 
> Signed-off-by: Franklin Meng

I got an error while applying:

No file to patch.  Skipping patch.
patch:  malformed patch at line 22: return 0;   
 Patch may be line wrapped

I suspect that your email is destroying your patch.


> 
> 
> diff -r b6b82258cf5e linux/drivers/media/video/saa7115.c  
> 
> --- a/linux/drivers/media/video/saa7115.c   Thu Dec 31 19:14:54 2009 
> -0200
> +++ b/linux/drivers/media/video/saa7115.c   Sun Jan 17 22:54:21 2010 
> -0800
> @@ -1338,6 +1338,59 @@
> 
> return 0; 
> 
>  }
> 
>   
> 
> +static int saa711x_s_power(struct v4l2_subdev *sd, int val)  
> 
> +{
> 
> +   struct saa711x_state *state = to_state(sd);   
> 
> + 
> 
> +   if(val > 1 || val < 0)
> 
> +   return -EINVAL; 

Also, please validade your patch against coding style, with checkpatch.pl (you 
can use
make checkpatch, if you're using the -hg tree).

Basically, you need a space between if and ( at the above line.

  
> + 
> 
> +   /* There really isn't a way to put the chip into power saving 
> 
> +   other than by pulling CE to ground so all we do is return 
> 
> +   out of this function  
> 
> +   */
> 
> +   if(val == 0)  
> 
> +   return 0; 
> 
> + 
> 
> +   /* When enabling the chip again we need to reinitialize the   
> 
> +   all the values
> 
> +   */
> 
> +   state->input = -1;
> 
> +   state->output = SAA7115_IPORT_ON; 
> 
> +   state->enable = 1;
> 
> +   state->radio = 0; 
> 
> +   state->bright = 128;  
> 
> +   state->contrast = 64; 
> 
> +   state->hue = 0;   
> 
> +   state->sat = 64;  
> 
> + 
> 
> +   state->audclk_freq = 48000;   
> 
> + 
> 
> +   v4l2_dbg(1, debug, sd, "writing init values s_power\n");  
> 
> + 
> 
> +   /* init to 60hz/48khz */  
> 
> +   state->crystal_freq = SAA7115_FREQ_24_576_MHZ;
> 
> +   switch (state->ident) {   
> 
> +   case V4L2_IDENT_SAA7111:  
> 
> +   saa711x_writeregs(sd, saa7111_init);  
> 
> +   break;
> 
> +   case V4L2_IDENT_SAA7113:  
> 
> +   saa711x_writeregs(sd, saa7113_init);
> +   break;
> +   default:
> +   state->crystal_freq = SAA7115_FREQ_32_11_MHZ;
> +   saa711x_writeregs(sd, saa7115_init_auto_input);
> +   }
> +   if (state->ident != V4L2_IDENT_SAA7111)
> +   saa711x_writeregs(sd, saa7115_init_misc);
> +   saa711x_set_v4lstd(sd,

Re: help: Leadtek DTV2000 DS

[Antti Palosaari]

On 01/25/2010 01:44 PM, Gavin Ramm wrote:

Tried the current build of v4l-dvb (as of 25/01/2010) for a Leadtek DTV2000 DS.
product site : 
http://www.leadtek.com/eng/tv_tuner/overview.asp?lineid=6&pronameid=530&check=f

The chipset are AF9015 + AF9013 and the tuner is TDA18211..
Im running it on mythdora 10.21 *fedora 10* i've had no luck with this.

Any help would be great.. im willing to test..


Device USB ID is missing. Please send your lsusb output and I will add 
new IDs.


Antti
--
http://palosaari.fi/
--
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 can I add IR remote to this new device (DIKOM DK300)?

[Mauro Carvalho Chehab]

Hi Andrea,

andrea.amoros...@gmail.com wrote:
> Hi to all,
> I'm trying to use my Dikom DK300, my old notebook and an external
> monitor to create a media centre (I'm mostly interested in TV and TV
> recording).
> 
> The problem is that, even if I have managed to have the device working
> with the following patch, I can't still use the IR remote control
> shipped with it.

This basically depends on the chipset found on your device. Newer em28xx
devices have the IR decoding logic inside the chip. So, all you need is to
create a table with your IR codes and point to it at the board entry. You'll
need to discover what kind of IR protocol is used: NEC or RC5.

For example, adding this to the board description:
.ir_codes   = &ir_codes_rc5_hauppauge_new_table,

Will program your chip to use RC5 protocol with the Hauppauge table.

Of course, your IR has a different table, so you'll need to load em28xx module
with ir_debug=1, and type every key of your keyboard, associating a keycode
with the scancode and writing a new table (or using an existing one, if equal).

Then, add the corresponding table at ir-keymaps.c.

> Can you give me some suggestion in order to have also the remote
> controller working? Otherwise is it easier to buy another remote with a
> dedicated receiver?
> 
> Moreover, since the digital demodulator remains activated when the tuner
> is switched from digital to analogue mode or when kaffeine (which
> actually I'm using to see digital tv) is closed, I wonder if someone can
> explain me how to verify the gpio settings using the usbsnoop (which
> I've done some times ago under win XP) to solve the issue.
> If it is not possible, is there any way to deactivate the usb port and
> reactivate it when the device is in needed?
> 
> Meantime this it the patch that fixes the Dikom DK300 hybrid USB card
> which is recognized as a Kworld VS-DVB-T 323UR (card=54).

Please, create a separate entry for your board, since your card is different.
Unfortunately, since both Kworld 323UR and Dikom dk300 share the same USB ID,
autodetection between the two is not possible, so a modprobe parameter will
be needed to differentiate between the two.

> The patch adds digital TV and solves analogue TV audio bad quality issue.
> Moreover it removes the composite and s-video analogue inputs which are
> not present on the board.
> 
> Not working: remote controller
> 
> Signed-off-by: Andrea Amorosi 
> 
> diff -r 59e746a1c5d1 linux/drivers/media/video/em28xx/em28xx-cards.c
> --- a/linux/drivers/media/video/em28xx/em28xx-cards.cWed Dec 30
> 09:10:33 2009 -0200
> +++ b/linux/drivers/media/video/em28xx/em28xx-cards.cTue Jan 12
> 21:58:30 2010 +0100
> @@ -1447,19 +1447,25 @@
> .tuner_type   = TUNER_XC2028,
> .tuner_gpio   = default_tuner_gpio,
> .decoder  = EM28XX_TVP5150,
> +.mts_firmware = 1,
> +.has_dvb  = 1,
> +.dvb_gpio = kworld_330u_digital,
> .input= { {
> .type = EM28XX_VMUX_TELEVISION,
> .vmux = TVP5150_COMPOSITE0,
> .amux = EM28XX_AMUX_VIDEO,
> -}, {
> +.gpio = default_analog,
> +},/* {
> .type = EM28XX_VMUX_COMPOSITE1,
> .vmux = TVP5150_COMPOSITE1,
> .amux = EM28XX_AMUX_LINE_IN,
> +.gpio = kworld_330u_analog,
> }, {
> .type = EM28XX_VMUX_SVIDEO,
> .vmux = TVP5150_SVIDEO,
> .amux = EM28XX_AMUX_LINE_IN,
> -} },
> +.gpio = kworld_330u_analog,
> +} */},
> },
> [EM2882_BOARD_TERRATEC_HYBRID_XS] = {
> .name = "Terratec Hybrid XS (em2882)",
> @@ -2168,6 +2174,7 @@
> ctl->demod = XC3028_FE_DEFAULT;
> break;
> case EM2883_BOARD_KWORLD_HYBRID_330U:
> +case EM2882_BOARD_KWORLD_VS_DVBT:
> ctl->demod = XC3028_FE_CHINA;
> ctl->fname = XC2028_DEFAULT_FIRMWARE;
> break;
> diff -r 59e746a1c5d1 linux/drivers/media/video/em28xx/em28xx-dvb.c
> --- a/linux/drivers/media/video/em28xx/em28xx-dvb.cWed Dec 30
> 09:10:33 2009 -0200
> +++ b/linux/drivers/media/video/em28xx/em28xx-dvb.cTue Jan 12
> 21:58:30 2010 +0100
> @@ -504,6 +504,7 @@
> break;
> case EM2880_BOARD_TERRATEC_HYBRID_XS:
> case EM2881_BOARD_PINNACLE_HYBRID_PRO:
> +case EM2882_BOARD_KWORLD_VS_DVBT:
> dvb->frontend = dvb_attach(zl10353_attach,
>&em28xx_zl10353_xc3028_no_i2c_gate,
>&dev->i2c_adap);
> 
> 
> -- 
> 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

--
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: [PATCH] obsolete config in kernel source (DVB_DIBCOM_DEBUG)

[Mauro Carvalho Chehab]

Hi Patrick,

Could you please take a look on this patch? It makes sense or to apply it
or to add an option to enable debug messages at the drivers.

Cheers,
Mauro

Christoph Egger wrote:
> Hi all!
> 
>   As part of the VAMOS[0] research project at the University of
> Erlangen we're checking referential integrity between kernel KConfig
> options and in-code Conditional blocks.
> 
>   By this we discovered the config Option DVB_DIBCOM_DEBUG,
> which was dropped while removing the dibusb driver in favor of dvb-usb
> in 2005. However it remaind existant at some places of the kernel
> config.
> 
>   Probably one should be a bit more agressive here as the dprintk
> macro now expands to a do{}while(0) unconditionally so all blocks
> using them can also be dropped to remove in-tree cruft but the patch
> does a first cleanup.
> 
>   Please keep me informed of this patch getting confirmed /
> merged so we can keep track of it.
> 
> Regards
> 
>   Christoph Egger
> 
> [0] http://vamos1.informatik.uni-erlangen.de/
> 

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

help: Leadtek DTV2000 DS

[Gavin Ramm]

Tried the current build of v4l-dvb (as of 25/01/2010) for a Leadtek DTV2000 DS.
product site : 
http://www.leadtek.com/eng/tv_tuner/overview.asp?lineid=6&pronameid=530&check=f
 
The chipset are AF9015 + AF9013 and the tuner is TDA18211..
Im running it on mythdora 10.21 *fedora 10* i've had no luck with this.

Any help would be great.. im willing to test..
 
gav   
_
View photos of singles in your area! Browse profiles for FREE
http://clk.atdmt.com/NMN/go/150855801/direct/01/--
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: problem with libdvben50221 and powercam pro V4 [almost solved]

[Manu Abraham]

Hello Pierre,


On Mon, Jan 25, 2010 at 2:03 AM, pierre gronlier  wrote:
> DUBOST Brice  crans.ens-cachan.fr> writes:
>>
>> Manu Abraham a écrit :
>> > Hi Brice,
>> >
>> > On Mon, Jan 25, 2010 at 12:09 AM, DUBOST Brice
>> >  crans.ens-cachan.fr> wrote:
>> >> Hello
>> >>
>> >> Powercam just made a new version of their cam, the version 4
>> >>
>> >> Unfortunately this CAM doesn't work with gnutv and applications based on
>> >> libdvben50221
>> >>
>> >> This cam return TIMEOUT errors (en50221_stdcam_llci_poll: Error reported
>> >> by stack:-3) after showing the supported ressource id.
>> >>
>> >> The problem is that this camreturns two times the list of supported ids
>> >> (as shown in the log) this behavior make the llci_lookup_callback
>> >> (en50221_stdcam_llci.c line 338)  failing to give the good ressource_id
>> >> at the second call because there is already a session number (in the
>> >> test app the session number is not tested)
>> >>
>> >> I solved the problem commenting out the test for the session number as
>> >> showed in the joined patch (against the latest dvb-apps, cloned today)
>> >
>> > Very strange that, it responds twice on the same session.
>> > Btw, What DVB driver are you using ? budget_ci or budget_av ?
>>
>> Hello
>>
>> The card is a "DVB: registering new adapter (TT-Budget S2-3200 PCI)" and
>> the driver used is budget_ci
>>
>> Do you want me to run some more tests ?
>>
>
> Hello Manu, Hello Brice,
>
> I will run some tests with a TT3200 card too and a Netup card tomorrow.
>
> Regarding the cam returning two times the list of valid cam ids, wouldn't be
> better if the manufacturer corrects it in the cam firmware ?
> What says the en50221 norm about it ?


EN50221 says:

The host sends a CA Info Enquiry object to the application, which
responds by returning an CA Info object with the
appropriate information. The session is then kept open for periodic
operation of the protocol associated with
the CA PMT and CA PMT Reply objects

The specification is not very clear either way, I will try to get some
more understanding in there ..


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: problem with libdvben50221 and powercam pro V4 [almost solved]

[pierre.gronlier]

pierre gronlier wrote, On 01/24/2010 11:03 PM:
> DUBOST Brice  crans.ens-cachan.fr> writes:
>> Manu Abraham a écrit :
>>> Hi Brice,
>>>
>>> On Mon, Jan 25, 2010 at 12:09 AM, DUBOST Brice
>>>  crans.ens-cachan.fr> wrote:
 Hello

 Powercam just made a new version of their cam, the version 4

 Unfortunately this CAM doesn't work with gnutv and applications based on
 libdvben50221

 This cam return TIMEOUT errors (en50221_stdcam_llci_poll: Error reported
 by stack:-3) after showing the supported ressource id.

 The problem is that this camreturns two times the list of supported ids
 (as shown in the log) this behavior make the llci_lookup_callback
 (en50221_stdcam_llci.c line 338)  failing to give the good ressource_id
 at the second call because there is already a session number (in the
 test app the session number is not tested)

 I solved the problem commenting out the test for the session number as
 showed in the joined patch (against the latest dvb-apps, cloned today)
> 
> I will run some tests with a TT3200 card too and a Netup card tomorrow.
> 
> Regarding the cam returning two times the list of valid cam ids, wouldn't be
> better if the manufacturer corrects it in the cam firmware ?
> What says the en50221 norm about it ?
> 

Indeed, with the patch applied, the command gnutv -adapter 0 -cammenu is
working fine with a netup card too.

I will try to update to the last revision of pcam firmware (v4.2) and
report this behaviour to the manufacturer.

-- 
Pierre


--
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: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes

[Jiri Slaby]

On 01/25/2010 12:44 AM, Antti Palosaari wrote:
> When I now test this patch with debugs enabled I don't see
> .probe and .disconnect be called for this HID interface (interface 1) at
> all and thus checks not needed.

What happens if you disable the HID layer? Or at least if you add an
ignore quirk for the device in usbhid?

I forbid usbhid to attach to the device, as the remote kills X with HID
driver. With dvb-usb-remote it works just fine (with remote=2 for af9015
or the 4 patches I've sent).

-- 
js
--
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