Re: Regression - OOPS when connecting devices with IR support
On Sat, 2010-01-09 at 20:52 -0500, Devin Heitmueller wrote: > Hey all, > > This is going to sound like a bit of a silly question. Has anyone > tried the current v4l-dvb tip with a device that has IR support? > > I had been working on separate branches for the last few weeks, and > finally updated to the tip. I'm seeing the exact same OOPS condition > for both my em28xx and cx88 based device. > > Did someone break the IR core? This occurs 100% of the time in my > environment when loading either cx88 or em28xx based devices that have > IR support (a stock Ubuntu 9.10 build (2.6.31-17-generic) with the > current v4l-dvb tip as of tonight. Yes, the IR core is broken, a patch has been submitted by myself some time ago (http://patchwork.kernel.org/patch/70126/), but hasn't made it to v4l-dvb yet. Regards, Francesco -- 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
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, I added a bug fix which should go to the kernel 2.6.33. Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 10 changesets: 01/10: gspca - vc032x: Fix bad probe of the sensor mi1320. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=89f9221d4555 02/10: gspca - vc032x: Add the H and V flip controls for sensor mi1320. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=17a73955b94a 03/10: gspca - vc032x: Change the sensor of 046d:0892 and 046d:0896. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=cbd0fdc04914 04/10: gspca - sonixj: Add more controls. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=dd4a73349d62 05/10: gspca - zc3xx: Fix the contrast control. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=b978912adcaa 06/10: gspca - zc3xx: Adjust the pas202b exchanges. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=aa0e795c6db3 07/10: gspca - main: Check the interface class at probe time. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=5b914c313b68 08/10: gspca - some subdrivers: Make sd_desc const. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=5e4054307384 09/10: gspca - all subdrivers: Make control descriptors constant. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=163a46b2f384 10/10: gspca - sunplus: Fix bridge exchanges. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=3aa6e0e16208 benq.c|2 conex.c |4 etoms.c |4 gl860/gl860.c | 10 gspca.c |8 mars.c|2 mr97310a.c|2 ov534.c |4 pac207.c |2 pac7302.c |4 pac7311.c |4 sn9c20x.c |2 sonixb.c |2 sonixj.c | 130 ++ spca500.c |4 spca501.c |2 spca505.c |2 spca506.c |4 spca508.c |2 spca561.c |4 stk014.c |2 stv0680.c |2 sunplus.c | 28 +- t613.c|2 tv8532.c |2 vc032x.c | 716 +++--- zc3xx.c | 257 +--- 27 files changed, 877 insertions(+), 330 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: CI USB
On Sat, Jan 2, 2010 at 11:55 PM, HoP wrote: > Hi Jonas > >> Does anyone know if there's any progress on USB CI adapter support? >> Last posts I can find are from 2008 (Terratec Cinergy CI USB & >> Hauppauge WinTV-CI). >> >> That attempt seems to have stranded with Luc Brosens (who gave it a >> shot back then) asking for help. >> >> The chip manufacturer introduced a usb stick as well; >> http://www.smardtv.com/index.php?page=products_listing&rubrique=pctv§ion=usbcam >> but besides the scary Vista logo on that page, it looks like they >> target broadcast companies only and not end users. >> > > You are right. Seems DVB CI stick is not targeted to end consumers. > > Anyway, it looks interesting, even it requires additional DVB tuner > "somewhere in the pc" what means duplicated traffic (to the CI stick > for descrambling and back for mpeg a/v decoding). > > It would be nice to see such stuff working in linux, but because of > market targeting i don' t expect that. > > BTW, Hauppauge's WinTV-CI looked much more promissing. > At least when I started reading whole thread about it here: > http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html > > Unfortunatelly, last Steve's note about not getting anything > (even any answer) has disappointed me fully. And because > google is quiet about any progress on it I pressume > no any docu nor driver was released later on. > The question is more or less how many people are interested in USB CI support for Linux. We basically have everything to provide a USB CI solution for linux now. Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Regression - OOPS when connecting devices with IR support
Hey all, This is going to sound like a bit of a silly question. Has anyone tried the current v4l-dvb tip with a device that has IR support? I had been working on separate branches for the last few weeks, and finally updated to the tip. I'm seeing the exact same OOPS condition for both my em28xx and cx88 based device. Did someone break the IR core? This occurs 100% of the time in my environment when loading either cx88 or em28xx based devices that have IR support (a stock Ubuntu 9.10 build (2.6.31-17-generic) with the current v4l-dvb tip as of tonight. Devin [ 1265.371807] input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1d.7/usb1/1-5/input/input6 [ 1265.371887] Creating IR device irrcv0 [ 1265.371905] BUG: unable to handle kernel paging request at 72727563 [ 1265.371912] IP: [] strcmp+0x12/0x30 [ 1265.371922] *pde = [ 1265.371927] Oops: [#1] SMP [ 1265.371932] last sysfs file: /sys/devices/pci:00/:00:1d.7/usb1/1-5/firmware/1-5/loading [ 1265.371937] Modules linked in: tuner_xc2028 tuner tvp5150 em28xx(+) v4l2_common videodev v4l1_compat ir_common videobuf_vmalloc videobuf_core ir_core tveeprom binfmt_misc ppdev snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device dell_wmi psmouse dcdbas iptable_filter ip_tables x_tables lp parport nvidia(P) snd soundcore snd_page_alloc serio_raw usbhid floppy r8169 mii intel_agp agpgart [ 1265.372001] [ 1265.372006] Pid: 2540, comm: modprobe Tainted: P (2.6.31-17-generic #54-Ubuntu) Inspiron 537 [ 1265.372011] EIP: 0060:[] EFLAGS: 00010296 CPU: 1 [ 1265.372015] EIP is at strcmp+0x12/0x30 [ 1265.372019] EAX: c06e2d75 EBX: f11b9720 ECX: c023a3c0 EDX: 72727563 [ 1265.372023] ESI: c06e2db1 EDI: 72727563 EBP: f2207ab4 ESP: f2207aac [ 1265.372027] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 1265.372031] Process modprobe (pid: 2540, ti=f2206000 task=f21a1920 task.ti=f2206000) [ 1265.372035] Stack: [ 1265.372037] 72727563 f2207b18 f2207ac4 c023a721 f11b9840 f2207b18 f2207ad8 c023b2ef [ 1265.372048] <0> f2207b18 f11b9840 f2207b18 f2207b0c c023b3a8 c01fb879 f11b96f0 0001 [ 1265.372059] <0> f11b96f0 f2207b18 f2207b0c c023a8cf f11b96f0 f2207b18 f11b9840 fff4 [ 1265.372072] Call Trace: [ 1265.372078] [] ? sysfs_find_dirent+0x21/0x30 [ 1265.372084] [] ? __sysfs_add_one+0x1f/0xc0 [ 1265.372090] [] ? sysfs_add_one+0x18/0x100 [ 1265.372095] [] ? ilookup5+0x39/0x50 [ 1265.372100] [] ? sysfs_addrm_start+0x3f/0xa0 [ 1265.372107] [] ? sysfs_add_file_mode+0x4c/0x80 [ 1265.372113] [] ? create_files+0x55/0xc0 [ 1265.372119] [] ? internal_create_group+0x65/0xc0 [ 1265.372125] [] ? sysfs_create_group+0xc/0x10 [ 1265.372134] [] ? ir_register_class+0x8b/0xd0 [ir_core] [ 1265.372142] [] ? ir_input_register+0x184/0x250 [ir_core] [ 1265.372149] [] ? queue_work_on+0x3b/0x60 [ 1265.372155] [] ? queue_work+0x15/0x20 [ 1265.372170] [] ? em28xx_ir_init+0x1af/0x240 [em28xx] [ 1265.372183] [] ? em28xx_card_setup+0x4ac/0xe90 [em28xx] [ 1265.372197] [] ? em28xx_tuner_callback+0x0/0x30 [em28xx] [ 1265.372209] [] ? em28xx_usb_probe+0x5c4/0xaa0 [em28xx] [ 1265.372219] [] ? usb_probe_interface+0x87/0x160 [ 1265.372225] [] ? sysfs_create_link+0x12/0x20 [ 1265.372232] [] ? really_probe+0x50/0x140 [ 1265.372238] [] ? _spin_lock_irqsave+0x2a/0x40 [ 1265.372245] [] ? driver_probe_device+0x19/0x20 [ 1265.372251] [] ? __driver_attach+0x79/0x80 [ 1265.372257] [] ? bus_for_each_dev+0x48/0x70 [ 1265.372263] [] ? driver_attach+0x19/0x20 [ 1265.372269] [] ? __driver_attach+0x0/0x80 [ 1265.372275] [] ? bus_add_driver+0xbf/0x2a0 [ 1265.372281] [] ? driver_register+0x65/0x120 [ 1265.372288] [] ? usb_register_driver+0x79/0xf0 [ 1265.372295] [] ? tracepoint_module_notify+0x2f/0x40 [ 1265.372306] [] ? em28xx_module_init+0x1b/0x44 [em28xx] [ 1265.372311] [] ? do_one_initcall+0x2c/0x190 [ 1265.372322] [] ? em28xx_module_init+0x0/0x44 [em28xx] [ 1265.372328] [] ? sys_init_module+0xb1/0x1f0 [ 1265.372334] [] ? syscall_call+0x7/0xb [ 1265.372337] Code: 8b 1c 24 8b 7c 24 08 89 ec 5d c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 83 ec 08 89 34 24 89 c6 89 7c 24 04 89 d7 ac 75 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 8b 34 24 8b 7c 24 [ 1265.372404] EIP: [] strcmp+0x12/0x30 SS:ESP 0068:f2207aac [ 1265.372411] CR2: 72727563 [ 1265.372416] ---[ end trace a4f8803cde5fb73f ]--- -- 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] cx25840: Fix composite detection.
If CX25840_VIN1_CH1 and the like is used, input is not detected as composite. Signed-off-by: Kusanagi Kouichi --- drivers/media/video/cx25840/cx25840-core.c |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/cx25840/cx25840-core.c b/drivers/media/video/cx25840/cx25840-core.c index 385ecd5..764c811 100644 --- a/drivers/media/video/cx25840/cx25840-core.c +++ b/drivers/media/video/cx25840/cx25840-core.c @@ -734,10 +734,8 @@ static int set_input(struct i2c_client *client, enum cx25840_video_input vid_inp v4l_dbg(1, cx25840_debug, client, "vid_input 0x%x\n", vid_input); reg = vid_input & 0xff; - if ((vid_input & CX25840_SVIDEO_ON) == CX25840_SVIDEO_ON) - is_composite = 0; - else if ((vid_input & CX25840_COMPONENT_ON) == 0) - is_composite = 1; + is_composite = !is_component && + ((vid_input & CX25840_SVIDEO_ON) != CX25840_SVIDEO_ON); v4l_dbg(1, cx25840_debug, client, "mux cfg 0x%x comp=%d\n", reg, is_composite); -- 1.6.6 -- 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
[PULL] soc-camera: minor fixes for 2.6.33
Hi Mauro, Having asked earlier today (actually yesterday) about non-ASCII characters, I decided, it probably would be ok if I just feed hg with utf-8. So, I've done that, all three authors of the patches from this pull request do have such characters in their names. So, please, have a look if it looks suitable for your scripting, if not, please, let me know, will try to regenerate and take into account in the future. Also, they are all non-critical, but still fixes, that better go in 2.6.33. Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following 3 changesets: 01/03: V4L/DVB mx1_camera: don't check platform_get_irq's return value against zero http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=83fa520b71f5 02/03: V4L/DVB sh_mobile_ceu: don't check platform_get_irq's return value against zero http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=df0a91529ed6 03/03: rj54n1cb0c: remove compiler warning http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=36cf17df75cb mx1_camera.c |2 +- rj54n1cb0c.c |2 +- sh_mobile_ceu_camera.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.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
Re: IR device at I2C address 0x7a
Hi, Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare: > On Sat, 09 Jan 2010 13:08:36 +0100, Daro wrote: > > W dniu 06.01.2010 21:21, Jean Delvare pisze: > > > On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote: > > >> It is not the error message itself that bothers me but the fact that IR > > >> remote control device is not detected and I cannot use it (I checked it > > >> on Windows and it's working). After finding this thread I thought it > > >> could have had something to do with this error mesage. > > >> Is there something that can be done to get my IR remote control working? > > > You could try loading the saa7134 driver with option card=146 and see > > > if it helps. > > > > It works! > > > > [ 15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as > > /devices/pci:00/:00:1e.0/:05:00.0/input/input8 > > > > Thank you very much fo your help. > > Then I would suggest the following patch: > > * * * * * > > From: Jean Delvare > Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants > > Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131 > Analog (card=146). However, by the time we find out, some > card-specific initialization is missed. In particular, the fact that > the IR is GPIO-based. Set it when we change the card type. > > Signed-off-by: Jean Delvare > Tested-by: Daro just to note it, the ASUS TV-FM 7135 with USB remote is different to the Asus My Cinema P7134 Analog only, not only for the remote, but also for inputs, but they have the same PCI subsystem. > --- > linux/drivers/media/video/saa7134/saa7134-cards.c |1 + > 1 file changed, 1 insertion(+) > > --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c > 2009-12-11 09:47:47.0 +0100 > +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-09 > 16:23:17.0 +0100 > @@ -7257,6 +7257,7 @@ int saa7134_board_init2(struct saa7134_d > printk(KERN_INFO "%s: P7131 analog only, using " > "entry of %s\n", > dev->name, saa7134_boards[dev->board].name); > + dev->has_remote = SAA7134_REMOTE_GPIO; > } > break; > case SAA7134_BOARD_HAUPPAUGE_HVR1150: > > > * * * * * Must have been broken at that time, IIRC. Only moving saa7134_input_init1(dev) to static int saa7134_hwinit2 in saa7134-core.c did help, AFAIK, but I might be wrong. > > I have another question regarding this driver: > > > > [ 21.340316] saa7133[0]: dsp access error > > [ 21.340320] saa7133[0]: dsp access error > > > > Do those messages imply something wrong? Can they have something do do > > with the fact I cannot get the sound out of tvtime application directly > > and have to use "arecord | aplay" workaround which causes undesirable delay? > > Yes, the message is certainly related to your sound problem. Maybe > support for your card is incomplete. But I can't help with this, sorry. That is nice ice to slide on, but from all others with that card previously not reported so far. Anyway, it should have also analog audio out, the two pins in the middle of the white 4pin connector on the PCB are ground. To know that can avoid troubles using older CD-ROM audio cables and get only one of the stereo channels. Cheers, Hermann Hermann -- 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: Leadtek Winfast TV2100
Hi, sorry, there is a typo in the gpio mask on previously attached patch you might use against current v4l-dvb with your further findings. Mask 0x0d is sufficient and we don't need any 0xe0d :( You might also consider to start with vmux = 3 for Composite1 and vmux = 0 for Composite2, that is expected to be over the S-Video connector and should work too. Does save some plugging around with two composite input devices, if S-Video is not in use. good night, Hermann -- 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: Fwd: Compro S300 - ZL10313
2010/1/10 JD Louw : > On Wed, 2010-01-06 at 22:17 +0200, Theunis Potgieter wrote: >> 2010/1/2 JD Louw : >> > On Sat, 2010-01-02 at 09:39 +0200, Theunis Potgieter wrote: >> >> 2010/1/1 JD Louw : >> >> > On Tue, 2009-12-29 at 23:23 +0200, Theunis Potgieter wrote: >> >> >> Hi mailing list, >> >> >> >> >> >> I have a problem with my Compro S300 pci card under Linux 2.6.32. >> >> >> >> >> >> I cannot tune with this card and STR/SNRA is very bad compared to my >> >> >> Technisat SkyStar 2 pci card, connected to the same dish. >> >> >> >> >> >> I have this card and are willing to run tests, tested drivers etc to >> >> >> make this work. >> >> >> >> >> >> I currently load the module saa7134 with options: card=169 >> >> >> >> >> >> I enabled some debug parameters on the saa7134, not sure what else I >> >> >> should enable. Please find my dmesg log attached. >> >> >> >> >> >> lsmod shows : >> >> >> >> >> >> # lsmod >> >> >> Module Size Used by >> >> >> zl10039 6268 2 >> >> >> mt312 12048 2 >> >> >> saa7134_dvb 41549 11 >> >> >> saa7134 195664 1 saa7134_dvb >> >> >> nfsd 416819 11 >> >> >> videobuf_dvb 8187 1 saa7134_dvb >> >> >> dvb_core 148140 1 videobuf_dvb >> >> >> ir_common 40625 1 saa7134 >> >> >> v4l2_common 21544 1 saa7134 >> >> >> videodev 58341 2 saa7134,v4l2_common >> >> >> v4l1_compat 24473 1 videodev >> >> >> videobuf_dma_sg 17830 2 saa7134_dvb,saa7134 >> >> >> videobuf_core 26534 3 saa7134,videobuf_dvb,videobuf_dma_sg >> >> >> tveeprom 12550 1 saa7134 >> >> >> thermal 20547 0 >> >> >> processor 54638 1 >> >> >> >> >> >> # uname -a >> >> >> Linux vbox 2.6.32-gentoo #4 Sat Dec 19 00:54:19 SAST 2009 i686 Pentium >> >> >> III (Coppermine) GenuineIntel GNU/Linux >> >> >> >> >> >> Thanks, >> >> >> Theunis >> >> > >> >> > Hi, >> >> > >> >> > It's probably the GPIO settings that are wrong for your SAA7133 based >> >> > card revision. See http://osdir.com/ml/linux-media/2009-06/msg01256.html >> >> > for an explanation. For quick confirmation check if you have 12V - 20V >> >> > DC going to your LNB. The relevant lines of code is in >> >> > ~/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c: >> >> > >> >> > case SAA7134_BOARD_VIDEOMATE_S350: >> >> > dev->has_remote = SAA7134_REMOTE_GPIO; >> >> > saa_andorl(SAA7134_GPIO_GPMODE0 >> 2, 0x8000, 0x8000); >> >> > saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x8000, 0x8000); >> >> > break; >> >> > >> >> Hi thanks for the hint. I changed it to the following: >> >> >> >> case SAA7134_BOARD_VIDEOMATE_S350: >> >> dev->has_remote = SAA7134_REMOTE_GPIO; >> >> saa_andorl(SAA7134_GPIO_GPMODE0 >> 2, 0xc000, 0xc000); >> >> saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0xc000, 0xc000); >> >> break; >> >> >> >> I now get the same SNR as on my skystar2 card, signal is still >> >> indicating 17% where as the skystar2 would show 68%. At least I'm >> >> getting a LOCK on channels :) >> >> >> >> Thanks! >> >> >> >> > >> >> > Looking at your log, at least the demodulator and tuner is responding >> >> > correctly. You can see this by looking at the i2c traffic addressed to >> >> > 0x1c (demodulator) and 0xc0 (tuner). Attached is a dmesg trace from my >> >> > working SAA7130 based card. >> >> > >> >> > Regards >> >> > JD >> >> > >> > >> > Hi, >> > >> > Just to clarify, can you now watch channels? >> > >> > At the moment the signal strength measurement is a bit whacked, so don't >> > worry too much about it. I also get the 75%/17% figures you mentioned >> > when tuning to strong signals. The figure is simply reported wrongly: >> > even weaker signals should tune fine. If you want you can have a look in >> > ~/v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c at >> > mt312_read_signal_strength(). >> > >> > Also, if you have a multimeter handy, can you confirm that the >> > 0xc000 GPIO fix enables LNB voltage? I'd like to issue a patch for >> > this. I've already tested this on my older card with no ill effect. >> >> This is what happened when I started vdr. >> >> Vertical gave a Volt reading between 13.9 and 14.1, Horizontal Gave >> 19.4 ~ 19.5. When I stopped vdr, the Voltage went back to 14V. I >> thought that it would read 0V. What is suppose to happen? >> >> Theunis >> >> > >> > Regards >> > JD >> > >> > >> > >> > > > Hi, > > The newer revision cards should be able to shut down LNB power when the > card is closed. This is what the Windows driver does; not yet > implemented in Linux. > > I'd like to document the different variants of this card on the wiki. > Can you send me the output of lspci -vvnn for your variant? If you have > Windows, can you also send me some RegSpy states similar to the ones I'm > attaching to this mail? > > Regards > JD > > 00:09.0 Multimedia controller [0480]: Philips Semiconductors SA
[Q] hg patches with non-ASCII symbols
Hi Mauro, all I've got a couple of patches from authors with non-ASCII characters in their names. I'm sending this email on purpose from a utf-8 client to better demonstrait this. Here is a header of one of such _git_ patches: >From 7984cae1e117149392548ff102c7a22fce7ae92c Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Wed, 16 Dec 2009 17:10:04 +0100 Subject: [PATCH 1/5] V4L/DVB mx1_camera: don't check platform_get_irq's return value against zero MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit platform_get_irq returns -ENXIO on failure, so !irq was probably always true. Better use (int)irq <= 0. Note that a return value of zero is still handled as error even though this could mean irq0. This is a followup to 305b3228f9ff4d59f49e6d34a7034d44ee8ce2f0 that changed the return value of platform_get_irq from 0 to -ENXIO on error. Signed-off-by: Uwe Kleine-König As you see, the name in the header is converted to a string like From: =?utf-8?q?Uwe=20Kleine-K=C3=B6nig?= but UTF-8 is preserved in Sob. Is this also how I shall commit such patches to hg or shall I do this somehow differently. Or shall I just wait with these patches until v4l switches to git... Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.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
Genius TVGo DVB-T02Q MCE firmware and module issues
Hi, I have Genius DVB-T02Q MCE USB DVB-T tuner. I tried using it on Ubuntu and Fedora without success. Here is the info that I get via dmesg and lsusb: # dmesg usb 1-6: new high speed USB device using ehci_hcd and address 8 usb 1-6: New USB device found, idVendor=0458, idProduct=400f usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-6: Product: DVB-T02Q MCE usb 1-6: Manufacturer: Genius usb 1-6: configuration #1 chosen from 1 choice input: Genius DVB-T02Q MCE as /devices/pci:00/:00:1d.7/usb1/1-6/1-6:1.0/input/input14 generic-usb 0003:0458:400F.0007: input,hidraw3: USB HID v1.11 Keyboard [Genius DVB-T02Q MCE] on usb-:00:1d.7-6/input0 Is the correct driver for this device dvb-usb-m920x ? On Fedora 12 with 2.6.31.9-174.fc12.i686 kernel I don't see that this module is getting loaded, why? I manually loaded dvb-usb-m920x module: # modprobe dvb-usb-m920x # dmesg usbcore: registered new interface driver dvb_usb_m920x I don't see /dev/dvb or /dev/video0 devices present, so I guess that something still is not ok, maybe firmware? Which is the correct firmware for this device? I downloaded all firmware from: http://linuxtv.org/downloads/firmware/ and copied them to /lib/firmware and tried reloading the module, still nothing :( Then I saw post on this mailing list saying that correct firware is dvb-usb-megasky-02.fw so I downloaded it also, but still nothing. Do you have any idea why this device is not working? Can I give you some more info in order to fix this issue? Cheers! -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic -- pratite me na twitteru - www.twitter.com/valentt http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic, msn: valent.turko...@hotmail.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: Fwd: Compro S300 - ZL10313
On Wed, 2010-01-06 at 22:17 +0200, Theunis Potgieter wrote: > 2010/1/2 JD Louw : > > On Sat, 2010-01-02 at 09:39 +0200, Theunis Potgieter wrote: > >> 2010/1/1 JD Louw : > >> > On Tue, 2009-12-29 at 23:23 +0200, Theunis Potgieter wrote: > >> >> Hi mailing list, > >> >> > >> >> I have a problem with my Compro S300 pci card under Linux 2.6.32. > >> >> > >> >> I cannot tune with this card and STR/SNRA is very bad compared to my > >> >> Technisat SkyStar 2 pci card, connected to the same dish. > >> >> > >> >> I have this card and are willing to run tests, tested drivers etc to > >> >> make this work. > >> >> > >> >> I currently load the module saa7134 with options: card=169 > >> >> > >> >> I enabled some debug parameters on the saa7134, not sure what else I > >> >> should enable. Please find my dmesg log attached. > >> >> > >> >> lsmod shows : > >> >> > >> >> # lsmod > >> >> Module Size Used by > >> >> zl10039 6268 2 > >> >> mt312 12048 2 > >> >> saa7134_dvb41549 11 > >> >> saa7134 195664 1 saa7134_dvb > >> >> nfsd 416819 11 > >> >> videobuf_dvb8187 1 saa7134_dvb > >> >> dvb_core 148140 1 videobuf_dvb > >> >> ir_common 40625 1 saa7134 > >> >> v4l2_common21544 1 saa7134 > >> >> videodev 58341 2 saa7134,v4l2_common > >> >> v4l1_compat24473 1 videodev > >> >> videobuf_dma_sg17830 2 saa7134_dvb,saa7134 > >> >> videobuf_core 26534 3 saa7134,videobuf_dvb,videobuf_dma_sg > >> >> tveeprom 12550 1 saa7134 > >> >> thermal20547 0 > >> >> processor 54638 1 > >> >> > >> >> # uname -a > >> >> Linux vbox 2.6.32-gentoo #4 Sat Dec 19 00:54:19 SAST 2009 i686 Pentium > >> >> III (Coppermine) GenuineIntel GNU/Linux > >> >> > >> >> Thanks, > >> >> Theunis > >> > > >> > Hi, > >> > > >> > It's probably the GPIO settings that are wrong for your SAA7133 based > >> > card revision. See http://osdir.com/ml/linux-media/2009-06/msg01256.html > >> > for an explanation. For quick confirmation check if you have 12V - 20V > >> > DC going to your LNB. The relevant lines of code is in > >> > ~/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c: > >> > > >> > case SAA7134_BOARD_VIDEOMATE_S350: > >> > dev->has_remote = SAA7134_REMOTE_GPIO; > >> > saa_andorl(SAA7134_GPIO_GPMODE0 >> 2, 0x8000, 0x8000); > >> > saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x8000, 0x8000); > >> > break; > >> > > >> Hi thanks for the hint. I changed it to the following: > >> > >> case SAA7134_BOARD_VIDEOMATE_S350: > >> dev->has_remote = SAA7134_REMOTE_GPIO; > >> saa_andorl(SAA7134_GPIO_GPMODE0 >> 2, 0xc000, 0xc000); > >> saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0xc000, 0xc000); > >> break; > >> > >> I now get the same SNR as on my skystar2 card, signal is still > >> indicating 17% where as the skystar2 would show 68%. At least I'm > >> getting a LOCK on channels :) > >> > >> Thanks! > >> > >> > > >> > Looking at your log, at least the demodulator and tuner is responding > >> > correctly. You can see this by looking at the i2c traffic addressed to > >> > 0x1c (demodulator) and 0xc0 (tuner). Attached is a dmesg trace from my > >> > working SAA7130 based card. > >> > > >> > Regards > >> > JD > >> > > > > > Hi, > > > > Just to clarify, can you now watch channels? > > > > At the moment the signal strength measurement is a bit whacked, so don't > > worry too much about it. I also get the 75%/17% figures you mentioned > > when tuning to strong signals. The figure is simply reported wrongly: > > even weaker signals should tune fine. If you want you can have a look in > > ~/v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c at > > mt312_read_signal_strength(). > > > > Also, if you have a multimeter handy, can you confirm that the > > 0xc000 GPIO fix enables LNB voltage? I'd like to issue a patch for > > this. I've already tested this on my older card with no ill effect. > > This is what happened when I started vdr. > > Vertical gave a Volt reading between 13.9 and 14.1, Horizontal Gave > 19.4 ~ 19.5. When I stopped vdr, the Voltage went back to 14V. I > thought that it would read 0V. What is suppose to happen? > > Theunis > > > > > Regards > > JD > > > > > > > > Hi, The newer revision cards should be able to shut down LNB power when the card is closed. This is what the Windows driver does; not yet implemented in Linux. I'd like to document the different variants of this card on the wiki. Can you send me the output of lspci -vvnn for your variant? If you have Windows, can you also send me some RegSpy states similar to the ones I'm attaching to this mail? Regards JD SAA7130 Card [0]: Vendor ID: 0x1131 Device ID: 0x7130 Subsystem ID:0xc900185b 7 states dumped Clean PC boot - no tuning yet
PULL http://jusst.de/hg/stv090x
Mauro, Please pull http://jusst.de/hg/stv090x changesets: from 13880 - 13891 inclusive of both. 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: em28xx: New device request and tvp5150 distortion issues when capturing from vcr
Devin Heitmueller wrote: > On Tue, Jan 5, 2010 at 3:40 AM, Michael Rüttgers > wrote: >> Hello, >> >> a year ago I bought a device named "Hama Video Editor", which was not >> (and is not yet) supported by the em28xx driver. >> So I played around with the card parameter and got the device basically >> working with card=38. >> Basically working means, that I had a distortion when capturing old >> VHS-Tapes from my old vcr. >> >> The problem can be seen here: >> http://www.michael-ruettgers.de/em28xx/test.avi >> >> A few weeks ago I started tracking down the reason for this issue with >> the help of Devin. >> Wondering, that the device works perfectly in Windows, I compared the >> i2c commands, that programmed the register of the tvp5150 in Windows. >> >> Finally I got the device working properly, setting the "TV/VCR" option >> in the register "Operation Mode Controls Register" at address 02h >> manually to "Automatic mode determined by the internal detection >> circuit. (default)": >> >> 000109: OUT: 00 ms 107025 ms 40 02 00 00 b8 00 02 00 >>> 02 00 >> >> After programming this register, the distortion issue disappeared. >> >> So my conclusion was, that the TV/VCR detection mode is forced to >> TV-mode in the em28xx, which could have been verified by a look into the >> debug output using the parameter reg_debug=1: >> >> OUT: 40 02 00 00 b8 00 02 00 >>> 02 30 >> >> Bit 4, 5 are used for setting the TV/VCR mode: >> >> Description in the Spec: >>> TV/VCR mode >>> 00 = Automatic mode determined by the internal detection circuit. >> (default) >>> 01 = Reserved >>> 10 = VCR (nonstandard video) mode >>> 11 = TV (standard video) mode >>> With automatic detection enabled, unstable or nonstandard syncs on the >> input video forces the detector into the VCR >>> mode. This turns off the comb filters and turns on the chroma trap >> filter. >> >> Thus far the tvp5150 distortion issues when capturing from vcr. > > Mauro, > > I have been working with Michael on this issue and I did some research > into the history of this issue, and it seems like you introduced code > in rev 2900 which turns off the auto mode and forces the tvp5150 into > "TV mode" if using a composite input: > > http://linuxtv.org/hg/v4l-dvb/rev/e6c585a76c77 > > Could you provide any information on the rationale for this decision? > I would think that having it in auto mode would be the appropriate > default (which is what the Windows driver does), and then you would > force it to either TV or VCR mode only if absolutely necessary. > > The comb filter only gets disabled if the auto mode actually concludes > the device should be in VCR mode. Hence, there shouldn't be any > downside to having it in auto mode unless you have some reason to > believe the detection code is faulty or error-prone. > This is a very old patch, and I forgot the reasons why. On that time, only TV were working. I suspect the change were needed in order to get signal working at Svideo/composite entry on WinTV USB2. Probably, I tested Svideo/composite with an old VCR I used for tests on that time. > We can add a modprobe option to allow the user to force it into one > mode or the other, if someone finds a case where the detection logic > has issues. But forcing it into one particular mode by default > doesn't seem like the right approach. A modprobe option would be very bad, IMHO. If the problem is with some old VCR's, maybe the better is to add a control for it. For example, bttv driver has one such control: V4L2_CID_PRIVATE_VCR_HACK I agree that it makes sense to keep the autodetect mode on by default, but tests are needed to validade if this won't break support with other devices. 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
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:Sat Jan 9 19:00:02 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13879:b6b82258cf5e 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.33-rc2-armv5: ERRORS linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: ERRORS linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: ERRORS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK 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 linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: building v4l-dvb - compilation error
Karicheri, Muralidharan wrote: > Hi, > > I have installed mercurial and cloned the v4l-dvb tree. I tried doing a build > as per instructions and I get the following error. Since I am in the process > of validating my build environment, I am not sure if the following is a > genuine build error or due to my environment... > > Other questions I have are:- > > 1) I am just doing make. So does this build all v4l2 drivers? Yes. > 2) Which target this build for? The one found on your running. You may force a different target with make ARCH= > 3) What output this build create? The *.ko modules. > make[2]: Leaving directory `/usr/src/kernels/2.6.9-55.0.12.EL-smp-i686' The minimum supported version by the backport is 2.6.16. 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: Kworld 315U and SAA7113?
I tweaked the GPIO's a bit more for the Kworld 315U and switching between
analog and digital signals is more reliable now. Attached is an updated diff.
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 Sat Jan 09 11:29:27
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},
@@ -1314,28 +1340,28 @@
.decoder= EM28XX_SAA711X,
.has_
Re: Leadtek Winfast TV2100
Hi, Am Samstag, den 09.01.2010, 17:23 +0100 schrieb dz-tor: > Hi Pavle, > > On 09.01.2010 15:46, Pavle Predic wrote: > > Hey Darek, > > > > Great job of making the card work. I was really thrilled when I saw > > your post. However, I am a total newbie, so I couldn't apply the > > changes you wrote about. Could you please be a bit more specific? What > > I did is downloaded the driver from here: > > http://dl.bytesex.org/releases/video4linux/saa7134-0.2.12.tar.gz and > > made the changes to those two files, as described. But I have no clue > > how to compile it. I installed linux-headers for my kernel version and > > tried to run make, but I'm getting an error. Are there any > > configuration options that I need to set in Makefile or Make.config? > I'm not sure whether downloading and compiling driver is good idea. v4l > drivers (which includes saa7134) are included in mainline kernel, so > compiling kernel is what you have to do. From what I know, in Debian > there should be package in repositories with kernel sources > (linux-source or similar) - this option you should use if you want to > stick to the kernel version provided by your distribution. Another > option is to download kernel sources from kernel.org and use them (I've > done so - I'm using latest stable release). Here you have link to how-to > about kernel compiling: > https://help.ubuntu.com/6.10/ubuntu/installation-guide/i386/kernel-baking.html. > > It's for Ubuntu, but for you it should be also applicable (on bottom > there is also link to Debian documentation). > > Before compilation you should make changes which I gave earlier. All > files which should be modified are in > /drivers/media/video/saa7134/ directory. Have in mind > that what I've done is that I've changed existing card configuration - > it's not proper solution. When I'll manage remote control to work, I'll > try to prepare patch with new card configuration. You can apply my > changes now or wait until I'll prepare the patch. > > Regards, > Darek Great! So Pavle's regspy results and following my instructions did the trick. Patches must go to LMML and be against latest v4l-dvb master at linuxtv.org. You can use what I prepared already yesterday for testing and is attached. You have only to change the clock and use LINE1 for external audio input. I suggest to use also LINE1 for mute then, gpio 0x08 is that input anyway. We can send that modified patch already and add IR support later. You must find the up/down gpio and with mask_keycode = 0x00 all the other gpios which do change on keypresses and create unique keycodes. Then you either need to add a new keytable or can use an already existing one. Yes, saa7130 chips have only mono TV sound. Cheers, Hermann > > > > > Cheers, > > > > Pavle. > > > > PS My kernel is 2.6.26-2-686 (it's a Debian Lenny 503 system). Here is > > the output produced by make: > > > > debian:/home/pavle/saa7134-0.2.12# make > > make -C /lib/modules/2.6.26-2-686/build > > SUBDIRS=/home/pavle/saa7134-0.2.12 modules > > make[1]: Entering directory `/usr/src/linux-headers-2.6.26-2-686' > > CC [M] /home/pavle/saa7134-0.2.12/video-buf.o > > In file included from /home/pavle/saa7134-0.2.12/media/video-buf.h:19, > > from /home/pavle/saa7134-0.2.12/video-buf.c:33: > > /home/pavle/saa7134-0.2.12/linux/videodev.h:68: error: field > > 'class_dev' has incomplete type > > /home/pavle/saa7134-0.2.12/linux/videodev.h:87: warning: 'struct > > class_device_attribute' declared inside parameter list > > /home/pavle/saa7134-0.2.12/linux/videodev.h:87: warning: its scope is > > only this definition or declaration, which is probably not what you want > > /home/pavle/saa7134-0.2.12/linux/videodev.h: In function > > 'video_device_create_file': > > /home/pavle/saa7134-0.2.12/linux/videodev.h:89: error: implicit > > declaration of function 'class_device_create_file' > > /home/pavle/saa7134-0.2.12/linux/videodev.h: At top level: > > /home/pavle/saa7134-0.2.12/linux/videodev.h:93: warning: 'struct > > class_device_attribute' declared inside parameter list > > /home/pavle/saa7134-0.2.12/linux/videodev.h: In function > > 'video_device_remove_file': > > /home/pavle/saa7134-0.2.12/linux/videodev.h:95: error: implicit > > declaration of function 'class_device_remove_file' > > /home/pavle/saa7134-0.2.12/video-buf.c: At top level: > > /home/pavle/saa7134-0.2.12/video-buf.c:46: error: expected ')' before > > string constant > > /home/pavle/saa7134-0.2.12/video-buf.c: In function > > 'videobuf_vmalloc_to_sg': > > /home/pavle/saa7134-0.2.12/video-buf.c:68: error: 'struct scatterlist' > > has no member named 'page' > > /home/pavle/saa7134-0.2.12/video-buf.c: In function > > 'videobuf_pages_to_sg': > > /home/pavle/saa7134-0.2.12/video-buf.c:96: error: 'struct scatterlist' > > has no member named 'page' > > /home/pavle/saa7134-0.2.12/video-buf.c:104: error: 'struct > > scatterlist' has no member named 'page' > > /home/
Re: Which modules for the VP-2033? Where is the module "mantis.ko"?
Hi! Still no change regarding regaining IR support for VP2040 device. Despite successfully loading the module from Abraham's tree and starting the UART, I still do not see the input device that I can use with lirc. I tried both trees: today's Liplianin tree, dmesg on loading the mantis module: ir_common: Unknown symbol ir_g_keycode_from_table ir_common: Unknown symbol ir_core_debug today's Abraham's tree, dmesg on loading the mantis modulem verbose=5: the result is still the same as the last time I wrote about it (no input device is registered, despite successful uart initialization). -- 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] V4L/DVB: ir: fix memory leak
Free ir_dev before exit.
Found by cppcheck.
Signed-off-by: Alexander Beregalov
---
drivers/media/IR/ir-keytable.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index bff7a53..684918e 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -422,8 +422,10 @@ int ir_input_register(struct input_dev *input_dev,
ir_dev->rc_tab.size = ir_roundup_tablesize(rc_tab->size);
ir_dev->rc_tab.scan = kzalloc(ir_dev->rc_tab.size *
sizeof(struct ir_scancode), GFP_KERNEL);
- if (!ir_dev->rc_tab.scan)
+ if (!ir_dev->rc_tab.scan) {
+ kfree(ir_dev);
return -ENOMEM;
+ }
IR_dprintk(1, "Allocated space for %d keycode entries (%zd bytes)\n",
ir_dev->rc_tab.size,
--
1.6.6
--
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: IR device at I2C address 0x7a
On Sat, 09 Jan 2010 13:08:36 +0100, Daro wrote: > W dniu 06.01.2010 21:21, Jean Delvare pisze: > > On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote: > >> It is not the error message itself that bothers me but the fact that IR > >> remote control device is not detected and I cannot use it (I checked it > >> on Windows and it's working). After finding this thread I thought it > >> could have had something to do with this error mesage. > >> Is there something that can be done to get my IR remote control working? > > You could try loading the saa7134 driver with option card=146 and see > > if it helps. > > It works! > > [ 15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as > /devices/pci:00/:00:1e.0/:05:00.0/input/input8 > > Thank you very much fo your help. Then I would suggest the following patch: * * * * * From: Jean Delvare Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131 Analog (card=146). However, by the time we find out, some card-specific initialization is missed. In particular, the fact that the IR is GPIO-based. Set it when we change the card type. Signed-off-by: Jean Delvare Tested-by: Daro --- linux/drivers/media/video/saa7134/saa7134-cards.c |1 + 1 file changed, 1 insertion(+) --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c 2009-12-11 09:47:47.0 +0100 +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-09 16:23:17.0 +0100 @@ -7257,6 +7257,7 @@ int saa7134_board_init2(struct saa7134_d printk(KERN_INFO "%s: P7131 analog only, using " "entry of %s\n", dev->name, saa7134_boards[dev->board].name); + dev->has_remote = SAA7134_REMOTE_GPIO; } break; case SAA7134_BOARD_HAUPPAUGE_HVR1150: * * * * * > I have another question regarding this driver: > > [ 21.340316] saa7133[0]: dsp access error > [ 21.340320] saa7133[0]: dsp access error > > Do those messages imply something wrong? Can they have something do do > with the fact I cannot get the sound out of tvtime application directly > and have to use "arecord | aplay" workaround which causes undesirable delay? Yes, the message is certainly related to your sound problem. Maybe support for your card is incomplete. But I can't help with this, sorry. -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gspca - pac7302: Add a delay on loading the bridge registers.
On Fri, 08 Jan 2010 18:29:02 +0100 Németh Márton wrote: > > Without the delay, the usb_control_msg() may fail when loading the > > page 3 with error -71 or -62. > > > > Priority: normal > > > > Signed-off-by: Jean-Francois Moine > > include/asm-generic/errno.h: > > #define ETIME 62 /* Timer expired */ > > #define EPROTO 71 /* Protocol error */ > > I'm interested in which device have you used for testing this? Hi, These errors occured with the webcam 06f8:3009, but I do not know exactly how. I thought about a speed problem. May be, when the webcam cannot treat quickly enough the requests, either it returns errors or it crashes. An other cause could be a bug in the ohci_hcd, but I do not looked at it. The delay was just a test and it fixed the problem. That is all the user wanted... Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: IR device at I2C address 0x7a
W dniu 06.01.2010 21:21, Jean Delvare pisze: On Wed, 06 Jan 2010 20:10:30 +0100, Daro wrote: W dniu 06.01.2010 19:40, Jean Delvare pisze: On Wed, 06 Jan 2010 18:58:58 +0100, Daro wrote: It is not the error message itself that bothers me but the fact that IR remote control device is not detected and I cannot use it (I checked it on Windows and it's working). After finding this thread I thought it could have had something to do with this error mesage. Is there something that can be done to get my IR remote control working? Did it ever work on Linux? I have no experience on that. I bought this card just few weeks ago and tried it only on Karmic Koala. OK. You could try loading the saa7134 driver with option card=146 and see if it helps. It works! [ 15.477875] input: saa7134 IR (ASUSTeK P7131 Analo as /devices/pci:00/:00:1e.0/:05:00.0/input/input8 Thank you very much fo your help. I have another question regarding this driver: [ 21.340316] saa7133[0]: dsp access error [ 21.340320] saa7133[0]: dsp access error Do those messages imply something wrong? Can they have something do do with the fact I cannot get the sound out of tvtime application directly and have to use "arecord | aplay" workaround which causes undesirable delay? -- 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: Fwd: Compro S300 - ZL10313
On Wednesday, 6. January 2010, Theunis Potgieter wrote: > 2010/1/2 JD Louw : > > On Sat, 2010-01-02 at 09:39 +0200, Theunis Potgieter wrote: > > > > Hi, > > > > Just to clarify, can you now watch channels? > > > > At the moment the signal strength measurement is a bit whacked, so don't > > worry too much about it. I also get the 75%/17% figures you mentioned > > when tuning to strong signals. The figure is simply reported wrongly: > > even weaker signals should tune fine. If you want you can have a look in > > ~/v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c at > > mt312_read_signal_strength(). > > > > Also, if you have a multimeter handy, can you confirm that the > > 0xc000 GPIO fix enables LNB voltage? I'd like to issue a patch for > > this. I've already tested this on my older card with no ill effect. > Does this gpio value changes voltage? If yes it is possible to hook into set_voltage and use this to disable LNB voltage for power saving. > This is what happened when I started vdr. > > Vertical gave a Volt reading between 13.9 and 14.1, Horizontal Gave > 19.4 ~ 19.5. When I stopped vdr, the Voltage went back to 14V. I > thought that it would read 0V. What is suppose to happen? > Sounds good so far. The voltage after stopping vdr is no surprise with zl10313, look into the code at mt312.c line 425, The value it writes for no voltage is the same as for vertical voltage. 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
Re: problem webcam gspca 2.6.32
On Sat, 9 Jan 2010 09:32:39 +0100 sacarde wrote: > on my archlinux-64 I have a webcam: 0471:0322 Philips DMVC1300K PC > Camera > until one mounth ago this works OK with driver: gspca_sunplus > > now with kernel 2.6.32 not works Hi, Oops, I introduced a bug in the sunplus driver of the kernel 2.6.32. I attach a patch, but this one applies to my gspca development repository at LinuxTv.org (http://linuxtv.org/hg/~jfrancois/gspca). May you get this last version and check the patch? Thank you. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ sunplus.pat Description: Binary data
Re: problem webcam gspca 2.6.32
Also, if you can, try the lastest from linuxtv.org On Sat, Jan 9, 2010 at 10:05 AM, Sean wrote: > What kind of errors or problems are you getting? > > Can you turn on debugging and give us some output? > > Sean > --Original Message-- > From: sacarde > Sender: linux-media-ow...@vger.kernel.org > To: linux-media@vger.kernel.org > Subject: problem webcam gspca 2.6.32 > Sent: Jan 9, 2010 12:32 AM > > hi, > on my archlinux-64 I have a webcam: 0471:0322 Philips DMVC1300K PC Camera > > until one mounth ago this works OK with driver: gspca_sunplus > > now with kernel 2.6.32 not works > I start cheese and I view: http://sacarde.interfree.it/errore-cheese.png > and this messages: > Cheese 2.28.1 > Probing devices with HAL... > Found device 0471:0322, getting capabilities... > Detected v4l2 device: USB Camera (0471:0322) > Driver: sunplus, version: 132864 > Capabilities: 0x0501 > Probing supported video formats... > > > from dmesg: > ... > gspca: probing 0471:0322 > gspca: probe ok > ... > /dev/video0 is created > > > I try to downgrade previus kernel kernel26 2.6.31.6-1 and dependencies > > and it works: > > when it works 2.6.31: Driver: sunplus, version: 132608 > > > thankyou > > > > saca...@tiscali.it > -- > 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
[PATCH] drivers/media/dvb/bt8xx/dst.c:fixes for DVB-C Twinhan VP2031 in Linux-2.6.32
Remove check "state->dst_type == DST_DTYPE_IS_CABLE" in function
dst_get_tuna (around line 1352) to select the correct checksum
computation
Fill in the .caps field in struct dst_dvbc_ops (around line 1824) with
all the supported QAM modulation methods to match the capabilities of
the card as implemented in function dst_set_modulation (around line
502). Note that beginning with linux kernel version 2.6.32 the
modulation method is checked (by function
dvb_frontend_check_parameters in file
drivers/media/dvb/dvb-core/dvb_frontend.c) and thus tuning fails if
you use a modulation method that is not present in the .caps field.
This patch has been tested on a Twinhan VP2031A DVB-C card with the
2.6.32.2 kernel.
Signed-off-by: Klaas de Waal
--
diff -r b6b82258cf5e linux/drivers/media/dvb/bt8xx/dst.c
--- a/linux/drivers/media/dvb/bt8xx/dst.c Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/dvb/bt8xx/dst.c Sat Jan 09 11:41:52 2010 +0100
@@ -1352,7 +1352,7 @@
return retval;
}
if ((state->type_flags & DST_TYPE_HAS_VLF) &&
- !(state->dst_type == DST_TYPE_IS_CABLE) &&
+ /* !(state->dst_type == DST_TYPE_IS_CABLE) && */
!(state->dst_type == DST_TYPE_IS_ATSC)) {
if (state->rx_tuna[9] != dst_check_sum(&state->rx_tuna[0], 9)) {
@@ -1821,7 +1821,7 @@
.symbol_rate_min = 100,
.symbol_rate_max = 4500,
/* . symbol_rate_tolerance = ???,*/
- .caps = FE_CAN_FEC_AUTO | FE_CAN_QAM_AUTO
+ .caps = FE_CAN_FEC_AUTO | FE_CAN_QAM_16 | FE_CAN_QAM_32 |
FE_CAN_QAM_64 | FE_CAN_QAM_128 | FE_CAN_QAM_256
},
.release = dst_release,
--
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 webcam gspca 2.6.32
What kind of errors or problems are you getting?
Can you turn on debugging and give us some output?
Sean
--Original Message--
From: sacarde
Sender: linux-media-ow...@vger.kernel.org
To: linux-media@vger.kernel.org
Subject: problem webcam gspca 2.6.32
Sent: Jan 9, 2010 12:32 AM
hi,
on my archlinux-64 I have a webcam: 0471:0322 Philips DMVC1300K PC Camera
until one mounth ago this works OK with driver: gspca_sunplus
now with kernel 2.6.32 not works
I start cheese and I view: http://sacarde.interfree.it/errore-cheese.png
and this messages:
Cheese 2.28.1
Probing devices with HAL...
Found device 0471:0322, getting capabilities...
Detected v4l2 device: USB Camera (0471:0322)
Driver: sunplus, version: 132864
Capabilities: 0x0501
Probing supported video formats...
from dmesg:
...
gspca: probing 0471:0322
gspca: probe ok
...
/dev/video0 is created
I try to downgrade previus kernel kernel26 2.6.31.6-1 and dependencies
and it works:
when it works 2.6.31: Driver: sunplus, version: 132608
thankyou
saca...@tiscali.it
--
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
N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±çbj)í
æèw* jg¬±¨ ¶Ý¢j/êäz¹Þà2Þ¨èÚ&¢)ß¡«a¶Úþø ®G«éh®æj:+v¨wèÙ¥
problem webcam gspca 2.6.32
hi, on my archlinux-64 I have a webcam: 0471:0322 Philips DMVC1300K PC Camera until one mounth ago this works OK with driver: gspca_sunplus now with kernel 2.6.32 not works I start cheese and I view: http://sacarde.interfree.it/errore-cheese.png and this messages: Cheese 2.28.1 Probing devices with HAL... Found device 0471:0322, getting capabilities... Detected v4l2 device: USB Camera (0471:0322) Driver: sunplus, version: 132864 Capabilities: 0x0501 Probing supported video formats... from dmesg: ... gspca: probing 0471:0322 gspca: probe ok ... /dev/video0 is created I try to downgrade previus kernel kernel26 2.6.31.6-1 and dependencies and it works: when it works 2.6.31: Driver: sunplus, version: 132608 thankyou saca...@tiscali.it -- 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: Kworld 315U and SAA7113?
Attached is an updated diff for the Kworld 315U TV. I believe all the bugs
have been worked out. I haven't figured out the remote control stuff and
hopefully I will be able to get around to it some time.
The sound issue was because I didn't have the right mplayer config so that is
fixed as well.
Other than that, the LED light on the front of the box doesn't shut off after I
start and stop the stream. It's probably a GPIO setting that I need to tweak.
And I wanted to say thank you to Douglas and Devin for the tips they provided
me.
Thanks,
Franklin Meng
--- On Thu, 1/7/10, Franklin Meng wrote:
> From: Franklin Meng
> Subject: Kworld 315U and SAA7113?
> To: linux-media@vger.kernel.org
> Date: Thursday, January 7, 2010, 7:48 PM
> After some work I have finally gotten
> the analog inputs to work with the Kworld 315U device. I
> have attached the changes/updates to the em28xx driver.
> Note: I still don't have analog sound working yet..
>
> I am hoping someone can comment on the changes in
> saa7115.c. I added a s_power routine to reinitialize the
> device. The reason I am reinitializing this device is
> because
>
> 1. I cannot keep both the LG demod and the SAA powered on
> at the same time for my device
>
> 2. The SAA datasheet seems to suggest that after a
> reset/power-on the chip needs to be reinitialized.
>
> 3. Reinitializing causes the analog inputs to work
> correctly.
>
> Here's what is says in the SAA7113 datasheet..
>
> Status after power-on
> control sequence
>
> VPO7 to VPO0, RTCO, RTS0 and RTS1
> are held in high-impedance state
>
> after power-on (reset
> sequence) a complete
> I2C-bus transmission is
> required
> ...
> The above is really suppose to be arranged horizontally in
> 3 columns. Anyways, the last part describes that "a
> complete I2C bus transmission is required" This is why
> I think the chip needs to be reinitialized.
>
>
> Last thing is that the initialization routing uses these
> defaults:
>
> state->bright = 128;
> state->contrast = 64;
> state->hue = 0;
> state->sat = 64;
>
> I was wondering if we should just read the back the values
> that were initialized by the initialization routine and use
> those values instead.The reason is because it seems like the
> different SAA's use slightly different values when
> initializing.
>
> Thanks,
> Franklin Meng
>
>
>
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 Sat Jan 09 00:21:39 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},
{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,12 @@
{ -1, -1, -1, -1},
};
+/* Board - EM2882 Kworld 315U suspend */
+static struct em28xx_reg_seq em2882_kworld_315u_suspend[] = {
+ {EM28XX_R08_GPIO, 0xff, 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},
@@ -1314,28 +1338,28 @@
.decoder = EM28XX_SAA711X,
.has_dvb = 1,
.dvb_gpio = em2882_kworld_315u_digital,
+ .suspend_gpio = em2882_kworld_315u_suspend,
.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
.i2c_speed = EM28XX_I2C_CLK_WAIT_ENABLE,
- /* Analog mode - still not ready */
- /*.input= { {
+ .input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = SAA7115_COMPOSITE2,
.amux = EM28XX_AMUX_VIDEO,
- .gpio = em2882_kworld_315u_analog,
+ .gpio = em2882_kworld_315u_analog1,
.aout = EM28XX_AOUT_PCM_IN | EM28XX_AOUT_PCM_STEREO,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = SAA7115_COMPOSITE0,
.amux = EM28XX_AMUX_LINE_IN,
- .gpio = em2882_kworld_315u_analog1,
+ .gpio = em2882_kworld_315u_analog2,
.aout = EM28XX_AOUT_PCM_IN | EM28XX_AOUT_PCM_STEREO,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = SAA7115_SVIDEO3,
.amux = EM28XX_AMUX_LINE_IN,
- .gpio = em2882_kworld_315u_analog1,
+ .
