Re: VL4-DVB compilation issue not covered by Daily Automated
Devin Heitmueller a écrit : On Tue, Jan 12, 2010 at 4:26 PM, Hagen von Eitzen ha...@von-eitzen.de wrote: Dear all, as suggested by http://www.linuxtv.org/wiki/index.php/Bug_Report I report several warnings and errors not yet covered in latest http://www.xs4all.nl/~hverkuil/logs/Monday.log I get when compiling. (The purpose of my experiments was trying to find out something about 0ccd:00a5 TerraTec Electronic GmbH) Regards Hagen This is an Ubuntu-specific issue (they improperly packaged their kernel headers), which will not be covered by the daily build system (which exercises various kernels but not across different Linux distribution versions). Devin Are you sure? (it is an Ubuntu-only issue) I can see several #include asm/asm.h in the v4l tree that compile fine on Ubuntu but only linux/drivers/media/dvb/firewire/firedtv-1394.c contains #include asm.h and doesn't compile. Unfortunately the asm.h asm/asm.h is not the only issue with firedtv-1394.c (on Ubuntu/Karmic Koala?). The /drivers/ieee1394/*.h seem to be in the linux-sources tree and not in the linux-headers one (?) Everywhere I look, I read don't bother, just disable firedtv-1394.c until they fix it. xof - But my problem is 'I have no audio on an Hercules Smart TV 2 Stereo' (bttv0: subsystem: 1540:952b; Card-100, Tuner-38). It works on a Dapper LiveCD (with a good /etc/modprobe.d/bttv, a ~/.xawtv and xawtv installed). The problem seems to exist since 2008... -- 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
Alle sabato 09 gennaio 2010, hai scritto: On Sat, 9 Jan 2010 15:06:14 +0100 ... Jean-Francois Moine write: I got the source of sunplus.c in the last kernel 2.6.32 and I build the attached patch. May you test it? ok, I build with your patch diff-2.6.32 - now mplayer tv:// works OK !! - now cheese -v once it works and once no (I can view only black-window) ...when works... 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... Device: USB Camera (0471:0322) (/dev/video0) FractionRange: 0/1 - 100/1 video/x-raw-rgb 640 x 480 num_framerates 101 0/1 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1 9/1 10 ... ... ... etc thanks 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
[PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix
Mauro, Please pulll change: http://udev.netup.ru/hg/v4l-dvb-aospan-22fix/ 22-kHz set_tone fix for NetUP Dual DVB-S2-CI card. Description: 22-kHz tone can be driven in two ways: 1. LNBH24 can produce 22kHz continuous tone when TEN=1 ( 22 KHz tone output is always activated ). 2. LNBH24 can reproduce 22kHz tone timings from DSQIN or EXTM pin's when TEN=0. From LNBH24 datasheet: In order to improve design flexibility an external tone input pin is available (EXTM). The EXTM is a Logic input pin which activates the 22 kHz tone output, on the VoTX pin, by using the LNBH24 integrated tone generator (similar to the DSQIN pin function). In fact, the output tone waveform characteristics will always be internally controlled by the LNBH24 tone generator and the EXTM signal will be used as a timing control for DiSEqC tone data encoding on the VoTX output. In NetUP Dual DVB-S2-CI card 22kHz tone timings on EXTM pin produced by STV0900 demod: .set_tone = stv0900_set_tone redefine to set_tone = lnbp21_set_tone is not correct for NetUP Dual DVB-S2-CI card. -- Abylai Ospan aos...@netup.ru NetUP Inc. P.S. Also I think diseqc doesn't work when TEN bit enabled in LNBH24 (22kHz tone can't be modulated by demod), but need to check ... signature.asc Description: This is a digitally signed message part
Re: ISP OMAP3 camera support ov7690
Hi, I have done a step ahead maybe: The camera has this output format: YUYV --- the first use the CCDC_OTHERS_MEM, so seems that it needs the WEN signal to syncronize (I don't have this one) RGB565 --- is not supported RAW8 --- is supported by the ISP but seems that is not implemented as a isp formats So I can't use the first one but I can use the last one because the pipeline support RAW format, the data path is the same of RAW10 expet for the autofocus module. If all is correct what are the steps? - add the isp_format - add in the if confidition this data format and use the same path of RAW10 ... Regards Michael -- 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
[RESEND PATCH 3/5] V4L/DVB sh_mobile_ceu: don't check platform_get_irq's return value against zero
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 u.kleine-koe...@pengutronix.de
Cc: David Vrabel dvra...@arcom.com
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Magnus Damm d...@igel.co.jp
Cc: Kuninori Morimoto morimoto.kunin...@renesas.com
Cc: Paul Mundt let...@linux-sh.org
Cc: linux-media@vger.kernel.org
---
drivers/media/video/sh_mobile_ceu_camera.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index d69363f..f09c714 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -1827,7 +1827,7 @@ static int __devinit sh_mobile_ceu_probe(struct
platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
irq = platform_get_irq(pdev, 0);
- if (!res || !irq) {
+ if (!res || (int)irq = 0) {
dev_err(pdev-dev, Not enough CEU platform resources.\n);
err = -ENODEV;
goto exit;
--
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
[RESEND PATCH 2/5] V4L/DVB mx1_camera: don't check platform_get_irq's return value against zero
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 u.kleine-koe...@pengutronix.de
Cc: David Vrabel dvra...@arcom.com
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Antonio Ospite osp...@studenti.unina.it
Cc: Paulius Zaleckas paulius.zalec...@teltonika.lt
Cc: linux-media@vger.kernel.org
---
drivers/media/video/mx1_camera.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index 2ba14fb..c167cc3 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -718,7 +718,7 @@ static int __init mx1_camera_probe(struct platform_device
*pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
irq = platform_get_irq(pdev, 0);
- if (!res || !irq) {
+ if (!res || (int)irq = 0) {
err = -ENODEV;
goto exit;
}
--
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: [PATCH 1/1] media: video/cx18, fix potential null dereference
On Tue, 2010-01-12 at 12:28 +0100, Jiri Slaby wrote: On 01/12/2010 12:48 AM, Andy Walls wrote: On Sun, 2010-01-10 at 09:56 +0100, Jiri Slaby wrote: Stanse found a potential null dereference in cx18_dvb_start_feed and cx18_dvb_stop_feed. There is a check for stream being NULL, but it is dereferenced earlier. Move the dereference after the check. Signed-off-by: Jiri Slaby jsl...@suse.cz Reviewed-by: Andy Walls awa...@radix.net Acked-by: Andy Walls awa...@radix.net You definitely know the code better, have you checked that it can happen at all? I mean may demux-priv be NULL? I'm wasn't sure, and that's the one reason I didn't NAK the patch. I can tell you no one has ever reported an Ooops or Bug due to that condition. I know the cx18 code very well. However, I am less familiar with the dvb core code and any bad behavior that may exist there. When relying on data structures the dvb core accesses I would have to research what could happen in the dvb core to possibly generate that condition. Since I'm busy this week with work related to my day job (nothing to do with Linux), it was easiest to let the NULL check stay in for now. If you don't mind a delay of until Sunday or so to get the patch applied to the V4L-DVB tree, I can take the patch and work it in my normal path through Mauro. Let me know. Regards, Andy -- 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: video/cx18, fix potential null dereference
On 01/13/2010 12:32 PM, Andy Walls wrote: If you don't mind a delay of until Sunday or so to get the patch applied to the V4L-DVB tree, I can take the patch and work it in my normal path through Mauro. Let me know. I have no problem with that. thanks, -- 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
Re: [PATCH 1/1] media: video/cx18, fix potential null dereference
On Tue, Jan 12, 2010 at 3:28 PM, Jiri Slaby jirisl...@gmail.com wrote: On 01/12/2010 12:48 AM, Andy Walls wrote: On Sun, 2010-01-10 at 09:56 +0100, Jiri Slaby wrote: Stanse found a potential null dereference in cx18_dvb_start_feed and cx18_dvb_stop_feed. There is a check for stream being NULL, but it is dereferenced earlier. Move the dereference after the check. Signed-off-by: Jiri Slaby jsl...@suse.cz Reviewed-by: Andy Walls awa...@radix.net Acked-by: Andy Walls awa...@radix.net You definitely know the code better, have you checked that it can happen at all? I mean may demux-priv be NULL? It is highly unlikely that demux-priv becoming NULL. The only time that could happen would be when there is a dvb register failed. But in which case, it wouldn't reach the stage where you want to start/stop a stream. 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: platform_get_irq() v4l fixes
Hi Uwe Your patches have been included in my pull request of 10.01.2010: http://www.spinics.net/lists/linux-media/msg14449.html 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
[PATCH] ir-kbd-i2c: Allow to disable Hauppauge filter through module parameter
Some Hauppauge devices have id=0 so such devices won't work.
For such devices add a module parameter that allow to turns
off filtering.
Signed-off-by: Samuel Rakitničan semiroc...@gmail.com
---
diff -r 82bbb3bd0f0a linux/drivers/media/video/ir-kbd-i2c.c
--- a/linux/drivers/media/video/ir-kbd-i2c.cMon Jan 11 11:47:33 2010
-0200
+++ b/linux/drivers/media/video/ir-kbd-i2c.cWed Jan 13 13:46:53 2010
+0100
@@ -61,6 +61,10 @@
module_param(hauppauge, int, 0644);/* Choose Hauppauge remote */
MODULE_PARM_DESC(hauppauge, Specify Hauppauge remote: 0=black, 1=grey
(defaults to 0));
+static int haup_filter = 1;
+module_param(haup_filter, int, 0644);
+MODULE_PARM_DESC(haup_filter, Hauppauge filter for other remotes,
default is 1 (On));
+
#define DEVNAME ir-kbd-i2c
#define dprintk(level, fmt, arg...)if (debug = level) \
@@ -96,24 +100,27 @@
if (!start)
/* no key pressed */
return 0;
- /*
-* Hauppauge remotes (black/silver) always use
-* specific device ids. If we do not filter the
-* device ids then messages destined for devices
-* such as TVs (id=0) will get through causing
-* mis-fired events.
-*
-* We also filter out invalid key presses which
-* produce annoying debug log entries.
-*/
- ircode= (start 12) | (toggle 11) | (dev 6) | code;
- if ((ircode 0x1fff)==0x1fff)
- /* invalid key press */
- return 0;
- if (dev!=0x1e dev!=0x1f)
- /* not a hauppauge remote */
- return 0;
+ if (haup_filter != 0) {
+ /*
+* Hauppauge remotes (black/silver) always use
+* specific device ids. If we do not filter the
+* device ids then messages destined for devices
+* such as TVs (id=0) will get through causing
+* mis-fired events.
+*
+* We also filter out invalid key presses which
+* produce annoying debug log entries.
+*/
+ ircode = (start 12) | (toggle 11) | (dev 6) |
code;
+ if ((ircode 0x1fff) == 0x1fff)
+ /* invalid key press */
+ return 0;
+
+ if (dev != 0x1e dev != 0x1f)
+ /* not a hauppauge remote */
+ return 0;
+ }
if (!range)
code += 64;
--
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: pull request: http://linuxtv.org/hg/~hgoede/gspca
Hans de Goede wrote: Hi, On 01/10/2010 12:53 PM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca For: 1) A high priority (should go to 2.6.33) mr97310a driver fix 2) A new driver for streaming from sn9c2028 cams 3) Some gspca documentation updates Hmm... your tree has 10 patches instead of 3.: /tmp/newpatches/hg_gspca_01.patch with cs=47d5a57b0183 First patch. /tmp/newpatches/hg_gspca_02.patch with cs=04eee693d37b Ok. /tmp/newpatches/hg_gspca_03.patch with cs=c7f961161530 Ok. /tmp/newpatches/hg_gspca_04.patch with cs=da3d3538b4c4 Ok. /tmp/newpatches/hg_gspca_05.patch with cs=98cecfa3c4f1 Ok. /tmp/newpatches/hg_gspca_06.patch with cs=bfe405de18aa Ok. /tmp/newpatches/hg_gspca_07.patch with cs=325c97ecffd2 Ok. /tmp/newpatches/hg_gspca_08.patch with cs=2e531e32ca6f Ok. /tmp/newpatches/hg_gspca_09.patch with cs=3563e7b617fe Ok. /tmp/newpatches/hg_gspca_10.patch with cs=21d70b6ed9f6 Ok. As I'm not sure if all of them are ready for merging, the better is to wait for a new pull request. Next time, please avoid add newer patches on a tree you've asked me to pull, or reply your pull email warning me that you've added more patches on your tree. Sorry, I wanted to send a new pull request yesterday, telling you to pull all 10 changes, 9 of time are marked as high priority, iow are meant for 2.6.33, the 10th one is a new driver so could go to 2.6.33 too, but does not has to. Summary of the changes: gspca_ov519: Several fixes related to ov519 + ov7648 gscpa_stv0680: Fix cam not streaming on hotplug gscpa_stv0680: Fix VGA cams not streaming gspca_sn9c2028: New gspca subdriver gscpa_sonixb:Fix hstart of tas5110d sensor Hans, It seems that you didn't properly set your mercurial environment. All patches has a wrong user: # HG changeset patch # User h...@rhel5-devel.localdomain # Date 1261728910 -3600 # Node ID 47d5a57b018343b02a0ea9de83380c1341867694 # Parent a7036c23ed813eb1051ce7b598fb742c08d2394f This will produce a wrong log if I merge from your tree. Please correct and re-submit. README.patches contain instructions on how to set it. Thanks 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Devin Heitmueller wrote: You didn't forget about the em28xx PAL VBI tree, right? I'm just mentioning it because the PULL has been pending for several weeks and came long before the PULL for the HVR-1600 ALSA changes. I tried to, but the hgimport script doesn't like https trees: $ ./hgimport https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 Pushing from local directory https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2, tree=em28xx-pal-vbi-2 abort: repository 'https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2' is not local Number of patches: 0 Diffstat of the imported series: /tmp/newpatches/hg_em28xx-pal-vbi-2_*.patch: No such file or directory checkpatch.pl: /tmp/newpatches/*.patch: open failed - Arquivo ou diretório não encontrado To cherry pick all files, you can do something like: for i in /tmp/newpatches/*.patch; do ./mailimport $i || exit; done To review all files, you can do something like: for i in /tmp/newpatches/*.patch; do ./v4l/scripts/hghead.pl /tmp/newpatches/*.patch kompare /tmp/newpatches/*.patch; done To merge it, the better is to run the merge script: ./v4l/scripts/do_merge.pl https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 If you really want to submit https pull requests, please fix hgimport script to accept (I would fix if I had enough time, but I'm with a big backlog, so it is not my priority). Otherwise, please indicate me an http site for me to pull. Thanks, 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: Problem with gspca and zc3xx
El Martes, 12 de Enero de 2010, Jose Alberto Reguero escribió: El Martes, 12 de Enero de 2010, Jean-Francois Moine escribió: On Mon, 11 Jan 2010 15:49:55 +0100 Jose Alberto Reguero jaregu...@telefonica.net wrote: I take another image with 640x480 and the bad bottom lines are 8. The right side look right this time. The good sizes are: 320x240-320x232 640x480-640x472 Hi Jose Alberto and Hans, Hans, I modified a bit your patch to handle the 2 resolutions (also, the problem with pas202b does not exist anymore). May you sign or ack it? Jose Alberto, the attached patch is to be applied to the last version of the gspca in my test repository at LinuxTv.org http://linuxtv.org/hg/~jfrancois/gspca May you try it? Regards. The patch works well. There is another problem. When autogain is on(default), the image is bad. It is possible to put autogain off by default? Thanks. Jose Alberto Autogain works well again. I can't reproduce the problem. Perhaps the debug messages. (Now I have debug off). Thanks. Jose Alberto -- 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Wed, Jan 13, 2010 at 8:44 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Devin Heitmueller wrote: You didn't forget about the em28xx PAL VBI tree, right? I'm just mentioning it because the PULL has been pending for several weeks and came long before the PULL for the HVR-1600 ALSA changes. I tried to, but the hgimport script doesn't like https trees: $ ./hgimport https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 Pushing from local directory https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2, tree=em28xx-pal-vbi-2 abort: repository 'https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2' is not local Number of patches: 0 Diffstat of the imported series: /tmp/newpatches/hg_em28xx-pal-vbi-2_*.patch: No such file or directory checkpatch.pl: /tmp/newpatches/*.patch: open failed - Arquivo ou diretório não encontrado To cherry pick all files, you can do something like: for i in /tmp/newpatches/*.patch; do ./mailimport $i || exit; done To review all files, you can do something like: for i in /tmp/newpatches/*.patch; do ./v4l/scripts/hghead.pl /tmp/newpatches/*.patch kompare /tmp/newpatches/*.patch; done To merge it, the better is to run the merge script: ./v4l/scripts/do_merge.pl https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 If you really want to submit https pull requests, please fix hgimport script to accept (I would fix if I had enough time, but I'm with a big backlog, so it is not my priority). Otherwise, please indicate me an http site for me to pull. Thanks, Mauro Mauro, The same tree is also available using http instead of https: http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 This should work for you without issue. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Michael Krufky wrote: The same tree is also available using http instead of https: http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 This should work for you without issue. Ok. Applied, thanks! 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: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix
Hi, Abylai Ospan wrote: Please pulll change: http://udev.netup.ru/hg/v4l-dvb-aospan-22fix/ 22-kHz set_tone fix for NetUP Dual DVB-S2-CI card. NAK. Description: 22-kHz tone can be driven in two ways: 1. LNBH24 can produce 22kHz continuous tone when TEN=1 ( 22 KHz tone output is always activated ). 2. LNBH24 can reproduce 22kHz tone timings from DSQIN or EXTM pin's when TEN=0. From LNBH24 datasheet: In order to improve design flexibility an external tone input pin is available (EXTM). The EXTM is a Logic input pin which activates the 22 kHz tone output, on the VoTX pin, by using the LNBH24 integrated tone generator (similar to the DSQIN pin function). In fact, the output tone waveform characteristics will always be internally controlled by the LNBH24 tone generator and the EXTM signal will be used as a timing control for DiSEqC tone data encoding on the VoTX output. In NetUP Dual DVB-S2-CI card 22kHz tone timings on EXTM pin produced by STV0900 demod: .set_tone = stv0900_set_tone redefine to set_tone = lnbp21_set_tone is not correct for NetUP Dual DVB-S2-CI card. Why is it not correct? Please explain. Afaics it does not matter, whether the demod or the LNBH24 controls the 22kHz tone. With your patch, lnbp21_set_tone would never be used... CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: VL4-DVB compilation issue not covered by Daily Automated
On Wed, Jan 13, 2010 at 3:32 AM, xof x...@skynet.be wrote: Are you sure? (it is an Ubuntu-only issue) I can see several #include asm/asm.h in the v4l tree that compile fine on Ubuntu but only linux/drivers/media/dvb/firewire/firedtv-1394.c contains #include asm.h and doesn't compile. Unfortunately the asm.h asm/asm.h is not the only issue with firedtv-1394.c (on Ubuntu/Karmic Koala?). The /drivers/ieee1394/*.h seem to be in the linux-sources tree and not in the linux-headers one (?) Everywhere I look, I read don't bother, just disable firedtv-1394.c until they fix it. I think perhaps you meant to write dma.h and not asm.h. All of the missing includes in the error log (including dma.h) are for files that are found in the iee1394 source directory, which are not provided in the Ubuntu linux-headers package. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Wed, Jan 13, 2010 at 9:00 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Michael Krufky wrote: The same tree is also available using http instead of https: http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 This should work for you without issue. Ok. Applied, thanks! Sorry about that. I typically cut/paste the link from my browser (and we support both http and https for the HG repo). I will be sure that future PULL requests are http only. Also, I haven't had a chance to rebase this tree against the tip yet, as I burned too much time over the weekend tracking down the regression you introduced into the with the ir-sysfs rework. Did that one line patch get merged yet? It's pretty embarrassing to have a situation for nearly a month where the mainline v4l-dvb causes an OOPS just because they happen to have IR support. In my case, I couldn't even get my PC to boot until I pulled the card from the machine. I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. 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: [RFC PATCH] Fix and invalid array indexing in isp_csi2_complexio_lanes_config
Nice catch! Patch looks good to me. I'm pushing it into my omap-devel branch, which I'll later rebase to latest Sakari's tree and send among other patches I have in my queue for him. Regards, Sergio -Original Message- From: Michael Trimarchi [mailto:mich...@panicking.kicks-ass.org] Sent: Tuesday, January 12, 2010 2:23 PM To: Sakari Ailus; Aguirre, Sergio Cc: linux-media@vger.kernel.org Subject: [RFC PATCH] Fix and invalid array indexing in isp_csi2_complexio_lanes_config -- 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] RFC: mx27: Add soc_camera support
Hi Javier, On 1/4/10, javier Martin javier.mar...@vista-silicon.com wrote: 2010/1/4 javier Martin javier.mar...@vista-silicon.com 2010/1/4 Alan Carvalho de Assis acas...@gmail.com Hi Javier, On 1/4/10, javier Martin javier.mar...@vista-silicon.com wrote: Alan, please, could you point me against which kernel version did you exactly test this patch? It applies on current kernel from git.pengutronix.de/git/imx/linux-2.6.git Thank you for your feedback Alan. Also it would be fine to know which video sensor did you use. I'm planning to use an OV2640 camera. Does this mean that this patch you are sending has been only compile-tested? Argh, sorry, you pointed this in your previous mail. Too bad we don't have any sensor available currently in mainline to do a fast test. Unfortunately my camera is not responding to I2C commands, I already slow it down to 10kbps with no success. I can see on oscilloscope i.MX27 send I2C commands, but the camera doesn't respond to it. Then I tested using the MT9T31 driver and change the it to my I2C commands, as I2C is failing I force the probe to return 0. But the soc_camera still failing: Linux video capture interface: v2.00 write: -5 MT9T31 Read register 0xFF = -5 Forcing mt9t031_video_probe to return OK! mx27-camera mx27-camera.0: initialising mx27-camera: probe of mx27-camera.0 failed with error -2 Best Regards, Alan -- 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
Terratec Cinergy Hybrid XE (TM6010 Mediachip)
I found a bug in tm6000 module. -- Stefan Ringel stefan.rin...@arcor.de Jan 13 20:23:22 linux-v5dy kernel: [ 186.452166] BUG: unable to handle kernel NULL pointer dereference at (null) Jan 13 20:23:22 linux-v5dy kernel: [ 186.452189] IP: [a1720c62] tm6000_read_write_usb+0x92/0x490 [tm6000] Jan 13 20:23:22 linux-v5dy kernel: [ 186.452212] PGD 55136067 PUD 55392067 PMD 0 Jan 13 20:23:22 linux-v5dy kernel: [ 186.452223] Oops: [#1] PREEMPT SMP Jan 13 20:23:22 linux-v5dy kernel: [ 186.452232] last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map Jan 13 20:23:22 linux-v5dy kernel: [ 186.452244] CPU 0 Jan 13 20:23:22 linux-v5dy kernel: [ 186.452249] Modules linked in: mxb hexium_orion gspca_sunplus ov7670 tm6000 gspca_jeilinj gspca_sq905 gspca_sn9c20x gspca_spca561 vivi radio_maestro tuner gspca_stk014 dvb_usb_umt_010 gspca_benq dvb_usb_nova_t_usb2 au0828 tda9875 gspca_etoms vpx3220 radio_gemtek_pci cpia_usb saa6588 vp27smpx konicawc gspca_spca505 upd64031a tvaudio radio_mr800 bt819 saa7110 gspca_conex gspca_mars gspca_finepix quickcam_messenger cs53l32a dvb_usb_dibusb_mc tvp5150 cx2341x gspca_stv0680 cx88xx usbvision mantis ths7303 m52790 gspca_spca506 gspca_spca501 gspca_ov534 w9968cf saa7185 dvb_ttpci ks0127 cpia2 dvb_usb_dibusb_mb zr36067 hdpvr radio_si4713 tvp514x budget_av cx231xx gspca_sonixj gspca_ov519 saa6752hs cs5345 cafe_ccic saa5249 upd64083 ultracam mt9v011 radio_maxiradio gspca_spca500 gspca_pac7311 saa7115 dsbr100 au8522 saa7134 cpia_pp wm8775 dvb_usb_a800 si4713_i2c tda9840 bttv gspca_stv06xx tlv320aic23b saa717x ovcamchip hexium_gemini ibmcam tef6862 radio_usb_si470x adv7343 saa7127 msp3400 em2 Jan 13 20:23:22 linux-v5dy kernel: 8xx saa7191 bt866 gspca_tv8532 tea6420 gspca_pac7302 gspca_zc3xx gspca_pac207 gspca_vc032x gspca_mr97310a adv7180 gspca_gl860 saa5246a tda7432 dvb_usb_ec168 budget_patch ov511 dvb_usb_dw2102 stradis snd_tea575x_tuner se401 dvb_usb_anysee pwc bw_qcam uvcvideo stv680 b2c2_flexcop_usb dvb_usb_cinergyT2 dvb_usb_au6610 dvb_usb_m920x dvb_usb_dib0700 dvb_usb_vp702x et61x251 v4l2_common zc0301 stkwebcam dvb_usb_cxusb mantis_core dm1105 dvb_usb_opera c_qcam dvb_usb_dtv5100 zr364xx saa7146_vv dvb_usb_vp7045 vicam dvb_usb_gl861 dvb_usb_dtt200u dvb_usb_digitv dvb_usb_friio budget usbvideo soc_camera_platform radio_tea5764 budget_ci dvb_usb_gp8psk gspca_main ir_kbd_i2c dvb_usb_ce6230 meye b2c2_flexcop_pci cpia dvb_usb_af9005 dvb_usb_af9015 sn9c102 s2255drv dvb_usb_ttusb2 dvb_usb_dibusb_common w9966 lgdt3305 budget_core stv0299 pluto2 dib7000m dib7000p tcm825x b2c2_flexcop smssdio ir_common zr36050 lgdt330x zr36016 smsusb videobuf_vmalloc or51132 videodev ttusb_dec zr36060 smsdvb saa7164 dib3000mc Jan 13 20:23:22 linux-v5dy kernel: dib8000 tuner_simple dvb_usb videobuf_dma_sg dvb_ttusb_budget or51211 firedtv videobuf_dvb videobuf_dma_contig earth_pt1 stv0288 stb0899 sp887x v4l2_compat_ioctl32 s5h1409 mt2266 soc_mediabus ds3000 tuner_types tda10023 tua6100 mt20xx btcx_risc tda18271 cx22702 videocodec tda10086 tea5767 mt312 s921 max2165 dvb_dummy_fe tda8261 qt1010 af9013 cx88_vp3054_i2c tda1004x tda665x nxt200x ves1820 bcm3510 isl6423 zl10036 mxl5007t drx397xD sp8870 cx24113 tda8290 l64781 cx24110 tda827x dabusb saa7146 ttpci_eeprom stb6100 tda10048 tda826x ttusbdecfe s5h1411 lgdt3304 ves1x93 stv0297 dib3000mb tda8083 lnbp21 zl10039 dibx000_common snd_bt87x ir_core tda9887 isl6421 mt2060 mb86a16 zl10353 tda10021 dvb_usb_af9005_remote cx22700 lgs8gxx s5h1420 mt352 v4l1_compat dvb_core isl6405 xc5000 ec100 tea5761 stv6110x mxl5005s dvb_pll dib0090 stb6000 v4l2_int_device mt2131 videobuf_core tveeprom stv0900 lgs8gl5 atbm8830 stv6110 mc44s803 cx24116 cx24123 stv090x dib0070 si21xx tuner_xc2028 nxt6000 itd1000 smsmdtv Jan 13 20:23:22 linux-v5dy kernel: sony_laptop rfkill mmc_core i2c_algo_bit ip6t_LOG xt_tcpudp xt_pkttype ipt_LOG xt_limit snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device edd vmnet ppdev parport_pc parport vmblock vsock vmci vmmon af_packet ip6t_REJECT nf_conntrack_ipv6 ip6table_raw xt_NOTRACK ipt_REJECT xt_state iptable_raw iptable_filter ip6table_mangle nf_conntrack_netbios_ns nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables ip6table_filter cpufreq_conservative cpufreq_userspace ip6_tables cpufreq_powersave x_tables powernow_k8 fuse nls_iso8859_1 nls_cp437 vfat fat loop dm_mod snd_hda_codec_intelhdmi snd_hda_codec_analog amd64_edac_mod snd_hda_intel ohci1394 snd_hda_codec edac_core sg sr_mod snd_hwdep ieee1394 edac_mce_amd nvidia(P) cdrom snd_pcm k8temp snd_timer serio_raw forcedeth i2c_nforce2 snd snd_page_alloc asus_atk0110 pcspkr button ext4 jbd2 crc16 fan processor ide_pci_generic amd74xx ide_core ata_generic thermal thermal_sys pata_amd sata_nv Jan 13 20:23:22 linux-v5dy kernel: [ 186.453006] Pid: 5751, comm: v4l_id Tainted: P 2.6.32-41.6-desktop #1 System Product Name Jan 13 20:23:22 linux-v5dy kernel: [ 186.453006] RIP: 0010:[a1720c62]
[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:Wed Jan 13 19:00:08 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13942:d490d84a64ac 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: OK linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: OK 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: OK linux-2.6.32-i686: OK 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: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: OK linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: OK 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: OK linux-2.6.32-x86_64: OK 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/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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
[PATCH 1/1] HID: ignore afatech 9016
Let's ignore the device altogether by HID layer. It's handled by
dvb-usb-remote driver properly already.
By now, FULLSPEED_INTERVAL quirk was used. It probably made things
better, but the remote ctrl 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.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
---
drivers/hid/usbhid/hid-core.c |8
drivers/hid/usbhid/hid-quirks.c |2 +-
include/linux/hid.h |1 -
3 files changed, 1 insertions(+), 10 deletions(-)
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..788d9a3 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -41,7 +41,7 @@ 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_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, HID_QUIRK_IGNORE
},
{ 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_INPUT 0x0040
#define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x0001
-#define HID_QUIRK_FULLSPEED_INTERVAL 0x1000
#define HID_QUIRK_NO_INIT_REPORTS 0x2000
/*
--
1.6.5.7
--
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 1/1] media: dvb-usb/af9015, add IR support for digivox mini II
MSI digivox mini II works even with remote=2 module parameter. Check
for manufacturer and if it is Afatech, use af9015_ir_table_msi and
af9015_rc_keys_msi.
The device itself is 15a4:9016.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Antti Palosaari cr...@iki.fi
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/af9015.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index 8b60a60..f0d5731 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -835,9 +835,15 @@ static int af9015_read_config(struct usb_device *udev)
af9015_ir_table_mygictv;
af9015_config.ir_table_size =
ARRAY_SIZE(af9015_ir_table_mygictv);
- } else if (!strcmp(MSI, manufacturer)) {
- /* iManufacturer 1 MSI
- iProduct 2 MSI K-VOX */
+ } else if (!strcmp(MSI, manufacturer) ||
+ !strcmp(Afatech, manufacturer)) {
+ /*
+ iManufacturer 1 MSI
+ iProduct 2 MSI K-VOX
+ iManufacturer 1 Afatech
+ iProduct 2 DVB-T 2
+*/
+
af9015_properties[i].rc_key_map =
af9015_rc_keys_msi;
af9015_properties[i].rc_key_map_size =
--
1.6.5.7
--
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] HID: ignore afatech 9016
[ Adding Pekka (the author of the patch that added this quirk for AF9016) to
CC ... ]
On Wed, 13 Jan 2010, Jiri Slaby wrote:
Let's ignore the device altogether by HID layer. It's handled by
dvb-usb-remote driver properly already.
By now, FULLSPEED_INTERVAL quirk was used. It probably made things
better, but the remote ctrl 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.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
---
drivers/hid/usbhid/hid-core.c |8
drivers/hid/usbhid/hid-quirks.c |2 +-
include/linux/hid.h |1 -
3 files changed, 1 insertions(+), 10 deletions(-)
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..788d9a3 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -41,7 +41,7 @@ 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_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, HID_QUIRK_IGNORE
},
Hmm, why do we keep HID_QUIRK_IGNORE anyway, when we already have generic
hid_ignore_list[]?
We don't set it for any device in the current codebase any more.
Thanks,x
--
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: [PATCH 1/1] HID: ignore afatech 9016
On 01/13/2010 09:20 PM, Jiri Kosina wrote:
diff --git a/drivers/hid/usbhid/hid-quirks.c
b/drivers/hid/usbhid/hid-quirks.c
index 38773dc..788d9a3 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -41,7 +41,7 @@ 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_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, HID_QUIRK_IGNORE
},
Hmm, why do we keep HID_QUIRK_IGNORE anyway, when we already have generic
hid_ignore_list[]?
You returned it back because of dynamic quirks...
We don't set it for any device in the current codebase any more.
Oh yeah, it's hard for people who don't remember code they wrote :).
Will respin. Thanks for the reminder.
--
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
[PATCH v2 1/1] HID: ignore afatech 9016
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.
Signed-off-by: Jiri Slaby jsl...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Pekka Sarnila sarn...@adit.fi
---
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_INPUT 0x0040
#define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x0001
-#define HID_QUIRK_FULLSPEED_INTERVAL 0x1000
#define HID_QUIRK_NO_INIT_REPORTS 0x2000
/*
--
1.6.5.7
--
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] HID: ignore afatech 9016
On Wed, 13 Jan 2010, Jiri Slaby wrote:
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -41,7 +41,7 @@ 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_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, HID_QUIRK_IGNORE
},
Hmm, why do we keep HID_QUIRK_IGNORE anyway, when we already have generic
hid_ignore_list[]?
You returned it back because of dynamic quirks...
Right you are.
We don't set it for any device in the current codebase any more.
Oh yeah, it's hard for people who don't remember code they wrote :).
Oh, right ... happened to me as well, see a few lines above :)
Will respin. Thanks for the reminder.
Thanks,
--
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: go7007 driver -- which program you use for capture
TJ wrote: jelle, that you? Here's the patch against go7007 driver in 2.6.32 kernel (run with -p1). The main purpose of the patch is to include support for ADS Tech DVD Xpress DX2 usb capture card and make it usable with v4l2-ctl utility. I also did a general clean-up in a few areas and *temporarily* added back in proprietary go7007 ioctls, so current mythtv users can take advantage of it and to make the gorecord program from wis-go7007 package now work again. Also attached is a stripped down version of gorecord from which I removed all parameter-setting stuff. This version is meant to be used in conjunction with v4l2-ctl or other means of configuring capture parameters. I will try to do mythtv patches next so that it starts using standard v4l2 ioctl calls and we can drop all proprietary stuff in the driver. Please try it and lemme know if it works for you. I've run into a few Ubuntuers as well who were trying to get their boards working as well. The patch doesn't apply on the latest -hg version: patching file drivers/staging/go7007/Kconfig patching file drivers/staging/go7007/go7007-driver.c Hunk #2 succeeded at 225 (offset 1 line). Hunk #3 succeeded at 285 (offset 1 line). patching file drivers/staging/go7007/go7007-usb.c patching file drivers/staging/go7007/go7007-v4l2.c Hunk #1 FAILED at 43. Hunk #2 succeeded at 425 with fuzz 2 (offset 8 lines). Hunk #4 succeeded at 578 (offset 8 lines). Hunk #6 FAILED at 993. Hunk #7 succeeded at 1078 with fuzz 1 (offset -8 lines). Hunk #8 FAILED at 1538. Hunk #9 succeeded at 1672 (offset -18 lines). Hunk #10 succeeded at 1764 (offset -8 lines). 3 out of 10 hunks FAILED -- saving rejects to file drivers/staging/go7007/go7007-v4l2.c.rej patching file drivers/staging/go7007/s2250-board.c Hunk #1 FAILED at 357. 1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/go7007/s2250-board.c.rej patching file drivers/staging/go7007/wis-i2c.h patching file drivers/staging/go7007/wis-saa7113.c patching file drivers/staging/go7007/wis-saa7115.c patching file drivers/staging/go7007/wis-tw2804.c patching file drivers/staging/go7007/wis-tw9903.c Hunk #1 FAILED at 152. 1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/go7007/wis-tw9903.c.rej patching file drivers/staging/go7007/wis-tw9906.c Patch doesn't apply Also, you shouldn't re-add the proprietary API but, instead, to port it to use the API support for compressed stuff. 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?
Hi Franklin,
I have no Kworld 315U here for testing, but your patch looked sane on my eyes.
In order to merge this upstream, it would be better if you could submit it as
two
separate patches: the first one with the saa7115 changes to support
re-energizing
the device, and the second one with the em28xx changes.
Please send your Signed-off-by: on the patches.
Cheers,
Mauro.
Franklin Meng wrote:
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},
+};
+
Re: go7007 driver -- which program you use for capture
Pete Eberlein wrote: On Fri, 2010-01-08 at 14:07 -0500, TJ wrote: Pete and anybody else out there with go7007 devices, what do you use for capture? I used a modified capture.c, based on http://v4l2spec.bytesex.org/v4l2spec/capture.c OK good. Without GO7007 ioctls, I was only able to get vlc to capture in MJPEG format. Does VLC try to change video parameters after starting the stream? The driver currently doesn't allow that. I think I've seen xawtv try to do that too. I haven't messed with it much, but I think it just uses default driver settings. When I went to Advanced settings in vlc and tried to change some stuff, it didn't work at all. I ended up just hacking up gorecord from the original driver package and got it working that way. I would probably be worthwhile getting vlc to work with go7007. What do you think? -TJ -- 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?
On Sat, Jan 9, 2010 at 2:30 PM, Franklin Meng fmeng2...@yahoo.com wrote: 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. Hello Franklin, This is pretty good stuff. A few questions/comments about your patch: The code has different GPIO configurations for the two analog modes. This is a bit unusual for an em28xx design. Do you know what the difference is in terms of what GPIO7 controls? The digital GPIO block strobes GPO3 to reset the lgdt3303. While I generally believe that it's good to explicitly strobe the reset low, this could cause problems with em28xx devices. This is because the em28xx calls the digital GPIO whenever starting streaming. Hence, you could end up with the chip being reset without the demod driver's init() routine being called, resulting in the chip's register state not being in sync with the driver's state info. In fact, we have this issue with one of the Terratec boards where the zl10353 driver state gets out of sync with the hardware (I still need to submit a patch upstream for that case). Your code at this point should probably only ensure the 3303 is not in reset (by setting the GPIO pin high). It's not surprising that you would uncover an issue with the suspend logic. Despite the fact that the em28xx driver provides a suspend method it is not actually used today in any of the board profiles. The saa7115 stuff looks pretty reasonable at first glance, although I am a bit worried about the possibility that it could cause a regression in other products that use that decoder. Did you actually do any power analysis to confirm that the suspend functionality is working properly? I agree with Mauro though that this should be split into multiple patches. In fact, I would seriously consider three patches instead of two - the first patch adds the basic functionality to get the board working, the second adds the saa7115 code, and the third adds the suspend GPIO changes. This will make it easier for others who have problems to isolate whether any problems are a basic issue with the board not working or whether it is related to the suspend and power management changes. 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: go7007 driver -- which program you use for capture
Mauro Carvalho Chehab wrote: TJ wrote: jelle, that you? Here's the patch against go7007 driver in 2.6.32 kernel (run with -p1). The main purpose of the patch is to include support for ADS Tech DVD Xpress DX2 usb capture card and make it usable with v4l2-ctl utility. I also did a general clean-up in a few areas and *temporarily* added back in proprietary go7007 ioctls, so current mythtv users can take advantage of it and to make the gorecord program from wis-go7007 package now work again. Also attached is a stripped down version of gorecord from which I removed all parameter-setting stuff. This version is meant to be used in conjunction with v4l2-ctl or other means of configuring capture parameters. I will try to do mythtv patches next so that it starts using standard v4l2 ioctl calls and we can drop all proprietary stuff in the driver. Please try it and lemme know if it works for you. I've run into a few Ubuntuers as well who were trying to get their boards working as well. The patch doesn't apply on the latest -hg version: patching file drivers/staging/go7007/Kconfig patching file drivers/staging/go7007/go7007-driver.c Hunk #2 succeeded at 225 (offset 1 line). Hunk #3 succeeded at 285 (offset 1 line). patching file drivers/staging/go7007/go7007-usb.c patching file drivers/staging/go7007/go7007-v4l2.c Hunk #1 FAILED at 43. Hunk #2 succeeded at 425 with fuzz 2 (offset 8 lines). Hunk #4 succeeded at 578 (offset 8 lines). Hunk #6 FAILED at 993. Hunk #7 succeeded at 1078 with fuzz 1 (offset -8 lines). Hunk #8 FAILED at 1538. Hunk #9 succeeded at 1672 (offset -18 lines). Hunk #10 succeeded at 1764 (offset -8 lines). 3 out of 10 hunks FAILED -- saving rejects to file drivers/staging/go7007/go7007-v4l2.c.rej patching file drivers/staging/go7007/s2250-board.c Hunk #1 FAILED at 357. 1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/go7007/s2250-board.c.rej patching file drivers/staging/go7007/wis-i2c.h patching file drivers/staging/go7007/wis-saa7113.c patching file drivers/staging/go7007/wis-saa7115.c patching file drivers/staging/go7007/wis-tw2804.c patching file drivers/staging/go7007/wis-tw9903.c Hunk #1 FAILED at 152. 1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/go7007/wis-tw9903.c.rej patching file drivers/staging/go7007/wis-tw9906.c Patch doesn't apply Mauro, brother, this patch is for in-kernel go7007 driver. It has to be run against kernel source 2.6.32. (IIRC it will also run against 2.6.31) It won't run against current v4l-dvb tree, as Pete has done quite a few changes since then. When I get a chance, I will start working against current version. Also, you shouldn't re-add the proprietary API but, instead, to port it to use the API support for compressed stuff. I did add support for standard vidioc_s/g_ext_ctrls API stuff and that's what I am actually using currently. I merely kept the proprietary ioctls so that mythtv users can start using the driver as well until somebody (me?) patches mythtv to use the standard APIs. -TJ 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: go7007 driver -- which program you use for capture
TJ wrote: Mauro Carvalho Chehab wrote: TJ wrote: jelle, that you? Here's the patch against go7007 driver in 2.6.32 kernel (run with -p1). The main purpose of the patch is to include support for ADS Tech DVD Xpress DX2 usb capture card and make it usable with v4l2-ctl utility. I also did a general clean-up in a few areas and *temporarily* added back in proprietary go7007 ioctls, so current mythtv users can take advantage of it and to make the gorecord program from wis-go7007 package now work again. Also attached is a stripped down version of gorecord from which I removed all parameter-setting stuff. This version is meant to be used in conjunction with v4l2-ctl or other means of configuring capture parameters. I will try to do mythtv patches next so that it starts using standard v4l2 ioctl calls and we can drop all proprietary stuff in the driver. Please try it and lemme know if it works for you. I've run into a few Ubuntuers as well who were trying to get their boards working as well. The patch doesn't apply on the latest -hg version: patching file drivers/staging/go7007/Kconfig patching file drivers/staging/go7007/go7007-driver.c Hunk #2 succeeded at 225 (offset 1 line). Hunk #3 succeeded at 285 (offset 1 line). patching file drivers/staging/go7007/go7007-usb.c patching file drivers/staging/go7007/go7007-v4l2.c Hunk #1 FAILED at 43. Hunk #2 succeeded at 425 with fuzz 2 (offset 8 lines). Hunk #4 succeeded at 578 (offset 8 lines). Hunk #6 FAILED at 993. Hunk #7 succeeded at 1078 with fuzz 1 (offset -8 lines). Hunk #8 FAILED at 1538. Hunk #9 succeeded at 1672 (offset -18 lines). Hunk #10 succeeded at 1764 (offset -8 lines). 3 out of 10 hunks FAILED -- saving rejects to file drivers/staging/go7007/go7007-v4l2.c.rej patching file drivers/staging/go7007/s2250-board.c Hunk #1 FAILED at 357. 1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/go7007/s2250-board.c.rej patching file drivers/staging/go7007/wis-i2c.h patching file drivers/staging/go7007/wis-saa7113.c patching file drivers/staging/go7007/wis-saa7115.c patching file drivers/staging/go7007/wis-tw2804.c patching file drivers/staging/go7007/wis-tw9903.c Hunk #1 FAILED at 152. 1 out of 1 hunk FAILED -- saving rejects to file drivers/staging/go7007/wis-tw9903.c.rej patching file drivers/staging/go7007/wis-tw9906.c Patch doesn't apply Mauro, brother, this patch is for in-kernel go7007 driver. It has to be run against kernel source 2.6.32. (IIRC it will also run against 2.6.31) It should be against -hg or linux-next tree, otherwise, I can't send it upstream. If you just want to send a patch for people to test, please mark it as RFC, otherwise I'll assume that you're sending a patch for upstream. Since there are more people working on this driver, the better is to add what you have there, to avoid people to do a similar work. It won't run against current v4l-dvb tree, as Pete has done quite a few changes since then. When I get a chance, I will start working against current version. Also, you shouldn't re-add the proprietary API but, instead, to port it to use the API support for compressed stuff. I did add support for standard vidioc_s/g_ext_ctrls API stuff and that's what I am actually using currently. Ah, ok :) I merely kept the proprietary ioctls so that mythtv users can start using the driver as well until somebody (me?) patches mythtv to use the standard APIs. -TJ Ok. While it is still at -staging, we can keep the proprietary ioctls, but they need to be removed before moving to the right place. 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: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix
Hi, Abylai Ospan wrote: redefine to set_tone = lnbp21_set_tone is not correct for NetUP Dual DVB-S2-CI card. Why is it not correct? Please explain. Afaics it does not matter, whether the demod or the LNBH24 controls the 22kHz tone. With your patch, lnbp21_set_tone would never be used... LNBH24 can _continuously_ produce 22kHz tone. This way acceptable if you only want to switch LNB's oscillator to high band. If you want to send diseqc command you need to modulate this 22kHz tone. LNBH24 can't do this but STV0900 demod can. There is no reason why we have to use the set_tone routine of the stv0900. You can combine - set_tone of LNBH24 with - stv090x_send_diseqc_msg of stv0900 without losing anything. Before a DiSEqC message will be sent, the tone will be disabled. Then the stv090x_send_diseqc_msg of the stv0900 can control the 22kHz tone generator of the LNBH24 using EXTM or DSQIN. I have created some demonstration from oscilloscope on NetUP Dual DVB-S2-CI card in attachment ( sorry, russian interface :). Blue is a EXTM pin, yellow is a coaxial connector. As you can see STV0900 sends 11 period's and LNBH24 reproduce it to coaxial output. This is so colled diseqc modulated mode. Scheme of modulated signals you can find in diseqc bus specification - http://www.eutelsat.com/satellites/pdf/Diseqc/Reference% 20docs/bus_spec.pdf on Figure 1: DiSEqC Modulation Scheme. See above. The 22kHz output of the LNBH24 is a logical 'or' of the TEN flag and the control inputs. I don't see any problem here. I think lnbp21_set_tone will be used if set_tone is not defined previously (set_tone == NULL). Is this correct ? No, sorry. set_tone had to be added, because the stv0900 can also operate in DiSEqC envelope mode (connected to DSQIN of the LNBH24). In this mode set_tone of the LNBH24 has to be used. When I modified the lnbp21 module, I considered both cases. I could not (and cannot) see any problem here. Please revert the patch. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] s2250: Fix write_reg i2c address
The kernel i2c model uses right-aligned 7-bit i2c addresses, but the 2250 firmware uses an 8-bit address in the usb vendor request. A previous patch by Jean Delvare shifted the i2c addresses 1 bit to the right, and this patch fixes the write_reg function to shift it back before sending the vendor request. Priority: normal Signed-off-by: Pete Eberlein p...@sensoray.com diff -r 3a4be7d7dabd -r 134a95c0d98b linux/drivers/staging/go7007/s2250-board.c --- a/linux/drivers/staging/go7007/s2250-board.cSun Jan 03 17:04:42 2010 + +++ b/linux/drivers/staging/go7007/s2250-board.cWed Jan 13 14:11:48 2010 -0800 @@ -159,7 +159,7 @@ struct go7007 *go = i2c_get_adapdata(client-adapter); struct go7007_usb *usb; int rc; - int dev_addr = client-addr; + int dev_addr = client-addr 1; /* firmware wants 8-bit address */ u8 *buf; if (go == NULL) -- 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 - v4 1/4] V4L - vpfe_capture-remove clock and platform code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform patches
2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++-
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
- BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
- ret = -1;
+ ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
- dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
- int ret = -ENOENT;
-
- vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
- if (NULL == vpfe_cfg-vpssclk) {
- v4l2_err(vpfe_dev-pdev-driver, No clock defined for
-vpss_master\n);
- return ret;
- }
-
- if (clk_enable(vpfe_cfg-vpssclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss master clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master clock enabled\n);
-
- vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
- if (NULL == vpfe_cfg-slaveclk) {
- v4l2_err(vpfe_dev-pdev-driver,
- No clock defined for vpss slave\n);
- goto out;
- }
-
- if (clk_enable(vpfe_cfg-slaveclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss slave clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver, vpfe vpss slave clock enabled\n);
- return 0;
-out:
- if (vpfe_cfg-vpssclk)
- clk_put(vpfe_cfg-vpssclk);
- if (vpfe_cfg-slaveclk)
- clk_put(vpfe_cfg-slaveclk);
-
- return -1;
-}
-
/*
* vpfe_probe : This function creates device entries by register
* itself to the V4L2 driver and initializes fields of each
@@ -1870,7 +1809,7 @@ static __init int vpfe_probe(struct platform_device *pdev)
if (NULL == pdev-dev.platform_data) {
v4l2_err(pdev-dev.driver, Unable to get vpfe config\n);
- ret = -ENOENT;
+ ret = -ENODEV;
goto probe_free_dev_mem;
}
@@ -1884,18 +1823,13 @@ static __init int
[PATCH - v4 2/4] V4L - vpfe-capture - converting dm355 ccdc driver to a platform driver
From: Muralidharan Karicheri m-kariche...@ti.com
Following are the changes done in this patch:-
1) clocks are configured using generic clock names
2) converting the driver to a platform driver
3) cleanup - consolidate all static variables inside a structure,
ccdc_cfg
The ccdc now uses a generic name for clocks. master and slave. On
individual platforms
these clocks will inherit from the platform specific clock. This will allow
re-use of
the driver for the same IP across different SoCs.
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
Updated based on Kevin's comments on clock configuration and error code (v3,
v4).
drivers/media/video/davinci/dm355_ccdc.c | 410 +++---
1 files changed, 257 insertions(+), 153 deletions(-)
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index 3143900..c29ac88 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -37,8 +37,12 @@
#include linux/platform_device.h
#include linux/uaccess.h
#include linux/videodev2.h
+#include linux/clk.h
+#include linux/err.h
+
#include media/davinci/dm355_ccdc.h
#include media/davinci/vpss.h
+
#include dm355_ccdc_regs.h
#include ccdc_hw_device.h
@@ -46,67 +50,75 @@ MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(CCDC Driver for DM355);
MODULE_AUTHOR(Texas Instruments);
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
- .pix_fmt = CCDC_PIXFMT_RAW,
- .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
- .win = CCDC_WIN_VGA,
- .fid_pol = VPFE_PINPOL_POSITIVE,
- .vd_pol = VPFE_PINPOL_POSITIVE,
- .hd_pol = VPFE_PINPOL_POSITIVE,
- .gain = {
- .r_ye = 256,
- .gb_g = 256,
- .gr_cy = 256,
- .b_mg = 256
- },
- .config_params = {
- .datasft = 2,
- .data_sz = CCDC_DATA_10BITS,
- .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
- .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
- .alaw = {
- .gama_wd = 2,
+static struct ccdc_oper_config {
+ struct device *dev;
+ /* CCDC interface type */
+ enum vpfe_hw_if_type if_type;
+ /* Raw Bayer configuration */
+ struct ccdc_params_raw bayer;
+ /* YCbCr configuration */
+ struct ccdc_params_ycbcr ycbcr;
+ /* Master clock */
+ struct clk *mclk;
+ /* slave clock */
+ struct clk *sclk;
+ /* ccdc base address */
+ void __iomem *base_addr;
+} ccdc_cfg = {
+ /* Raw configurations */
+ .bayer = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .gain = {
+ .r_ye = 256,
+ .gb_g = 256,
+ .gr_cy = 256,
+ .b_mg = 256
},
- .blk_clamp = {
- .sample_pixel = 1,
- .dc_sub = 25
- },
- .col_pat_field0 = {
- .olop = CCDC_GREEN_BLUE,
- .olep = CCDC_BLUE,
- .elop = CCDC_RED,
- .elep = CCDC_GREEN_RED
- },
- .col_pat_field1 = {
- .olop = CCDC_GREEN_BLUE,
- .olep = CCDC_BLUE,
- .elop = CCDC_RED,
- .elep = CCDC_GREEN_RED
+ .config_params = {
+ .datasft = 2,
+ .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+ .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+ .alaw = {
+ .gama_wd = 2,
+ },
+ .blk_clamp = {
+ .sample_pixel = 1,
+ .dc_sub = 25
+ },
+ .col_pat_field0 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
+ .col_pat_field1 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+
[PATCH - v4 3/4] V4L - vpfe-capture - converting dm644x ccdc driver to a platform driver
From: Muralidharan Karicheri m-kariche...@ti.com
Following are the changes done:-
1) clocks are configured using generic clock names
2) converting the driver to a platform driver
3) cleanup - consolidate all static variables inside a structure,
ccdc_cfg
The ccdc driver now uses generic names for clocks - master and slave. On
individual platforms
these clocks will inherit from the platform specific clock. This will allow
re-use of
the driver for the same IP across different SoCs.
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
rebased to linux-next tree of v4l-dvb (v4)
Updated based on Kevin's comments on clock configuration and error handling
(v3, v4).
drivers/media/video/davinci/dm644x_ccdc.c | 361 ++---
1 files changed, 225 insertions(+), 136 deletions(-)
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
index d5fa193..0c394ca 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -37,8 +37,12 @@
#include linux/platform_device.h
#include linux/uaccess.h
#include linux/videodev2.h
+#include linux/clk.h
+#include linux/err.h
+
#include media/davinci/dm644x_ccdc.h
#include media/davinci/vpss.h
+
#include dm644x_ccdc_regs.h
#include ccdc_hw_device.h
@@ -46,32 +50,44 @@ MODULE_LICENSE(GPL);
MODULE_DESCRIPTION(CCDC Driver for DM6446);
MODULE_AUTHOR(Texas Instruments);
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
- .pix_fmt = CCDC_PIXFMT_RAW,
- .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
- .win = CCDC_WIN_VGA,
- .fid_pol = VPFE_PINPOL_POSITIVE,
- .vd_pol = VPFE_PINPOL_POSITIVE,
- .hd_pol = VPFE_PINPOL_POSITIVE,
- .config_params = {
- .data_sz = CCDC_DATA_10BITS,
+static struct ccdc_oper_config {
+ struct device *dev;
+ /* CCDC interface type */
+ enum vpfe_hw_if_type if_type;
+ /* Raw Bayer configuration */
+ struct ccdc_params_raw bayer;
+ /* YCbCr configuration */
+ struct ccdc_params_ycbcr ycbcr;
+ /* Master clock */
+ struct clk *mclk;
+ /* slave clock */
+ struct clk *sclk;
+ /* ccdc base address */
+ void __iomem *base_addr;
+} ccdc_cfg = {
+ /* Raw configurations */
+ .bayer = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .config_params = {
+ .data_sz = CCDC_DATA_10BITS,
+ },
+ },
+ .ycbcr = {
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+ .win = CCDC_WIN_PAL,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .bt656_enable = 1,
+ .pix_order = CCDC_PIXORDER_CBYCRY,
+ .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
},
-};
-
-/* Object for CCDC ycbcr mode */
-static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
- .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
- .frm_fmt = CCDC_FRMFMT_INTERLACED,
- .win = CCDC_WIN_PAL,
- .fid_pol = VPFE_PINPOL_POSITIVE,
- .vd_pol = VPFE_PINPOL_POSITIVE,
- .hd_pol = VPFE_PINPOL_POSITIVE,
- .bt656_enable = 1,
- .pix_order = CCDC_PIXORDER_CBYCRY,
- .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
};
#define CCDC_MAX_RAW_YUV_FORMATS 2
@@ -84,25 +100,15 @@ static u32 ccdc_raw_bayer_pix_formats[] =
static u32 ccdc_raw_yuv_pix_formats[] =
{V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
-static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
-static enum vpfe_hw_if_type ccdc_if_type;
-
/* register access routines */
static inline u32 regr(u32 offset)
{
- return __raw_readl(ccdc_base_addr + offset);
+ return __raw_readl(ccdc_cfg.base_addr + offset);
}
static inline void regw(u32 val, u32 offset)
{
- __raw_writel(val, ccdc_base_addr + offset);
-}
-
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
- ccdc_base_addr = addr;
- ccdc_addr_size = size;
+ __raw_writel(val, ccdc_cfg.base_addr + offset);
}
static void ccdc_enable(int flag)
@@ -132,7 +138,7 @@ void ccdc_setwin(struct v4l2_rect *image_win,
int vert_start, vert_nr_lines;
int val = 0, mid_img = 0;
- dev_dbg(dev, \nStarting ccdc_setwin...);
+ dev_dbg(ccdc_cfg.dev, \nStarting ccdc_setwin...);
/*
[PATCH 11/11] dabusb: declare MODULE_FIRMWARE
Signed-off-by: Ben Hutchings b...@decadent.org.uk --- Mauro, You nacked my previous patches for media because they would result in many false dependencies. However, I think this driver at least will always depend on the same files. Ben. drivers/media/video/dabusb.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/dabusb.c b/drivers/media/video/dabusb.c index ee43876..9b413a3 100644 --- a/drivers/media/video/dabusb.c +++ b/drivers/media/video/dabusb.c @@ -913,6 +913,8 @@ static void __exit dabusb_cleanup (void) MODULE_AUTHOR( DRIVER_AUTHOR ); MODULE_DESCRIPTION( DRIVER_DESC ); MODULE_LICENSE(GPL); +MODULE_FIRMWARE(dabusb/firmware.fw); +MODULE_FIRMWARE(dabusb/bitstream.bin); module_param(buffers, int, 0); MODULE_PARM_DESC (buffers, Number of buffers (default=256)); -- 1.6.5.7 -- 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: cx23885 oops during loading, WinTV-HVR-1850 card -- SOLVED
On Fri, Jan 08, 2010 at 09:06:01PM -0500, Devin Heitmueller wrote: The cx23885 driver doesn't work with tvtime, due to bugs in the v4l controls in the driver. Michael Krufky has some patches but they need some more work before they can go in the mainline. Even if they were committed though, there is currently no support for raw audio, so tvtime would not be a good application to use for this device. Thanks for the tip. I've tried all the other clients I could get my hands on, including xawtv, mplayer, and xine. Unfortunately, I have not managed to get a picture (or even an empty window) out of them. Is there a way to get it working? Mplayer plays local media files and DVDs happily, but when I try to input from /dev/video, or use the tv:// args, it complains: v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 over and over again. The other clients just hang or exit. I'm not sure what to try next. Here is a typical log, I have tried many variations, but the end result is always the same. $ mplayer tv://4 -tv norm=NTSC-M:chanlist=us-bcast MPlayer SVN-r29800-4.4.2 (C) 2000-2009 MPlayer Team [...] Playing tv://4. STREAM: [tv] tv://4 STREAM: Description: TV Input STREAM: Author: Benjamin Zores, Albeu STREAM: Comment: TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski olschew...@zpr.uni-koeln.de comment: first try, more to come ;-) Selected device: Hauppauge WinTV-HVR1850 Tuner cap: STEREO LANG1 LANG2 Tuner rxs: MONO LANG2 Capabilites: video capture tuner read/write streaming supported norms: 0 = NTSC-M; 1 = NTSC-M-JP; 2 = NTSC-443; 3 = PAL-BG; 4 = PAL-I; 5 = PAL-DK; 6 = PAL-M; 7 = PAL-N; 8 = PAL-Nc; 9 = PAL-60; 10 = SECAM-DK; 11 = SECAM-L; inputs: Current input: 0 Format unknown (0x4745504d) ( 0 bits, MPEG): Unknown 0x4745504d Current format: unknown (0x4745504d) v4l2: current audio mode is : LANG1 v4l2: set format: YVU420 v4l2: set input: 0 v4l2: ioctl enum input failed: Invalid argument Selected norm : NTSC-M v4l2: set norm: NTSC-M Selected channel list: us-bcast (including 82 channels) Requested channel: 4 Selected channel: 4 (freq: 67.250) Current frequency: 1076 (67.250) Current frequency: 1076 (67.250) == Found video stream: 0 v4l2: get format: unknown (0x4745504d) v4l2: get fps: 29.970030 v4l2: get width: 720 v4l2: get height: 480 Using a ring buffer for maximum 2 frames, 0 MB total size. v4l2: ioctl query control failed: Invalid argument v4l2: ioctl query control failed: Invalid argument v4l2: ioctl query control failed: Invalid argument v4l2: ioctl query control failed: Invalid argument [V] filefmt:9 fourcc:0x4745504D size:720x480 fps:29.970 ftime:=0.0334 [vdpau] Could not open dynamic library libvdpau.so.1 X11 opening display: :0.0 vo: X11 color mask: FF (R:FF G:FF00 B:FF) vo: X11 running at 848x480 with depth 24 and 32 bpp (:0.0 = local display) [x11] Detected wm supports NetWM. [x11] Detected wm supports FULLSCREEN state. [x11] Detected wm supports ABOVE state. [x11] Detected wm supports BELOW state. [x11] Current fstype setting honours FULLSCREEN ABOVE BELOW X atoms [VO_XV] Using Xv Adapter #0 (Intel(R) Textured Video) [xv common] Drawing no colorkey. [xv common] Maximum source image dimensions: 2048x2048 == Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough VDec: vo config request - 720 x 480 (preferred colorspace: Mpeg PES) Trying filter chain: vo Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] SwScale params: -1 x -1 (-1=no scaling) Trying filter chain: scale vo The selected video_out device is incompatible with this codec. Try appending the scale filter to your filter list, e.g. -vf spp,scale instead of -vf spp. VDecoder init failed :( Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Unsupported PixelFormat -1 INFO: libavcodec init OK! Selected video codec: [ffmpeg1] vfm: ffmpeg (FFmpeg MPEG-1) == Audio: no sound Freeing 0 unused audio chunks. Starting playback... v4l2: going to capture v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed: Input/output error, idx = 0 v4l2: ioctl dequeue buffer failed:
About driver architecture
Hi guys, I'm going to write drivers for a new soc which designed for dvb-s set top box. It will support these features: 1. Multi-layer display with alpha blending feature, including video(YUV), OSDs(2 same RGB layers), background(with fixed YUV color) and still picture(YUV color for still image) 2. DVB-S tuner and demod 3. HW MPEG2/4 decoder 4. HW accelerated JPEG decoder engine. My targets are: 1. Fit all the drivers in proper framework so they can be easily used by applications in open source community. 2. As flexible as I can to add new software features in the future. My questions are: How many drivers should I implement, and how should I divide all the features? As far as I know: A) a frame buffer driver for 2 OSDs, maybe also the control point for whole display module? B) video output device for video layer, which will output video program. C) drivers for tuner and demo (or just a driver which will export 2 devices files for each?) D) driver for jpeg accelerate interface, or should it be a part of MPEG2/4 decoder driver? E) driver for MPEG2/4 decoder which will control the behave of H/W decoder. Actually I think all the display functions are relative, some functions i listed upper are operating one HW module, for instance: OSD and video layer are implemented by display module in H/W level. What's the right way to implement these functions in driver level, united or separated? And, I've read some documents for V4L2, but I still cannot figure out where should I implement my driver in the framework. In a word, I'm totally confused. Can you guys show me the right way or just kick me to a existing example with similar features? Best regards Michael Qiu -- 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
