Re: Conversion of vino driver for SGI to not use the legacy decoder API
On Friday 27 February 2009 01:47:42 Mauro Carvalho Chehab wrote: > After the conversion of Zoran driver to V4L2, now almost all drivers are > using the new API. However, there are is one remaining driver using the > video_decoder.h API (based on V4L1 API) for message exchange between the > bridge driver and the i2c sensor: the vino driver. > > This driver adds support for the Indy webcam and for a capture hardware > on SGI. Does someone have those hardware? If so, are you interested on > helping to convert those drivers to fully use V4L2 API? > > The SGI driver is located at: > drivers/media/video/vino.c > > Due to vino, those two drivers are also using the old API: > drivers/media/video/indycam.c > drivers/media/video/saa7191.c > > It shouldn't be hard to convert those files to use the proper APIs, but > AFAIK none of the current active developers has any hardware for testing > it. The conversion has already been done in my v4l-dvb-vino tree. I'm trying to convince the original vino author to boot up his Indy and test it, but he is not very interested in doing that. I'll ask him a few more times, but we may have to just merge my code untested. Or perhaps just drop it. Jean, I remember you mentioning that you wouldn't mind if the i2c-algo-sgi code could be dropped which is only used by vino. How important is that to you? Perhaps we are flogging a dead horse here and we should just let this driver die. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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/~mkrufky/sms1xxx
Mauro, Changeset 85a2b117175e creates the following build warning: WARNING: "sms_dbg" [/home/mk/v4l-dvb/v4l/smsusb.ko] undefined! WARNING: "sms_dbg" [/home/mk/v4l-dvb/v4l/smsdvb.ko] undefined! Please pull the fix from: http://linuxtv.org/hg/~mkrufky/sms1xxx for the following: - Backed out changeset 85a2b117175e - siano: prevent duplicate variable declaration sms-cards.c |4 smscoreapi.c |2 +- smscoreapi.h |2 -- smsdvb.c |6 +- smsusb.c |6 +- 5 files changed, 15 insertions(+), 5 deletions(-) Thanks, 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.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran
On Friday 27 February 2009 01:33:09 Mauro Carvalho Chehab wrote: > On Sun, 22 Feb 2009 18:58:29 +0100 > > Hans Verkuil wrote: > > It took me several long weekends to get all this work done, but I think > > it's been very worthwhile. > > Very great job! > > Yet, I had to add some patches to manually fix a few merge conflicts > after your series. I'll try to fold those patches at the proper places to > avoid breaking bisect upstream. > > A side note: we should now remove the video_decoder.h headers. There are > only 3 drivers left using it. I'll add an RFC asking for people to help > with the remaining ones, or otherwise strip them from kernel. I have a v4l-dvb-vino tree pending that converts the last video_decoder.h users. I'm waiting for test results, but the guy I've asked to do the testing (the original vino author) has very little time (and I suspect interest), so if I do not get feedback in time then I'll just make a pull request for that tree and get it in untested. I also noted that it was still included in mxb.c: it can certainly be removed there. Note that now that the zoran tree is merged, the video_encoder.h header has become obsolete. It's not in our tree, so you will have to manually remove it from the upstream kernel. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
TwinHan PCI-Sat Card Problem
Hallo, my configuration is * Fujitsu Siemens HTPC * MythDora 5.0(FC 8) * TwinHan PCI-Sat * Technisat Multytenne(4 Satelite positions 13.0 19.2,23.5, 28) dual This mulitytenne is once connected to a technisat receiver and once to the HTPC. I can watch on the receiver, but I did not success with my htpc so far. The card is recognized in mythtv-setup, but it cant determine its parameters, so I tried to use it manually, first. I got installed 2 tv cards in my HTPC, I am concentrating on the Twinhan Vision Plus DVB In my /etc/modprobe.conf there is not yet anything mentioned about my dvb card ls /dev/dvb/adapter0/ shows ca0 demux0 dvr0 frontend0 net0 I successfully generated a channels.conf with valid and real channels. When I run [myt...@localhost szap]$ ./szap -a 0 -r N24 reading channels from file '/home/mythtv/.szap/channels.conf' zapping to 17 'N24': sat 0, frequency = 12640 MHz V, symbolrate 2200, vpid = 0x03ff, apid = 0x0400 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' FE_SET_VOLTAGE failed: Input/output error status 1f | signal fffe | snr fffe | ber fffe | unc fffe | FE_HAS_LOCK status 1f | signal fffe | snr 22ef | ber fffe | unc fffe | FE_HAS_LOCK status 1f | signal 3d00 | snr 22f3 | ber fffe | unc fffe | FE_HAS_LOCK ... The error message about FE_SET_VOLTAGE does sometimes appear if i try then/during mplayer /dev/dvb/adapter0/dvr0 I get nothing, dvr does not output any byte Relevant modules loaded are saa7134_alsa 14689 1 tda1004x 17477 1 saa7134_dvb1 0 videobuf_dvb8517 1 saa7134_dvb dst_ca 14913 1 tuner_simple 15953 2 tuner_types17857 1 tuner_simple tda988713509 1 tda829015685 0 dst27593 2 dst_ca dvb_bt8xx 17605 0 dvb_core 68673 5 saa7134_dvb,videobuf_dvb,dst_ca,dst,dvb_bt8xx saa7134 128789 2 saa7134_alsa,saa7134_dvb bt878 12793 2 dst,dvb_bt8xx tuner 26249 0 bttv 152661 2 dvb_bt8xx,bt878 videodev 31425 3 saa7134,tuner,bttv The important passages of dmesg look like bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt :01:0b.0[A] -> GSI 16 (level, low) -> IRQ 16 bttv0: Bt878 (rev 17) at :01:0b.0, irq: 16, latency: 32, mmio: 0xfdcff000 bttv0: detected: Twinhan VisionPlus DVB [card=113], PCI subsystem ID is 1822:0001 bttv0: using: Twinhan DST + clones [card=113,autodetected] bttv0: gpio: en=, out= in=00f5fffd [init] input: i2c IR (Hauppauge) as /class/input/input8 ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-1/1-001a/ir0 [bt878 #0 [hw]] bttv0: tuner absent bttv0: add subdevice "dvb0" bt878: AUDIO driver version 0.0.0 loaded bt878: Bt878 AUDIO function found (0). ACPI: PCI Interrupt :01:0b.1[A] -> GSI 16 (level, low) -> IRQ 16 bt878_probe: card id=[0x11822],[ Twinhan VisionPlus DVB ] has DVB functions. bt878(0): Bt878 (rev 17) at 01:0b.1, irq: 16, latency: 32, memory: 0xfdcfe000 saa7130/34: v4l2 driver version 0.2.14 loaded ACPI: PCI Interrupt :01:04.0[A] -> GSI 19 (level, low) -> IRQ 19 saa7134[0]: found at :01:04.0, rev: 1, irq: 19, latency: 32, mmio: 0xfddff000 saa7134[0]: subsystem: 021a:0001, board: Medion 7134 [card=12,insmod option] saa7134[0]: board init: gpio is 0 DVB: registering new adapter (bttv0) tuner' 2-0043: chip found @ 0x86 (saa7134[0]) tda9887 2-0043: creating new instance tda9887 2-0043: tda988[5/6/7] found tuner' 2-0061: chip found @ 0xc2 (saa7134[0]) saa7134[0]: i2c eeprom 00: a0 12 02 00 54 20 08 00 43 43 28 0c 00 52 20 12 saa7134[0]: i2c eeprom 10: 00 87 82 0f ff 20 2a 00 00 50 12 00 00 18 0a 10 saa7134[0]: i2c eeprom 20: 01 00 00 02 02 03 01 00 06 ad 00 10 02 51 00 08 saa7134[0]: i2c eeprom 30: 01 18 48 07 03 00 00 0c d2 00 00 10 00 00 12 3c saa7134[0]: i2c eeprom 40: 60 00 00 c0 82 10 00 00 00 00 01 58 40 1b 02 8d saa7134[0]: i2c eeprom 50: 7d 56 65 3f 00 5b 06 02 00 00 04 00 0c 00 04 00 saa7134[0]: i2c eeprom 60: 2b a6 7d 38 2b d4 d3 5b 3a 51 e5 5e c6 87 f2 ff saa7134[0]: i2c eeprom 70: ff a6 2a 58 3a 5b 13 86 b2 58 1a d4 d3 58 5a 5d saa7134[0]: i2c eeprom 80: 02 22 50 1f 21 8f 80 87 bf 5b fb 5b 3f ad 28 50 saa7134[0]: i2c eeprom 90: 16 7d 28 1c 41 18 48 87 f3 00 01 8d f3 00 01 50 saa7134[0]: i2c eeprom a0: 22 58 12 7f 60 00 91 5e 18 ff ff a6 7d da d8 79 saa7134[0]: i2c eeprom b0: 29 52 96 d4 d3 5b 3a ad 2b 41 84 22 a6 58 66 00 saa7134[0]: i2c eeprom c0: 93 26 29 a6 2a 58 3a 5b 13 a6 29 58 1a 61 2b d4 saa7134[0]: i2c eeprom d0: d3 49 82 8f ba 49 82 8f f2 00 01 5d 12 22 7e 1f saa7134[0]: i2c eeprom e0: 21 8f 80 87 bf 5b fb 5b 3f ad 28 50 16 7d 28 1c saa7134[0]: i2c eeprom f0: 41 18 48 87 f3 00 01 8d f3 00 01 50 22 60 29 7f saa7134[0] Cant determine tuner type 1000 from EEPROM saa7134[0] Tuner type is 63 tuner
Re: [PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits
On Fri, 27 Feb 2009, Igor M. Liplianin wrote: > 01/02: dm1105: not demuxing from interrupt context. > http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=6faf0753950b I'm not sure if you considered this, but the default work queue is multi-threaded with a kernel thread for each CPU. This means that if the IRQ handler calls schedule_work() while your work function is running then you can get a second copy running of your work function running at the same time. It doesn't look like your work function uses atomit_t or locking, so I'm guessing it's not safe to run concurrently. For the pluto2 patch, I created a single threaded work queue. This avoids the concurrency problem and it's not like the demuxer can run in parallel anyway. Having your own work queue also means that you don't have to worry about latency from whatever other tasks might be in the default work queue. Also consider that the work function is queued mutliple times before it runs, it will only run once. I.e. queuing a work func that's already in the queue does nothing (one the function starts to run, it's no longer in the queue and can be added again before it's finished). The pluto2 patch I posted didn't take this into account, but I've since fixed 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: [linux-dvb] TechnoTrend C-1501 - Locking issues on 388Mhz
Hi,
Am Mittwoch, den 25.02.2009, 20:42 + schrieb erik:
> klaas de waal gmail.com> writes:
> >
> > On Fri, Oct 10, 2008 at 2:36 AM, hermann pitton
> > arcor.de>
> wrote:
> > Hi,
> > Am Donnerstag, den 09.10.2008, 22:15 +0200 schrieb klaas de waal:
> > The table starts a new segment at 390MHz,
> > > it then starts to use VCO2 instead of VCO1.
> > > I have now (hack, hack) changed the segment start from 390 to 395MHz
> > > so that the 388MHz is still tuned with VCO1, and this works OK!!
> > > Like this:
> > >
> > > static const struct tda827xa_data tda827xa_dvbt[] = {
> > > { .lomax = 56875000, .svco = 3, .spd = 4, .scr = 0, .sbs =
> > > 0, .gc3 = 1},
> > > #else
> > > { .lomax = 39500, .svco = 2, .spd = 1, .scr = 0, .sbs =
> > > 3, .gc3 = 1},
> > > #endif
> > > { .lomax = 45500, .svco = 3, .spd = 1, .scr = 0, .sbs =
> > > 3, .gc3 = 1},
> > > etc etc
> > >
>
> Hi Klaas/Hermann
>
> Your fix works perfectly for me as well. Prior I could not get the channels in
> the 38675 freq. With Fix appied my Ziggo locking issues disappeared.
>
> Is there any chance to get it into the official version?
>
> Erik
>
yes, there should be one for the later patch with the separate tuning
table for tda8274a DVB-C I think.
Patch for a review must be against recent mercurial v4l-dvb, needs to be
in form of a unified diff, with mercurial installed and v4l-dvb cloned
"hg diff > tda827x_dvb-c_improved-tuning-table.patch" something does
create it most simple.
Needs to go to linux-media@vger.kernel.org , please try README.patches
in the v4l-dvb Documentation. Needs a Signed-off-by line.
Also testers like you should provide a Tested-by line to promote it.
Don't know if somebody has the tuning table for that specific tuner,
tda8274a IIRC, or if this will only rely on the reports of the testers.
Some equivalent of lna config = 0 needs to be introduced too to keep it
quiet was said as well.
Cheers,
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
[GIT PATCHES for 2.6.29] V4L/DVB updates
Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git for_linus For a few fixes: - em28xx: register device to soundcard for sysfs; - soc-camera: fix S_CROP breakage on PXA and SuperH; - b2c2: fix software IRQ watchdog and update documentation to reflect the current usage of Technisat. Cheers, Mauro. --- Documentation/dvb/README.flexcop | 205 Documentation/dvb/technisat.txt| 34 +++-- drivers/media/dvb/b2c2/flexcop-hw-filter.c |1 + drivers/media/dvb/b2c2/flexcop-pci.c | 65 ++--- drivers/media/dvb/b2c2/flexcop.c |3 +- drivers/media/video/em28xx/em28xx-audio.c |2 + drivers/media/video/pxa_camera.c | 26 ++-- drivers/media/video/sh_mobile_ceu_camera.c | 13 +- 8 files changed, 84 insertions(+), 265 deletions(-) delete mode 100644 Documentation/dvb/README.flexcop Guennadi Liakhovetski (1): V4L/DVB (10663): soc-camera: fix S_CROP breakage on PXA and SuperH Nicola Soranzo (1): V4L/DVB (10659): em28xx: register device to soundcard for sysfs Patrick Boettcher (1): V4L/DVB (10694): [PATCH] software IRQ watchdog for Flexcop B2C2 DVB PCI cards Uwe Bugla (2): V4L/DVB (10695): Update Technisat card documentation V4L/DVB (10696): Remove outdated README for the flexcop-driver --- V4L/DVB development is hosted at http://linuxtv.org -- 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://linuxtv.org/hg/~awalls/cx18
On Sat, 21 Feb 2009 21:22:22 -0500 Andy Walls wrote: > Mauro, > > Please pull from: > > http://linuxtv.org/hug/~awalls/cx18 > > for the following: > > cx18: Disable AC3 controls as the firmware doesn't support AC3 > cx18: Increment version number due to significant changes for v4l2_subdevs > cx18: Get rid of unused variables related to video output > cx18: Change log lines for internal subdevs and fix tveeprom reads + strncpy(c.name, "cx18 tveeprom tmp", sizeof(c.name)); + c.name[sizeof(c.name)-1] = '\0'; Please use strlcpy() instead. > cx18: Fix a memory leak of buffers used for sliced VBI insertion > cx18: Convert GPIO connected functions to act as v4l2_subdevices > cx18: Convert I2C devices to v4l2_subdevices > cx18, v4l2-chip-ident: Finish conversion of AV decoder core to v4l2_subdev > cx18: Slim down instance handling, build names from v4l2_device.name > cx18: Convert the integrated A/V decoder core interface to a v4l2_subdev > > This is the conversion of cx18 to the new v4l_device/v4l2_subdev > framework, along with a few minor changes. (Note, I added a new value > in v4l2-chip-ident, outside of the cx18 directory.) > > This set of changes will conflict with Hans' recent pull request that > affects cx18-av-core.c. If your merge tools can't detect that the code > Hans intends to patch simply differs in position by about 20 lines, then > Hans' changes to cx18-av-core.c still should be easy enough to merge by > hand. There were some merge conflicts. I've fixed it by hand, but I suspect that you'll need to properly tune the default values for v4l2_ctrl_query_fill(). Please review my last patch and fix it accordingly with the limits of each V4L2_CID. 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://linuxtv.org/hg/~awalls/cx18
Andy and Hans, On Sat, 21 Feb 2009 21:22:22 -0500 Andy Walls wrote: > This set of changes will conflict with Hans' recent pull request that > affects cx18-av-core.c. If your merge tools can't detect that the code > Hans intends to patch simply differs in position by about 20 lines, then > Hans' changes to cx18-av-core.c still should be easy enough to merge by > hand. There were several merge conflicts and bisect breakages that happened during the merge of your trees. Most of the troubles were due the removal of a control function helper from core. It took me a large amount of time to fix those conflicts and to be sure that bisect were not broken during the -git export. Since I had to do some magic during this merge, it would be really interesting if you could double check if everything is ok. I've already backported the -git changes into -hg. If you find any issues, please send me a patch fixing they. 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://mercurial.intuxication.org/hg/v4l-dvb-commits
On Fri, 27 Feb 2009 03:38:15 +0200 "Igor M. Liplianin" wrote: > Mauro, > I know, it is bad practice to send twice, but previous request for misterious > reason not appeared > in mailing list after 18 hrs. No problem, but I've merged your tree already (today evening). Please check and ping me if I forgot something. 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: POLL: for/against dropping support for kernels < 2.6.22
On Sun, Feb 22, 2009 at 7:15 PM, Hans Verkuil wrote: > Should we drop support for kernels <2.6.22 in our v4l-dvb repository? > > _: Yes > _: No Yes. > Optional question: > > Why: Focus on moving forward instead of looking backwards. Keeping user space compatibilty is of course a good idea, but I see no reason why V4L needs to be special compared to the rest of the kernel. I don't have the full picture though and I'm not the one who spend energy and time on keeping backwards compatibility. If the cost is small enough then it may of course be worth it. But my gut feeling is that there is no point in being special with these things, just do like the rest of the kernel subsystems and you will be fine. / magnus -- 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://mercurial.intuxication.org/hg/v4l-dvb-commits
Mauro, I know, it is bad practice to send twice, but previous request for misterious reason not appeared in mailing list after 18 hrs. Please pull from http://mercurial.intuxication.org/hg/v4l-dvb-commits for the following 2 changesets: 01/02: dm1105: not demuxing from interrupt context. http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=6faf0753950b 02/02: dm1105: infrared remote code is remaked. http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=74fba5b3b3ae drivers/media/common/ir-keymaps.c | 38 ++ drivers/media/dvb/dm1105/dm1105.c | 239 -- include/media/ir-common.h |1 3 files changed, 145 insertions(+), 133 deletions(-) Thanks, Igor -- 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
Conversion of vino driver for SGI to not use the legacy decoder API
After the conversion of Zoran driver to V4L2, now almost all drivers are using the new API. However, there are is one remaining driver using the video_decoder.h API (based on V4L1 API) for message exchange between the bridge driver and the i2c sensor: the vino driver. This driver adds support for the Indy webcam and for a capture hardware on SGI. Does someone have those hardware? If so, are you interested on helping to convert those drivers to fully use V4L2 API? The SGI driver is located at: drivers/media/video/vino.c Due to vino, those two drivers are also using the old API: drivers/media/video/indycam.c drivers/media/video/saa7191.c It shouldn't be hard to convert those files to use the proper APIs, but AFAIK none of the current active developers has any hardware for testing it. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-zoran
On Sun, 22 Feb 2009 18:58:29 +0100 Hans Verkuil wrote: > It took me several long weekends to get all this work done, but I think it's > been very worthwhile. Very great job! Yet, I had to add some patches to manually fix a few merge conflicts after your series. I'll try to fold those patches at the proper places to avoid breaking bisect upstream. A side note: we should now remove the video_decoder.h headers. There are only 3 drivers left using it. I'll add an RFC asking for people to help with the remaining ones, or otherwise strip them from kernel. 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://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision
On Thursday 26 February 2009 20:28:06 Mauro Carvalho Chehab wrote: > On Sat, 21 Feb 2009 22:17:10 +0100 > > Hans Verkuil wrote: > > Hi Mauro, > > > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision > > for the following: > > > > - v4l2-common: add v4l2_i2c_subdev_addr() > > - usbvision: convert to v4l2_device/v4l2_subdev. > > Thierry/Dwaine, > > Could you please check if everything is ok with usbvision after those > patches? Just for the record, I did test it on my pinnacle. Sorry, I should have mentioned it. But it's of course always good to have more testing done. Regards, Hans > > > Thanks, > > > > Hans > > > > diffstat: > > drivers/media/video/usbvision/usbvision-core.c |2 > > drivers/media/video/usbvision/usbvision-i2c.c | 147 > > ++-- > > drivers/media/video/usbvision/usbvision-video.c | 63 -- > > drivers/media/video/usbvision/usbvision.h |8 - > > drivers/media/video/v4l2-common.c |9 + > > include/media/v4l2-common.h |2 > > 6 files changed, 86 insertions(+), 145 deletions(-) > > 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 -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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://linuxtv.org/hg/~mkrufky/sms1xxx
On Thu, Feb 26, 2009 at 3:19 PM, Uri Shkolnik wrote:
>
>
>
> -Original Message-
> From: mkru...@gmail.com on behalf of Michael Krufky
> Sent: Thu 2/26/2009 9:23 PM
> To: Mauro Carvalho Chehab
> Cc: linux-media@vger.kernel.org; Uri Shkolnik
> Subject: Re: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx
>
> On Thu, Feb 26, 2009 at 2:13 PM, Mauro Carvalho Chehab
> wrote:
>> On Fri, 20 Feb 2009 11:53:51 -0500
>> Michael Krufky wrote:
>>
>>> Mauro,
>>>
>>> As you know, there is a large amount of pending changesets from Siano
>>> that are waiting for merge.
>>>
>>> Given the large amount of changes and the impact it has on the
>>> driver's current functionality, I am going to make the merge requests
>>> in phases.
>>>
>>> This is the first phase, which merges the first round of changesets
>>> from Uri, in addition to codingstyle cleanups and some fixes for some
>>> current devices.
>>>
>>> I am still processing through the remaining changesets, but I think
>>> it's important to try to merge some of this now, to reduce the delta
>>> of the changes that will need review when all is done and ready.
>>>
>>> This tree has been tested with the currently supported devices, and it
>>> is a step towards merge of the pending Siano changesets.
>>>
>>> I am sure you will have some comments about these changes -- Let's try
>>> to merge what we can now, and all comments will be addressed in future
>>> cleanups. Please post your comments to this thread so that we may
>>> hold any review discussions in this public forum.
>>>
>>> The main objective of these changesets is to break down the sms1xxx
>>> module into sub-modules. Siano doesn't want to load the usb part of
>>> the driver into memory unless the usb interface is to be used (which
>>> won't always be the case).
>>>
>>> After these changes are merged, I will send additional merge requests
>>> for the later changesets and the addition of the SPI interface.
>>>
>>> Please pull from:
>>>
>>> http://linuxtv.org/hg/~mkrufky/sms1xxx
>>>
>>> for the following changesets:
>>>
>>> - sms1xxx: enable rf switch on Hauppauge Tiger devices
>>> - sms1xxx: move definition of struct smsdvb_client_t into smsdvb.c
>>> - sms1xxx: restore smsusb_driver.name to smsusb
>>> - sms1xxx: move smsusb_id_table into smsusb.c
>>> - import changes from Siano
>>> - sms1xxx: fix checkpatch.pl violations introduced by previous changeset
>>> - sms1xxx: load smsdvb module automatically based on device id
>>>
>>> Makefile | 4
>>> sms-cards.c | 92 ++
>>> sms-cards.h | 7 -
>>> smscoreapi.c | 162 +--
>>> smscoreapi.h | 46 ++-
>>> smsdvb.c | 66 +--
>>> smsusb.c | 73 +++--
>>> 7 files changed, 304 insertions(+), 146 deletions(-)
>>
>> Hmm... Why are you adding all those symbols to be exported?
>>
>> +EXPORT_SYMBOL(smscore_onresponse);
>> +EXPORT_SYMBOL(sms_get_board);
>> +EXPORT_SYMBOL(sms_debug);
>> +EXPORT_SYMBOL(smscore_putbuffer);
>> +EXPORT_SYMBOL(smscore_registry_getmode);
>> +EXPORT_SYMBOL(smscore_register_device);
>> +EXPORT_SYMBOL(smscore_set_board_id);
>> +EXPORT_SYMBOL(smscore_start_device);
>> +EXPORT_SYMBOL(smscore_unregister_device);
>> +EXPORT_SYMBOL(smscore_getbuffer);
>> +EXPORT_SYMBOL(smscore_get_device_mode);
>> +EXPORT_SYMBOL(smscore_register_client);
>> +EXPORT_SYMBOL(smscore_unregister_hotplug);
>> +EXPORT_SYMBOL(smsclient_sendrequest);
>> +EXPORT_SYMBOL(smscore_unregister_client);
>> +EXPORT_SYMBOL(smscore_get_board_id);
>> +EXPORT_SYMBOL(smscore_register_hotplug);
>>
>> Shouldn't all of they be instead EXPORT_SYMBOL_GPL?
>>
>> Cheers,
>> Mauro
>>
>
> cc added to Uri @ Siano.
>
> Uri,
>
> Would it be okay with you if we make the above change? You don't have
> to send in a patch for this right now, since I am already in the midst
> of merging your patch series. If you give permission to change these
> exports to EXPORT_SYMBOL_GPL, then please provide your sign-off and I
> will merge that change for you in the next series merge.
>
> Thanks,
>
> Mike
>
> --
>
> Mike, Mauro,
>
>
> Please feel free to modify **anything** in the code that you think will make
> it more compatible with Linux kernel's methods, guidelines, coding style
> and/or any other relevant directives. Each of you have much more knowledge
> about it than I have.
>
> There is one thing that is significant to me, which is the the flexibility
> of the package (meaning how easy it to add more bus drivers, more interfaces
> and other customers' code / product related adjustments etc. ).
>
> Please remember that this **very** modular software module should continue
> to function with multiple bus-drivers (TS, SPI/SPP, HIF, I2C, ) foreign
> boards ("sms-cards"), and interfaces (DVB v3, DVB v5 and Siano's
> proprietary) from various sources which some of them are not (at the moment)
> available as open source (or sometimes violate Linux kerne
RE: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx
-Original Message-
From: mkru...@gmail.com on behalf of Michael Krufky
Sent: Thu 2/26/2009 9:23 PM
To: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org; Uri Shkolnik
Subject: Re: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx
On Thu, Feb 26, 2009 at 2:13 PM, Mauro Carvalho Chehab
wrote:
> On Fri, 20 Feb 2009 11:53:51 -0500
> Michael Krufky wrote:
>
>> Mauro,
>>
>> As you know, there is a large amount of pending changesets from Siano
>> that are waiting for merge.
>>
>> Given the large amount of changes and the impact it has on the
>> driver's current functionality, I am going to make the merge requests
>> in phases.
>>
>> This is the first phase, which merges the first round of changesets
>> from Uri, in addition to codingstyle cleanups and some fixes for some
>> current devices.
>>
>> I am still processing through the remaining changesets, but I think
>> it's important to try to merge some of this now, to reduce the delta
>> of the changes that will need review when all is done and ready.
>>
>> This tree has been tested with the currently supported devices, and it
>> is a step towards merge of the pending Siano changesets.
>>
>> I am sure you will have some comments about these changes -- Let's try
>> to merge what we can now, and all comments will be addressed in future
>> cleanups. Please post your comments to this thread so that we may
>> hold any review discussions in this public forum.
>>
>> The main objective of these changesets is to break down the sms1xxx
>> module into sub-modules. Siano doesn't want to load the usb part of
>> the driver into memory unless the usb interface is to be used (which
>> won't always be the case).
>>
>> After these changes are merged, I will send additional merge requests
>> for the later changesets and the addition of the SPI interface.
>>
>> Please pull from:
>>
>> http://linuxtv.org/hg/~mkrufky/sms1xxx
>>
>> for the following changesets:
>>
>> - sms1xxx: enable rf switch on Hauppauge Tiger devices
>> - sms1xxx: move definition of struct smsdvb_client_t into smsdvb.c
>> - sms1xxx: restore smsusb_driver.name to smsusb
>> - sms1xxx: move smsusb_id_table into smsusb.c
>> - import changes from Siano
>> - sms1xxx: fix checkpatch.pl violations introduced by previous changeset
>> - sms1xxx: load smsdvb module automatically based on device id
>>
>> Makefile |4
>> sms-cards.c | 92 ++
>> sms-cards.h |7 -
>> smscoreapi.c | 162 +--
>> smscoreapi.h | 46 ++-
>> smsdvb.c | 66 +--
>> smsusb.c | 73 +++--
>> 7 files changed, 304 insertions(+), 146 deletions(-)
>
> Hmm... Why are you adding all those symbols to be exported?
>
> +EXPORT_SYMBOL(smscore_onresponse);
> +EXPORT_SYMBOL(sms_get_board);
> +EXPORT_SYMBOL(sms_debug);
> +EXPORT_SYMBOL(smscore_putbuffer);
> +EXPORT_SYMBOL(smscore_registry_getmode);
> +EXPORT_SYMBOL(smscore_register_device);
> +EXPORT_SYMBOL(smscore_set_board_id);
> +EXPORT_SYMBOL(smscore_start_device);
> +EXPORT_SYMBOL(smscore_unregister_device);
> +EXPORT_SYMBOL(smscore_getbuffer);
> +EXPORT_SYMBOL(smscore_get_device_mode);
> +EXPORT_SYMBOL(smscore_register_client);
> +EXPORT_SYMBOL(smscore_unregister_hotplug);
> +EXPORT_SYMBOL(smsclient_sendrequest);
> +EXPORT_SYMBOL(smscore_unregister_client);
> +EXPORT_SYMBOL(smscore_get_board_id);
> +EXPORT_SYMBOL(smscore_register_hotplug);
>
> Shouldn't all of they be instead EXPORT_SYMBOL_GPL?
>
> Cheers,
> Mauro
>
cc added to Uri @ Siano.
Uri,
Would it be okay with you if we make the above change? You don't have
to send in a patch for this right now, since I am already in the midst
of merging your patch series. If you give permission to change these
exports to EXPORT_SYMBOL_GPL, then please provide your sign-off and I
will merge that change for you in the next series merge.
Thanks,
Mike
--
Mike, Mauro,
Please feel free to modify **anything** in the code that you think will make it
more compatible with Linux kernel's methods, guidelines, coding style and/or
any other relevant directives. Each of you have much more knowledge about it
than I have.
There is one thing that is significant to me, which is the the flexibility of
the package (meaning how easy it to add more bus drivers, more interfaces and
other customers' code / product related adjustments etc. ).
Please remember that this **very** modular software module should continue to
function with multiple bus-drivers (TS, SPI/SPP, HIF, I2C, ) foreign boards
("sms-cards"), and interfaces (DVB v3, DVB v5 and Siano's proprietary) from
various sources which some of them are not (at the moment) available as open
source (or sometimes violate Linux kernel's rules).
The idea is the the module's binary build content is selected by 'make
menuconfig' and *any* variant which includes at least one bus driver (but maybe
more) and at least one interface (but ma
Re: [PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb/
On Thu, 26 Feb 2009 15:28:11 -0300 Mauro Carvalho Chehab wrote: > On Sun, 22 Feb 2009 12:50:34 -0500 > CityK wrote: > > > Douglas Schilling Landgraf wrote: > > > Hi Mauro, > > > > > > Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb/ > > > for the following: > > > > > > - v4l2-apps: Add parser for USB snoops captured from SniffUSB > > > 2.0 > > > > It is not clear to me why this ended up in /v4l2-apps/test, as > > opposed to /v4l2/util -- can someone comment? Thanks. > > You're right. This one is at the wrong place. I'll move it. > Thanks Mauro/CityK! Cheers, Douglas -- 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.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision
On Sat, 21 Feb 2009 22:17:10 +0100 Hans Verkuil wrote: > Hi Mauro, > > Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-usbvision for > the following: > > - v4l2-common: add v4l2_i2c_subdev_addr() > - usbvision: convert to v4l2_device/v4l2_subdev. Thierry/Dwaine, Could you please check if everything is ok with usbvision after those patches? > > Thanks, > > Hans > > diffstat: > drivers/media/video/usbvision/usbvision-core.c |2 > drivers/media/video/usbvision/usbvision-i2c.c | 147 > ++-- > drivers/media/video/usbvision/usbvision-video.c | 63 -- > drivers/media/video/usbvision/usbvision.h |8 - > drivers/media/video/v4l2-common.c |9 + > include/media/v4l2-common.h |2 > 6 files changed, 86 insertions(+), 145 deletions(-) > 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: [PATCH] dvb-api: update documentation, chapter1
Why do I have a feeling even the updated doc will be full of spelling & grammatical errors? ;) Probably, because none of the writers so far where native English. Therefore i'am really happy that *you* now took over all the responsibility to find all that spelling and grammatical errors. ;-) Also, you might want to consider changing "DVB cards" to "DVB devices". For example, I don't know anybody who refers to USB DVB devices as 'DVB cards'. Yes, makes sense. But at the writing time of that API- more then 6 years ago - most probably nobody was thinking of USB for a DVB device. --Winfried -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-api: update documentation, chapter1
On Thu, Feb 26, 2009 at 8:35 AM, VDR User wrote: >> It seems better to say, instead, that "Version 4 was suggested, but it >> weren't completed nor implemented". > > That's improper. I think you mean, "Version 4 was suggested but > neither completed, nor implemented". > > Why do I have a feeling even the updated doc will be full of spelling > & grammatical errors? ;) See below for the irony. >>> +This Linux DVB API documentation will be extended to reflect these >>> additions. >> >> While we don't finish adding the S2API parts, maybe we should say instead: >> >> This document is currently under review to reflect the S2API additions. > > Maybe you should say, "This documentation is a work-in-progress and > doesn't contain the full scope of newer additions year, such as > S2API". Err... s/yet/year in that last line. Oops! ;) -- 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://linuxtv.org/hg/~mkrufky/sms1xxx
On Thu, Feb 26, 2009 at 2:13 PM, Mauro Carvalho Chehab wrote: > On Fri, 20 Feb 2009 11:53:51 -0500 > Michael Krufky wrote: > >> Mauro, >> >> As you know, there is a large amount of pending changesets from Siano >> that are waiting for merge. >> >> Given the large amount of changes and the impact it has on the >> driver's current functionality, I am going to make the merge requests >> in phases. >> >> This is the first phase, which merges the first round of changesets >> from Uri, in addition to codingstyle cleanups and some fixes for some >> current devices. >> >> I am still processing through the remaining changesets, but I think >> it's important to try to merge some of this now, to reduce the delta >> of the changes that will need review when all is done and ready. >> >> This tree has been tested with the currently supported devices, and it >> is a step towards merge of the pending Siano changesets. >> >> I am sure you will have some comments about these changes -- Let's try >> to merge what we can now, and all comments will be addressed in future >> cleanups. Please post your comments to this thread so that we may >> hold any review discussions in this public forum. >> >> The main objective of these changesets is to break down the sms1xxx >> module into sub-modules. Siano doesn't want to load the usb part of >> the driver into memory unless the usb interface is to be used (which >> won't always be the case). >> >> After these changes are merged, I will send additional merge requests >> for the later changesets and the addition of the SPI interface. >> >> Please pull from: >> >> http://linuxtv.org/hg/~mkrufky/sms1xxx >> >> for the following changesets: >> >> - sms1xxx: enable rf switch on Hauppauge Tiger devices >> - sms1xxx: move definition of struct smsdvb_client_t into smsdvb.c >> - sms1xxx: restore smsusb_driver.name to smsusb >> - sms1xxx: move smsusb_id_table into smsusb.c >> - import changes from Siano >> - sms1xxx: fix checkpatch.pl violations introduced by previous changeset >> - sms1xxx: load smsdvb module automatically based on device id >> >> Makefile | 4 >> sms-cards.c | 92 ++ >> sms-cards.h | 7 - >> smscoreapi.c | 162 +-- >> smscoreapi.h | 46 ++- >> smsdvb.c | 66 +-- >> smsusb.c | 73 +++-- >> 7 files changed, 304 insertions(+), 146 deletions(-) > > Hmm... Why are you adding all those symbols to be exported? > > +EXPORT_SYMBOL(smscore_onresponse); > +EXPORT_SYMBOL(sms_get_board); > +EXPORT_SYMBOL(sms_debug); > +EXPORT_SYMBOL(smscore_putbuffer); > +EXPORT_SYMBOL(smscore_registry_getmode); > +EXPORT_SYMBOL(smscore_register_device); > +EXPORT_SYMBOL(smscore_set_board_id); > +EXPORT_SYMBOL(smscore_start_device); > +EXPORT_SYMBOL(smscore_unregister_device); > +EXPORT_SYMBOL(smscore_getbuffer); > +EXPORT_SYMBOL(smscore_get_device_mode); > +EXPORT_SYMBOL(smscore_register_client); > +EXPORT_SYMBOL(smscore_unregister_hotplug); > +EXPORT_SYMBOL(smsclient_sendrequest); > +EXPORT_SYMBOL(smscore_unregister_client); > +EXPORT_SYMBOL(smscore_get_board_id); > +EXPORT_SYMBOL(smscore_register_hotplug); > > Shouldn't all of they be instead EXPORT_SYMBOL_GPL? > > Cheers, > Mauro > cc added to Uri @ Siano. Uri, Would it be okay with you if we make the above change? You don't have to send in a patch for this right now, since I am already in the midst of merging your patch series. If you give permission to change these exports to EXPORT_SYMBOL_GPL, then please provide your sign-off and I will merge that change for you in the next series merge. Thanks, 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
[cron job] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(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:Thu Feb 26 19:00:06 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10677:818c8b74e975 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc5-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29-rc5-armv5-omap2: WARNINGS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: 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-rc5-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc5-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc5-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc5-powerpc64: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: OK 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-rc5-x86_64: WARNINGS fw/apps: OK spec: ERRORS sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc5): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-api: update documentation, chapter1
Mauro Carvalho Chehab wrote:
+
+For this API documentation applies an even/odd versioning scheme, stating
+unstable or stable versions of that API. Only stable API versions should
+be used for developing drivers and applications.
Hmm... I wouldn't add the above. I don't think we should use such versioning
scheme for docs.
I removed that lines.
Can you please comment, how the dvb-developers want to deal with in
future with the transition to a updated documentation?
By looking at the differences between headers and doc, it will take at
least one year or even longer to finish.
Only a comment "currently under review" is probably not sufficient here.
Would it help to add a extra page "Revision History" like its done on
v4l api? If so, please suggest a format for the page.
+In 2003 Convergence and Toshiba Electronics Europe GmbH started the
development
+of
+\href
{http://www.linuxtv.org/downloads/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf}{DVB
API Version 4}
+with public discussion on the linux-dvb mailing list. The goal was a
complete
+new API, reflecting that PCs and embedded platforms are diverging. On a PC
+usually a budget card provides the full raw transport stream and decoding
+and processing is main CPU's task. On embedded platforms, however, data is
+multiplexed by specialized hardware or firmware for direct application use
+which relieves the main CPU from these tasks. Therefore, Linux DVB
+API Version 4 was suggested, but unfortunally never completed.
It seems better to say, instead, that "Version 4 was suggested, but it weren't
completed nor implemented".
I put in here as suggested by Derek:
"Version 4 was suggested but neither completed, nor implemented"
+Today, the LinuxTV project is an independend and non-profit community
project
s/independend/independent/
Changed.
+by DVB/V4L enthusiasts and developers interested in Digital TV and
Analog TV,
+sharing the same hg tree.
+
+However, this document describes only the digital TV part.
I would replace the last paragraph by:
"This document describes the digital TV API. For Analog TV and radio, please consult
V4L2 API."
IMO, we should also add such cross-reference at the V4L2 API, and point both to
linuxtv.org website (so, adding the corresponding \href pointers), for those
interested on getting the other API to know here both are available.
Changed and linked to
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/v4l2spec/v4l2.pdf
+
+
+With the further development of newer DTV standards, the existing version
+3 of the Linux DVB API was no longer able to support all DTV standards and
+newer hardware. Two concurrent approaches to overcome the problem where
+proposed, \texttt{Multiproto} and \texttt{S2API}.
+
+At
+\href {http://www.linuxtv.org/news.php?entry=2008-09-19.mchehab}{Linux
Plumbers Conference 2008}
+the decision was made towards to S2API, basically an extension to
+\texttt{DVB API Version 3} called \texttt{DVB API Version 5}.
+
+
+This Linux DVB API documentation will be extended to reflect these
additions.
While we don't finish adding the S2API parts, maybe we should say instead:
This document is currently under review to reflect the S2API additions.
Changed, but please answer the question above.
Also changed: "dvb card" -> "dvb device" as suggested by Derek.
updated patch below.
-- Winfried
diff -Nurp v4l-dvb-17554cc18063/dvb-spec/dvbapi/dvbapi.tex
v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/dvbapi.tex
--- v4l-dvb-17554cc18063/dvb-spec/dvbapi/dvbapi.tex2009-02-23
16:26:38.0 +0100
+++ v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/dvbapi.tex2009-02-26
18:40:35.008186330 +0100
@@ -1,4 +1,4 @@
-\documentclass[a4paper,10pt]{book}
+\documentclass[a4paper,10pt,oneside]{book}
\usepackage[dvips,colorlinks=true]{hyperref}
\usepackage{times}
diff -Nurp v4l-dvb-17554cc18063/dvb-spec/dvbapi/intro.tex
v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/intro.tex
--- v4l-dvb-17554cc18063/dvb-spec/dvbapi/intro.tex2009-02-23
16:26:38.0 +0100
+++ v4l-dvb-17554cc18063_1/dvb-spec/dvbapi/intro.tex2009-02-26
20:04:57.245819770 +0100
@@ -7,49 +7,84 @@
The reader of this document is required to have some knowledge in the
area of digital video broadcasting (DVB) and should be familiar with
part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222),
-i.e you should know what a program/transport stream (PS/TS) is and what is
-meant by a packetized elementary stream (PES) or an I-frame.
-
-Various DVB standards documents are available from
-\texttt{http://www.dvb.org/} and/or \texttt{http://www.etsi.org/}.
+i.e you should know what a program stream or transport stream (PS/TS) is
+and what is meant by a packetized elementary stream (PES) or an I-frame.
+Various DVB standards documents are available from
\text
Re: [PULL] http://linuxtv.org/hg/~mkrufky/sms1xxx
On Fri, 20 Feb 2009 11:53:51 -0500 Michael Krufky wrote: > Mauro, > > As you know, there is a large amount of pending changesets from Siano > that are waiting for merge. > > Given the large amount of changes and the impact it has on the > driver's current functionality, I am going to make the merge requests > in phases. > > This is the first phase, which merges the first round of changesets > from Uri, in addition to codingstyle cleanups and some fixes for some > current devices. > > I am still processing through the remaining changesets, but I think > it's important to try to merge some of this now, to reduce the delta > of the changes that will need review when all is done and ready. > > This tree has been tested with the currently supported devices, and it > is a step towards merge of the pending Siano changesets. > > I am sure you will have some comments about these changes -- Let's try > to merge what we can now, and all comments will be addressed in future > cleanups. Please post your comments to this thread so that we may > hold any review discussions in this public forum. > > The main objective of these changesets is to break down the sms1xxx > module into sub-modules. Siano doesn't want to load the usb part of > the driver into memory unless the usb interface is to be used (which > won't always be the case). > > After these changes are merged, I will send additional merge requests > for the later changesets and the addition of the SPI interface. > > Please pull from: > > http://linuxtv.org/hg/~mkrufky/sms1xxx > > for the following changesets: > > - sms1xxx: enable rf switch on Hauppauge Tiger devices > - sms1xxx: move definition of struct smsdvb_client_t into smsdvb.c > - sms1xxx: restore smsusb_driver.name to smsusb > - sms1xxx: move smsusb_id_table into smsusb.c > - import changes from Siano > - sms1xxx: fix checkpatch.pl violations introduced by previous changeset > - sms1xxx: load smsdvb module automatically based on device id > > Makefile |4 > sms-cards.c | 92 ++ > sms-cards.h |7 - > smscoreapi.c | 162 +-- > smscoreapi.h | 46 ++- > smsdvb.c | 66 +-- > smsusb.c | 73 +++-- > 7 files changed, 304 insertions(+), 146 deletions(-) Hmm... Why are you adding all those symbols to be exported? +EXPORT_SYMBOL(smscore_onresponse); +EXPORT_SYMBOL(sms_get_board); +EXPORT_SYMBOL(sms_debug); +EXPORT_SYMBOL(smscore_putbuffer); +EXPORT_SYMBOL(smscore_registry_getmode); +EXPORT_SYMBOL(smscore_register_device); +EXPORT_SYMBOL(smscore_set_board_id); +EXPORT_SYMBOL(smscore_start_device); +EXPORT_SYMBOL(smscore_unregister_device); +EXPORT_SYMBOL(smscore_getbuffer); +EXPORT_SYMBOL(smscore_get_device_mode); +EXPORT_SYMBOL(smscore_register_client); +EXPORT_SYMBOL(smscore_unregister_hotplug); +EXPORT_SYMBOL(smsclient_sendrequest); +EXPORT_SYMBOL(smscore_unregister_client); +EXPORT_SYMBOL(smscore_get_board_id); +EXPORT_SYMBOL(smscore_register_hotplug); Shouldn't all of they be instead EXPORT_SYMBOL_GPL? 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://linuxtv.org/hg/~dougsland/v4l-dvb/
On Sun, 22 Feb 2009 12:50:34 -0500 CityK wrote: > Douglas Schilling Landgraf wrote: > > Hi Mauro, > > > > Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb/ for the > > following: > > > > - v4l2-apps: Add parser for USB snoops captured from SniffUSB 2.0 > > It is not clear to me why this ended up in /v4l2-apps/test, as opposed > to /v4l2/util -- can someone comment? Thanks. You're right. This one is at the wrong place. I'll move it. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Old firmware - again af9013 4.65.0 ?!?
Antti wrote: > And remember also replug stick, take account > that without re-plug it could be even downloaded by old windoze driver. > That did the trick! Thanks man! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git pull] DVB + ieee1394: firedtv driver
* Linus Torvalds wrote: > Two choices that I can see: > > - do the ieee1394_init() as a fs_initcall(), earlier > > - move drivers/ieee1394 linking up to before drivers/media > > but I suspect that drivers/media wants to be early, in order to do the > _media_ layer initialization early. > > Does this work? yes, i just tested it and your patch fixes the crash: mercury:~> uname -a Linux mercury 2.6.29-rc6-tip-02011-gb62a1ed-dirty #250 SMP Thu Feb 26 19:00:54 CET 2009 i686 athlon i386 GNU/Linux mercury:~> uptime 19:02:51 up 0 min, 1 user, load average: 3.97, 1.10, 0.37 Tested-by: Ingo Molnar Thanks! Ingo -- 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: AF9015 USB TV STICK
Kaan Aksit wrote: From the address of http://linuxtv.org/hg/v4l-dvb , I have installed my AF9015 USB TV STICK. It works perfect. Thank you very much for the drivers. But I have a small problem with the remote. When I click on volume up or volume down, it does it is job. But for example when I click on number on the remote. It repeats itself infinite in number. Is there a solution to avoid repeating it self? http://linuxtv.org/wiki/index.php/MSI_DigiVox_mini_II_V3.0 http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030292.html regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb-api: update documentation, chapter1
On Thu, Feb 26, 2009 at 7:14 AM, Mauro Carvalho Chehab wrote: > It seems better to say, instead, that "Version 4 was suggested, but it > weren't completed nor implemented". That's improper. I think you mean, "Version 4 was suggested but neither completed, nor implemented". Why do I have a feeling even the updated doc will be full of spelling & grammatical errors? ;) >> +This Linux DVB API documentation will be extended to reflect these >> additions. > > While we don't finish adding the S2API parts, maybe we should say instead: > > This document is currently under review to reflect the S2API additions. Maybe you should say, "This documentation is a work-in-progress and doesn't contain the full scope of newer additions year, such as S2API". Also, you might want to consider changing "DVB cards" to "DVB devices". For example, I don't know anybody who refers to USB DVB devices as 'DVB cards'. Cheers, -Derek -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git pull] DVB + ieee1394: firedtv driver
On Thu, 26 Feb 2009, Stefan Richter wrote: > > Alas I have no Linux box at hand before Saturday. I wonder, was > ieee1394_bus_type not yet registered (i.e. ieee1394's ieee1394_init() not yet > called) at the moment when fdtv_init is executed? > > Or what else could have been the NULL pointer dereference in driver_find? Afaik, the only way that NULL pointer dereference can happen is if struct kobject *k = kset_find_obj(bus->p->drivers_kset, name); gets a NULL pointer exception either because of a NULL "bus" pointer as the argument, or if "bus->p" is NULL. And in this case, it's the latter. The Code: decode shows the whole function in this case: 1c: 55 push %rbp 1d: 89 e5 mov%esp,%ebp 1f: e8 34 5f c8 ff callq 0xffc85f58 24: 89 c1 mov%eax,%ecx 26: 8b 42 38mov0x38(%rdx),%eax 29: 89 ca mov%ecx,%edx 2b:* 8b 40 54mov0x54(%rax),%eax <-- trapping instruction 2e: e8 6c 48 f9 ff callq 0xfff9489f 33: 31 d2 xor%edx,%edx 35: 85 c0 test %eax,%eax 37: 74 03 je 0x3c 39: 8b 50 6cmov0x6c(%rax),%edx 3c: 5d pop%rbp 3d: 89 d0 mov%edx,%eax 3f: c3 retq and that first "callq" seems to be due to Ingo having function tracing on, while the second callq would have been that 'kset_find_obj()' thing. So it does look like "&ieee1394_bus_type" has simply not been initialized yet. It looks like ieee1394_init() is called too late. Two choices that I can see: - do the ieee1394_init() as a fs_initcall(), earlier - move drivers/ieee1394 linking up to before drivers/media but I suspect that drivers/media wants to be early, in order to do the _media_ layer initialization early. Does this work? Linus --- drivers/ieee1394/ieee1394_core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ieee1394/ieee1394_core.c b/drivers/ieee1394/ieee1394_core.c index 1028e72..8723380 100644 --- a/drivers/ieee1394/ieee1394_core.c +++ b/drivers/ieee1394/ieee1394_core.c @@ -1275,7 +1275,7 @@ static void __exit ieee1394_cleanup(void) unregister_chrdev_region(IEEE1394_CORE_DEV, 256); } -module_init(ieee1394_init); +fs_initcall(ieee1394_init); module_exit(ieee1394_cleanup); /* Exported symbols */ -- 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
AF9015 USB TV STICK
Dear Sir, >From the address of http://linuxtv.org/hg/v4l-dvb , I have installed my AF9015 >USB TV STICK. It works perfect. Thank you very much for the drivers. But I >have a small problem with the remote. When I click on volume up or volume >down, it does it is job. But for example when I click on number on the remote. >It repeats itself infinite in number. Is there a solution to avoid repeating >it self? Best regards, Kaan -- 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: dm1105: not demuxing from interrupt context
On 26 февраля 2009, "Igor M. Liplianin" wrote:
> On Thu, 19 Feb 2009 07:18:47 +0200
>
> "Igor M. Liplianin" wrote:
> > I read in mailing list about design error in dm1105.
> > So I am designer.
> > DMA buffer in the driver itself organized like ringbuffer
> > and not difficult to bind it to tasklet or work queue.
> > I choose work queue, because it is like trend :)
> > The code tested by me on quite fast computer and it works as usual.
> > I think, on slow computer difference must be noticeable.
> > The patch is preliminary.
> > Anyone can criticize.
>
> The patch looks fine for me, but, as you said this i preliminary, I'm
> marking it as RFC on patchwork. Please send me the final revision of it,
> after having a final version.
>
> Cheers,
> Mauro.
>
> > diff -r 359d95e1d541 -r f22da8d6a83c
> > linux/drivers/media/dvb/dm1105/dm1105.c ---
> > a/linux/drivers/media/dvb/dm1105/dm1105.cб═б═б═Wed Feb 18 09:49:37 2009
> > -0300 +++ b/linux/drivers/media/dvb/dm1105/dm1105.cб═б═б═Thu Feb 19
> > 04:38:32 2009 +0200 @@ -220,10 +220,14 @@
> > б═б═б═б═б═б═б═б═/* i2c */
> > б═б═б═б═б═б═б═б═struct i2c_adapter i2c_adap;
> > б═
> > +б═б═б═б═б═б═б═/* irq */
> > +б═б═б═б═б═б═б═struct work_struct work;
> > +
> > б═б═б═б═б═б═б═б═/* dma */
> > б═б═б═б═б═б═б═б═dma_addr_t dma_addr;
> > б═б═б═б═б═б═б═б═unsigned char *ts_buf;
> > б═б═б═б═б═б═б═б═u32 wrp;
> > +б═б═б═б═б═б═б═u32 nextwrp;
> > б═б═б═б═б═б═б═б═u32 buffer_size;
> > б═б═б═б═б═б═б═б═unsigned intб═б═б═б═PacketErrorCount;
> > б═б═б═б═б═б═б═б═unsigned int dmarst;
> > @@ -418,6 +422,9 @@
> > б═б═б═б═б═б═б═б═u8 data;
> > б═б═б═б═б═б═б═б═u16 keycode;
> > б═
> > +б═б═б═б═б═б═б═if (ir_debug)
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═printk(KERN_INFO "%s: received byte
> > 0x%04x\n", __func__, ircom); +
> > б═б═б═б═б═б═б═б═data = (ircom >> 8) & 0x7f;
> > б═
> > б═б═б═б═б═б═б═б═input_event(ir->input_dev, EV_MSC, MSC_RAW, (0xf8 <<
> > 16) | data); @@ -434,6 +441,50 @@
> > б═
> > б═}
> > б═
> > +/* work handler */
> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 20)
> > +static void dm1105_dmx_buffer(void *_dm1105dvb)
> > +#else
> > +static void dm1105_dmx_buffer(struct work_struct *work)
> > +#endif
> > +{
> > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 20)
> > +б═б═б═б═б═б═б═struct dm1105dvb *dm1105dvb = _dm1105dvb;
> > +#else
> > +б═б═б═б═б═б═б═struct dm1105dvb *dm1105dvb =
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═container_
> >of(work, struct dm1105dvb, work); +#endif
> > +б═б═б═б═б═б═б═unsigned int nbpackets;
> > +б═б═б═б═б═б═б═u32 oldwrp = dm1105dvb->wrp;
> > +б═б═б═б═б═б═б═u32 nextwrp = dm1105dvb->nextwrp;
> > +
> > +б═б═б═б═б═б═б═if (!((dm1105dvb->ts_buf[oldwrp] == 0x47) &&
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═(dm1105dvb->ts_buf[oldwrp
> > + 188] == 0x47) &&
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═(dm1105dvb->ts_buf[oldwrp
> > + 188 * 2] == 0x47))) {
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═dm1105dvb->PacketErrorCount++;
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═/* bad packet found */
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═if ((dm1105dvb->PacketErrorCount >= 2) &&
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═(dm1105dvb
> >->dmarst == 0)) { +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═outb(1,
> > dm_io_mem(DM1105_RST));
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═dm1105dvb->wrp = 0;
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═dm1105dvb->PacketErrorCoun
> >t = 0; +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═dm1105dvb->dmarst =
> > 0; +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═return;
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═}
> > +б═б═б═б═б═б═б═}
> > +
> > +б═б═б═б═б═б═б═if (nextwrp < oldwrp) {
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═memcpy(dm1105dvb->ts_buf +
> > dm1105dvb->buffer_size,
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═
> >б═б═б═б═б═б═б═б═б═б═б═dm1105dvb->ts_buf, nextwrp);
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═nbpackets = ((dm1105dvb->buffer_size -
> > oldwrp) + nextwrp) / 188; +б═б═б═б═б═б═б═} else
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═nbpackets = (nextwrp - oldwrp) / 188;
> > +
> > +б═б═б═б═б═б═б═dm1105dvb->wrp = nextwrp;
> > +б═б═б═б═б═б═б═dvb_dmx_swfilter_packets(&dm1105dvb->demux,
> > +б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═б═
> >б═б═б═&dm1105dvb->ts_buf[oldwrp], nbpackets); +}
> > +
> > б═#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 19)
> > б═static irqreturn_t dm1105dvb_irq(int irq, void *dev_id, struct pt_regs
> > *regs) б═#else
> > @@ -441,11 +492,6 @@
> > б═#endif
> > б═{
> > б═б═б═б═б═б═б═б═struct dm1105dvb *dm1105dvb = dev_id;
> > -б═б═б═б═б═б═б═unsigned int piece;
> > -б═б═б═б═б═б═б═unsigned int nbpackets;
> > -б═б═б═б═б═б═б═u32 command;
> > -б═б═б═б═б═б═б═u32 nextwrp;
> > -б═б═б═б═б═б═б═u32 oldwrp;
> > б═
> > б═б═б═б═б═б═б═б═/* Read-Write INSTS Ack's Interrupt for DM1105 chip
> > 16.03.2008 */ б═б═б═б═б═б═б═б═unsigned int intsts =
> > inb(dm_io_mem(DM1105_INTSTS)); @@ -454,48 +500,17 @@
> > б═б═б═б═б═б═б═б═switch (intsts) {
Re: [git pull] DVB + ieee1394: firedtv driver
Ingo Molnar wrote: [ 13.756029] calling fdtv_init+0x0/0xf @ 1 [ 13.760074] BUG: unable to handle kernel NULL pointer dereference at 0054 [ 13.764023] IP: [] driver_find+0xf/0x24 [ 13.764023] *pde = [ 13.764023] Oops: [#1] SMP [ 13.764023] last sysfs file: [ 13.764023] [ 13.764023] Pid: 1, comm: swapper Not tainted (2.6.29-rc6-tip-01938-gdb50eec-dirty #27473) System Product Name [ 13.764023] EIP: 0060:[] EFLAGS: 00010286 CPU: 0 [ 13.764023] EIP is at driver_find+0xf/0x24 [ 13.764023] EAX: EBX: c0f8d7ac ECX: c0e4a9dd EDX: c0e4a9dd [ 13.764023] ESI: 0003 EDI: EBP: f70e3f28 ESP: f70e3f28 [ 13.764023] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 13.764023] Process swapper (pid: 1, ti=f70e3000 task=f70e8000 task.ti=f70e3000) [ 13.764023] Stack: [ 13.764023] f70e3f38 c04964a5 c0f8d7a0 0003 f70e3f48 c06eef99 c0f8d6f8 0003 [ 13.764023] f70e3f50 c066ac36 f70e3f5c c105c85c 34294a24 f70e3f64 c105c83a f70e3fc0 [ 13.764023] c0101089 c105c82d 6f727200 6f632072 2d206564 00203231 f70e3fc0 [ 13.764023] Call Trace: [ 13.764023] [] ? driver_register+0x4b/0x96 [ 13.764023] [] ? __hpsb_register_protocol+0x23/0x36 [ 13.764023] [] ? hpsb_register_protocol+0xf/0x11 [ 13.764023] [] ? fdtv_1394_init+0x20/0x42 [ 13.764023] [] ? fdtv_init+0xd/0xf [ 13.764023] [] ? do_one_initcall+0x4f/0x11f [ 13.764023] [] ? fdtv_init+0x0/0xf [ 13.764023] [] ? register_irq_proc+0x87/0xa0 [ 13.764023] [] ? do_initcalls+0x15/0x25 [ 13.764023] [] ? kernel_init+0x0/0x97 [ 13.764023] [] ? do_basic_setup+0x1c/0x1e [ 13.764023] [] ? kernel_init+0x59/0x97 [ 13.764023] [] ? kernel_thread_helper+0x7/0x10 [ 13.764023] Code: b8 64 00 00 00 e8 10 49 cc ff e8 2e fc ff ff 85 c0 75 ed e8 eb 37 cd ff 31 c0 5d c3 55 89 e5 e8 34 5f c8 ff 89 c1 8b 42 38 89 ca <8b> 40 54 e8 6c 48 f9 ff 31 d2 85 c0 74 03 8b 50 6c 5d 89 d0 c3 Config attached. Thanks. Alas I have no Linux box at hand before Saturday. I wonder, was ieee1394_bus_type not yet registered (i.e. ieee1394's ieee1394_init() not yet called) at the moment when fdtv_init is executed? Or what else could have been the NULL pointer dereference in driver_find? Stefan Richter -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Cinergy T USB XXS: remote does not work with 1.20 firmware
Le tridi 3 ventôse, an CCXVII, Nicolas George a écrit :
> I just re-did it:
>
> if(status != -ETIMEDOUT)
> printk("dib0700_rc_query_v1_20: status = %d\n", status);
>
> just after usb_bulk_msg. Then I press keys on the remote: I see mostly
> nothing, but once in a while, I get:
>
> [ 800.589349] dib0700_rc_query_v1_20: status = 0
> [ 800.589366] dib0700: Unknown remote controller key: 00 13 36 c9
>
> I did not manage to find any pattern in the keys that come through: that
> seems completely random.
>
> If I do use the 1.10 firmware and do the same in dib0700_rc_query_legacy
> just after the test against 0.0.0.0, I get a diagnosis line (or several)
> each time I press a key on the remote, without any loss.
Excuse-me to insist, but isn't there anything at all I can do to help get
this remote controller working?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
Re: [PATCH] dvb-api: update documentation, chapter1
On Sun, 22 Feb 2009 18:39:33 +0100
wk wrote:
> Since dvb-api doc is still outdated by six years...
>
>
> The following patch changes dvbapi.pdf as following:
> ___
>
> - change from twosided book format to singlesided book format.
> * By doing so, the readability is improved and on the right-hand side
> is more space on every second page.
>
> - change copyright notice on first page by adding "2008, 2009
> www.linuxtv.org"
>
> - add "The Linux DVB Developers http://www.linuxtv.org"; to 'written by'
>
> - increase API Version number to 5
>
> - change Version Number and date
> -- 24/07/2003V 1.0.0
> ++ 22/02/2009Version 1.1.0 <- unstable version now, every time api
> is changed version should be increased now
>
> - chapter 1 - What you need to know
>* added goal: "consistent abstraction layer for
> different digital TV hardware, allowing software applications to be
> developed without hardware details as well as serving as driver
> developers reference"
>* added comment: odd api version numbers = unstable -> not to be used
> for driver/app development
>
> - chapter 1 - history
> * add History of DVB API v 4
> * add comment LinuxTV project beeing an independend and non-profit
> community
> * add reasons for DVB API v 5 and decision on Plumbers Conference 2008
> towards S2API
>
> - chapter 1 - Overview
> * changed "DVB PCI card" wherever found, since API doesnt depend on
> PCI bus
> * changed "MPEG picture and sound decoding" to "MPEG video and audio
> decoding",
> since mpeg picture is misleading
>
> - fix some typos inside chapter 1
> - fix "Overfull \hbox" warnings from chapter 1 (*only* chapter 1 for now..)
>
> Signed-off-by: Winfried Koehler
> ___
>
> Please response, comment, improve, review, apply. Do not ignore silently,
> having a new API doc should be hard requirement for next kernel versions.
It follows a few comments.
>
> diff -Nrup v4l-dvb-359d95e1d541/dvb-spec/dvbapi/dvbapi.tex
> v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/dvbapi.tex
> --- v4l-dvb-359d95e1d541/dvb-spec/dvbapi/dvbapi.tex2009-02-22
> 17:07:48.123742503 +0100
> +++ v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/dvbapi.tex2009-02-21
> 17:33:29.557033066 +0100
> @@ -1,4 +1,4 @@
> -\documentclass[a4paper,10pt]{book}
> +\documentclass[a4paper,10pt,oneside]{book}
> \usepackage[dvips,colorlinks=true]{hyperref}
>
> \usepackage{times}
> diff -Nrup v4l-dvb-359d95e1d541/dvb-spec/dvbapi/intro.tex
> v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/intro.tex
> --- v4l-dvb-359d95e1d541/dvb-spec/dvbapi/intro.tex2009-02-18
> 13:49:37.0 +0100
> +++ v4l-dvb-a7ea3df69673/dvb-spec/dvbapi/intro.tex2009-02-22
> 16:03:12.610230293 +0100
> @@ -7,36 +7,73 @@
> The reader of this document is required to have some knowledge in the
> area of digital video broadcasting (DVB) and should be familiar with
> part I of the MPEG2 specification ISO/IEC 13818 (aka ITU-T H.222),
> -i.e you should know what a program/transport stream (PS/TS) is and what is
> -meant by a packetized elementary stream (PES) or an I-frame.
> -
> -Various DVB standards documents are available from
> -\texttt{http://www.dvb.org/} and/or \texttt{http://www.etsi.org/}.
> +i.e you should know what a program stream or transport stream (PS/TS) is
> +and what is meant by a packetized elementary stream (PES) or an I-frame.
> +Various DVB standards documents are available from
> \texttt{http://www.dvb.org/}
> +and/or \texttt{http://www.etsi.org/}.
>
> It is also necessary to know how to access unix/linux devices and how
> to use ioctl calls. This also includes the knowledge of C or C++.
>
> +The goal of this API is to provide a consistent abstraction layer for
> +different digital TV hardware, allowing software applications to be
> +developed without hardware details as well as serving as driver
> +developers reference.
> +
> +For this API documentation applies an even/odd versioning scheme, stating
> +unstable or stable versions of that API. Only stable API versions should
> +be used for developing drivers and applications.
Hmm... I wouldn't add the above. I don't think we should use such versioning
scheme for docs.
> +\newpage
> \section{History}
>
> -The first API for DVB cards we used at Convergence in late 1999
> -was an extension of the Video4Linux API which was primarily
> +The first API for DVB cards was used at Convergence in late 1999
> +as an extension of the Video4Linux API which was primarily
> developed for frame grabber cards.
> +
> +
> As such it was not really well suited to be used for DVB cards and
> their new features like recording MPEG streams and filtering several
> section and PES data streams at the same time.
>
> -In early 2000, we were approached by Nokia with a proposal for a new
> +
> +In early 2000, Convergence was approa
Re: dm1105: not demuxing from interrupt context
On Thu, 19 Feb 2009 07:18:47 +0200
"Igor M. Liplianin" wrote:
> I read in mailing list about design error in dm1105.
> So I am designer.
> DMA buffer in the driver itself organized like ringbuffer
> and not difficult to bind it to tasklet or work queue.
> I choose work queue, because it is like trend :)
> The code tested by me on quite fast computer and it works as usual.
> I think, on slow computer difference must be noticeable.
> The patch is preliminary.
> Anyone can criticize.
The patch looks fine for me, but, as you said this i preliminary, I'm marking
it as RFC on patchwork. Please send me the final revision of it, after having a
final version.
Cheers,
Mauro.
>
> diff -r 359d95e1d541 -r f22da8d6a83c linux/drivers/media/dvb/dm1105/dm1105.c
> --- a/linux/drivers/media/dvb/dm1105/dm1105.c Wed Feb 18 09:49:37 2009 -0300
> +++ b/linux/drivers/media/dvb/dm1105/dm1105.c Thu Feb 19 04:38:32 2009 +0200
> @@ -220,10 +220,14 @@
> /* i2c */
> struct i2c_adapter i2c_adap;
>
> + /* irq */
> + struct work_struct work;
> +
> /* dma */
> dma_addr_t dma_addr;
> unsigned char *ts_buf;
> u32 wrp;
> + u32 nextwrp;
> u32 buffer_size;
> unsigned intPacketErrorCount;
> unsigned int dmarst;
> @@ -418,6 +422,9 @@
> u8 data;
> u16 keycode;
>
> + if (ir_debug)
> + printk(KERN_INFO "%s: received byte 0x%04x\n", __func__,
> ircom);
> +
> data = (ircom >> 8) & 0x7f;
>
> input_event(ir->input_dev, EV_MSC, MSC_RAW, (0xf8 << 16) | data);
> @@ -434,6 +441,50 @@
>
> }
>
> +/* work handler */
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 20)
> +static void dm1105_dmx_buffer(void *_dm1105dvb)
> +#else
> +static void dm1105_dmx_buffer(struct work_struct *work)
> +#endif
> +{
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 20)
> + struct dm1105dvb *dm1105dvb = _dm1105dvb;
> +#else
> + struct dm1105dvb *dm1105dvb =
> + container_of(work, struct dm1105dvb, work);
> +#endif
> + unsigned int nbpackets;
> + u32 oldwrp = dm1105dvb->wrp;
> + u32 nextwrp = dm1105dvb->nextwrp;
> +
> + if (!((dm1105dvb->ts_buf[oldwrp] == 0x47) &&
> + (dm1105dvb->ts_buf[oldwrp + 188] == 0x47) &&
> + (dm1105dvb->ts_buf[oldwrp + 188 * 2] == 0x47))) {
> + dm1105dvb->PacketErrorCount++;
> + /* bad packet found */
> + if ((dm1105dvb->PacketErrorCount >= 2) &&
> + (dm1105dvb->dmarst == 0)) {
> + outb(1, dm_io_mem(DM1105_RST));
> + dm1105dvb->wrp = 0;
> + dm1105dvb->PacketErrorCount = 0;
> + dm1105dvb->dmarst = 0;
> + return;
> + }
> + }
> +
> + if (nextwrp < oldwrp) {
> + memcpy(dm1105dvb->ts_buf + dm1105dvb->buffer_size,
> + dm1105dvb->ts_buf, nextwrp);
> + nbpackets = ((dm1105dvb->buffer_size - oldwrp) + nextwrp) /
> 188;
> + } else
> + nbpackets = (nextwrp - oldwrp) / 188;
> +
> + dm1105dvb->wrp = nextwrp;
> + dvb_dmx_swfilter_packets(&dm1105dvb->demux,
> + &dm1105dvb->ts_buf[oldwrp],
> nbpackets);
> +}
> +
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 19)
> static irqreturn_t dm1105dvb_irq(int irq, void *dev_id, struct pt_regs *regs)
> #else
> @@ -441,11 +492,6 @@
> #endif
> {
> struct dm1105dvb *dm1105dvb = dev_id;
> - unsigned int piece;
> - unsigned int nbpackets;
> - u32 command;
> - u32 nextwrp;
> - u32 oldwrp;
>
> /* Read-Write INSTS Ack's Interrupt for DM1105 chip 16.03.2008 */
> unsigned int intsts = inb(dm_io_mem(DM1105_INTSTS));
> @@ -454,48 +500,17 @@
> switch (intsts) {
> case INTSTS_TSIRQ:
> case (INTSTS_TSIRQ | INTSTS_IR):
> - nextwrp = inl(dm_io_mem(DM1105_WRP)) -
> - inl(dm_io_mem(DM1105_STADR)) ;
> - oldwrp = dm1105dvb->wrp;
> - spin_lock(&dm1105dvb->lock);
> - if (!((dm1105dvb->ts_buf[oldwrp] == 0x47) &&
> - (dm1105dvb->ts_buf[oldwrp + 188] == 0x47) &&
> - (dm1105dvb->ts_buf[oldwrp + 188 * 2] ==
> 0x47))) {
> - dm1105dvb->PacketErrorCount++;
> - /* bad packet found */
> - if ((dm1105dvb->PacketErrorCount >= 2) &&
> - (dm1105dvb->dmarst == 0)) {
> - outb(1, dm_io_mem(DM1105_RST));
> - dm1105dvb->wrp = 0;
> - dm1105dvb->PacketErrorCount = 0;
> - dm1105dvb->dmarst = 0;
> -
Re: Is there a way to get linux-media daily digests?
Ok, thanks. I'll give it a try. Thanks for your help. Regards, Eduard 2009/2/26 Pierre Gronlier : > Eduard Huguet wrote: >> Sounds interesting... What client do you use to read the news, may I ask? >> Regards, > > thunderbird, but any news client is fine. > > -- > pierre > >> Eduard >> >> >> 2009/2/26 Pierre Gronlier : >>> Eduard Huguet wrote: Yes, but this way implies using a feed reader or similar. I'm aware of this way, but this would mean unsubscribing from the list to stop receiving the mails and just read them through an external program / webpage. What also means that, if I want to post a new message or just answering one I'd need to re-subscribe again just for doing so. >>> >>> not at all. I just disabled the reception of email through the mailing >>> interface and I can reply to the mailing list directly from my news >>> reader as gname does the bridge between the ml and news. >>> >>> I really preferred the other way (it's what I also use for other mail lists such as mythtv-users and mythtv-dev), and I found it very convenient... Regards Eduard 2009/2/26 Pierre Gronlier : > Eduard Huguet wrote: >> Hi, >> Well, title says old... In previously linux-dvb list I was >> subscribed to the daily digest modality of the list, so I was getting >> only 2 or 3 digest messages per day. This is something I really miss >> now, as I really prefer this way of subscribing to a mail list, >> instead of just receiving every mail sent (I'm just scared thinking >> what I will find in my mailbox when I come back from holidays...). >> >> Is there a way to use such a modality for linux-media? >> >> Best regards, >> Eduard >> >> PS: if I've just missed something and the possibility exists but I'm >> just too dumb to find it, please send me the link with a big RTFM in >> it, I'll take no offense... > You can subscribe to a newsgroup via gmane: > http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure > > this way your mailbox will not be overloaded. > > -- > pierre > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add ids for Yuan PD378S DVB adapter
Signed-off-by: Arnaud Patard
Signed-off-by: Pascal Terjan
---
drivers/media/dvb/dvb-usb/dib0700_devices.c |7 ++-
drivers/media/dvb/dvb-usb/dvb-usb-ids.h |1 +
drivers/media/dvb/dvb-usb/dvb-usb.h |2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_devices.c
b/drivers/media/dvb/dvb-usb/dib0700_devices.c
index 635d30a..fbd8a0c 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -1396,6 +1396,7 @@ struct usb_device_id dib0700_usb_id_table[] = {
{ USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_T_EXPRESS) },
{ USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY_2) },
+ { USB_DEVICE(USB_VID_YUAN, USB_PID_YUAN_PD378S) },
{ 0 } /* Terminating entry */
};
MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -1595,7 +1596,7 @@ struct dvb_usb_device_properties dib0700_devices[] = {
},
},
- .num_device_descs = 9,
+ .num_device_descs = 10,
.devices = {
{ "DiBcom STK7070P reference design",
{ &dib0700_usb_id_table[15], NULL },
@@ -1633,6 +1634,10 @@ struct dvb_usb_device_properties dib0700_devices[] = {
{ &dib0700_usb_id_table[33], NULL },
{ NULL },
},
+ { "Yuan PD378S",
+ { &dib0700_usb_id_table[44], NULL },
+ { NULL },
+ },
},
.rc_interval = DEFAULT_RC_INTERVAL,
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
index 0db0c06..a34a035 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -232,6 +232,7 @@
#define USB_PID_ASUS_U3100 0x173f
#define USB_PID_YUAN_EC372S0x1edc
#define USB_PID_YUAN_STK7700PH 0x1f08
+#define USB_PID_YUAN_PD378S0x2edc
#define USB_PID_DW2102 0x2102
#define USB_PID_XTENSIONS_XD_380 0x0381
#define USB_PID_TELESTAR_STARSTICK_2 0x8000
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb.h
b/drivers/media/dvb/dvb-usb/dvb-usb.h
index b1de0f7..6aaf576 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb.h
@@ -223,7 +223,7 @@ struct dvb_usb_device_properties {
int generic_bulk_ctrl_endpoint;
int num_device_descs;
- struct dvb_usb_device_description devices[9];
+ struct dvb_usb_device_description devices[10];
};
/**
--
1.6.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] writing DVB recorder, questions
Juhana Sadeharju wrote: > Hello. I started writing a simple DVB recorder, dvbrec. Perhaps > it later evolves to program such as Klear, which indeed is > clearest thing I have seen among DVB programs (but misses subtitles). > Hello > The complete stream has too much of data: 10 GB per hour. > As solution, existing recorders seems to pick only parts of the > whole stream (audio and video of one channel), missing many > features, including subtitles. The idea seems to be to drop > the parts that are unwanted and unknown (to author). > > Perfect recording requires more. My idea is to pick all what comes > and drop the known parts: audio and video of the unwanted channels. > This leaves subtitles, alternative languages, robovoice, epg, > text-tv, etc. intact. > > Xine plays poorly the output of "dvbstream -o 8192". I yet don't > know why. Xine people may take this early hint and think about > playing the complete DVB stream with a configurable way to play it. > > Questions: > > (1) In dvbstream, what happens when 8192 is only PID? I have stared > at the code but cannot figure out how the device is configured. I want > all data from the DVB device like "dvbstream -o 8192" does. > Then I may parse the stream on my own. > If you put 8192 at being the only pid you get the whole MPEG2-TS stream of the transponder > (2) Do I need to use demux? PES? Filters? I don't understand them. > Quick intro would be nice as well. > > (3) What PID to use for subtitles? channels.conf lists numbers > 512:650:17 as a last thing. They seem to be video PID (512) and > audio PID (650). Where is the subtitle PID (DMX_SUBTITLE)? > I think you have only the audio video and pmt in this ouput format The pid subtitle change from channel to channel. > (4) I have followed Xine's way, but my program ends to > "Unable to read PAT filter". The polled and read FD is a demux FD. > How the demux should be used? > > I will ask more questions later. Recording video and audio has > been easy, but subtitles, EPG, etc. are quite a different story. > > PS. I'm now trying to read PAT/PTM but I get nothing from > demux FD. I'm following xine-lib, but apparently not enough well. > What I can propose to you is to use mumudvb. (http://mumudvb.braice.net ) It has been made for streaming channels but you can use it indirectly for saving (and I think it can be easily modified to fit you needs) The good point for you is that mumudvb is able to find all the pids for audio, video, PCR, ac3, dts, aac, subtitling, teletext and the mandatory PAT, EIT (wich contains EPG), NIT, SDT, TDT, PMT and send them automatically with the channel. You just have to give the tuning parameters. So you don't have to care about demuxing and sorting data. The second point is that it can stream all the channels of a transponder, so you can record more than one channel at the same time. for recording you can use mplayer in the following way mplayer -dumpfile filename.mpg -dumpstream udp://ip:port Hope this will helps you Best regards -- Brice -- 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]Add green balance v4l2 ctrl support
Hi Erik, On Thursday 26 February 2009 13:04:47 Mauro Carvalho Chehab wrote: > On Mon, 02 Feb 2009 20:14:26 +0100 > > Erik Andrén wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hi, > > > > The m5602 gspca driver has two sensors offering the possiblity to > > control the green balance. This patch adds a v4l2 ctrl for this. What's a "green balance" exactly ? The "red balance" and "blue balance" controls make up the two components of the white balance control (which can also be expressed in color temperature units). How does the "green balance" relate to those ? Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is there a way to get linux-media daily digests?
Eduard Huguet wrote: > Sounds interesting... What client do you use to read the news, may I ask? > Regards, thunderbird, but any news client is fine. -- pierre > Eduard > > > 2009/2/26 Pierre Gronlier : >> Eduard Huguet wrote: >>> Yes, but this way implies using a feed reader or similar. I'm aware of >>> this way, but this would mean unsubscribing from the list to stop >>> receiving the mails and just read them through an external program / >>> webpage. What also means that, if I want to post a new message or just >>> answering one I'd need to re-subscribe again just for doing so. >>> >> >> not at all. I just disabled the reception of email through the mailing >> interface and I can reply to the mailing list directly from my news >> reader as gname does the bridge between the ml and news. >> >> >>> I really preferred the other way (it's what I also use for other mail >>> lists such as mythtv-users and mythtv-dev), and I found it very >>> convenient... >>> >>> Regards >>> Eduard >>> >>> >>> >>> 2009/2/26 Pierre Gronlier : Eduard Huguet wrote: > Hi, > Well, title says old... In previously linux-dvb list I was > subscribed to the daily digest modality of the list, so I was getting > only 2 or 3 digest messages per day. This is something I really miss > now, as I really prefer this way of subscribing to a mail list, > instead of just receiving every mail sent (I'm just scared thinking > what I will find in my mailbox when I come back from holidays...). > > Is there a way to use such a modality for linux-media? > > Best regards, > Eduard > > PS: if I've just missed something and the possibility exists but I'm > just too dumb to find it, please send me the link with a big RTFM in > it, I'll take no offense... You can subscribe to a newsgroup via gmane: http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure this way your mailbox will not be overloaded. -- pierre -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-media" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] writing DVB recorder, questions
Hi Juhana, On Thu, 26 Feb 2009, Juhana Sadeharju wrote: Hello. I started writing a simple DVB recorder, dvbrec. Perhaps it later evolves to program such as Klear, which indeed is clearest thing I have seen among DVB programs (but misses subtitles). The complete stream has too much of data: 10 GB per hour. As solution, existing recorders seems to pick only parts of the whole stream (audio and video of one channel), missing many features, including subtitles. The idea seems to be to drop the parts that are unwanted and unknown (to author). Perfect recording requires more. My idea is to pick all what comes and drop the known parts: audio and video of the unwanted channels. This leaves subtitles, alternative languages, robovoice, epg, text-tv, etc. intact. I'm not answering to your question and I don't know about Robovoice, but for the rest VDR could do it for you. Either with plugins or (most of it) native. VDR in conjunction with vdr-xineliboutput can be nicely integrated in Desktop or dedicated SetTopBox-replacement environments. If I were you, I'd give it a try :) Patrick. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] writing DVB recorder, questions
On Thu, Feb 26, 2009 at 12:28 PM, Juhana Sadeharju wrote: > > Hello. I started writing a simple DVB recorder, dvbrec. Perhaps > it later evolves to program such as Klear, which indeed is > clearest thing I have seen among DVB programs (but misses subtitles). > > The complete stream has too much of data: 10 GB per hour. > As solution, existing recorders seems to pick only parts of the > whole stream (audio and video of one channel), missing many > features, including subtitles. The idea seems to be to drop > the parts that are unwanted and unknown (to author). > > Perfect recording requires more. My idea is to pick all what comes > and drop the known parts: audio and video of the unwanted channels. > This leaves subtitles, alternative languages, robovoice, epg, > text-tv, etc. intact. > > Xine plays poorly the output of "dvbstream -o 8192". I yet don't > know why. Xine people may take this early hint and think about > playing the complete DVB stream with a configurable way to play it. > > Questions: > > (1) In dvbstream, what happens when 8192 is only PID? I have stared > at the code but cannot figure out how the device is configured. I want > all data from the DVB device like "dvbstream -o 8192" does. > Then I may parse the stream on my own. > > (2) Do I need to use demux? PES? Filters? I don't understand them. > Quick intro would be nice as well. > > (3) What PID to use for subtitles? channels.conf lists numbers > 512:650:17 as a last thing. They seem to be video PID (512) and > audio PID (650). Where is the subtitle PID (DMX_SUBTITLE)? > > (4) I have followed Xine's way, but my program ends to > "Unable to read PAT filter". The polled and read FD is a demux FD. > How the demux should be used? > > I will ask more questions later. Recording video and audio has > been easy, but subtitles, EPG, etc. are quite a different story. > > PS. I'm now trying to read PAT/PTM but I get nothing from > demux FD. I'm following xine-lib, but apparently not enough well. > > Juhana > > ___ > linux-dvb users mailing list > For V4L/DVB development, please use instead linux-media@vger.kernel.org > linux-...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > Hi In GStreamer this is easy: If you have a zap style channels.conf file as ~/.gstreamer-0.10/dvb-channels.conf, you can do for example if you have a channel called BBC ONE: gst-launch dvb://BBC\ ONE ! filesink location=bbcone.ts It follows the PAT, PMT and will output the PAT, PMT and all stream pids including subtitle, teletext, private stream as well as all the video and audio pids and the PCR PID (if not one of the stream pids). Zaheer -- 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
writing DVB recorder, questions
Hello. I started writing a simple DVB recorder, dvbrec. Perhaps it later evolves to program such as Klear, which indeed is clearest thing I have seen among DVB programs (but misses subtitles). The complete stream has too much of data: 10 GB per hour. As solution, existing recorders seems to pick only parts of the whole stream (audio and video of one channel), missing many features, including subtitles. The idea seems to be to drop the parts that are unwanted and unknown (to author). Perfect recording requires more. My idea is to pick all what comes and drop the known parts: audio and video of the unwanted channels. This leaves subtitles, alternative languages, robovoice, epg, text-tv, etc. intact. Xine plays poorly the output of "dvbstream -o 8192". I yet don't know why. Xine people may take this early hint and think about playing the complete DVB stream with a configurable way to play it. Questions: (1) In dvbstream, what happens when 8192 is only PID? I have stared at the code but cannot figure out how the device is configured. I want all data from the DVB device like "dvbstream -o 8192" does. Then I may parse the stream on my own. (2) Do I need to use demux? PES? Filters? I don't understand them. Quick intro would be nice as well. (3) What PID to use for subtitles? channels.conf lists numbers 512:650:17 as a last thing. They seem to be video PID (512) and audio PID (650). Where is the subtitle PID (DMX_SUBTITLE)? (4) I have followed Xine's way, but my program ends to "Unable to read PAT filter". The polled and read FD is a demux FD. How the demux should be used? I will ask more questions later. Recording video and audio has been easy, but subtitles, EPG, etc. are quite a different story. PS. I'm now trying to read PAT/PTM but I get nothing from demux FD. I'm following xine-lib, but apparently not enough well. Juhana -- 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]Add green balance v4l2 ctrl support
On Mon, 02 Feb 2009 20:14:26 +0100 Erik Andrén wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > The m5602 gspca driver has two sensors offering the possiblity to > control the green balance. This patch adds a v4l2 ctrl for this. Your patch looks OK. Could you please add also the changes at V4L2 spec? Cheers, Mauro. 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: Is there a way to get linux-media daily digests?
Sounds interesting... What client do you use to read the news, may I ask? Regards, Eduard 2009/2/26 Pierre Gronlier : > Eduard Huguet wrote: >> Yes, but this way implies using a feed reader or similar. I'm aware of >> this way, but this would mean unsubscribing from the list to stop >> receiving the mails and just read them through an external program / >> webpage. What also means that, if I want to post a new message or just >> answering one I'd need to re-subscribe again just for doing so. >> > > > not at all. I just disabled the reception of email through the mailing > interface and I can reply to the mailing list directly from my news > reader as gname does the bridge between the ml and news. > > >> I really preferred the other way (it's what I also use for other mail >> lists such as mythtv-users and mythtv-dev), and I found it very >> convenient... >> >> Regards >> Eduard >> >> >> >> 2009/2/26 Pierre Gronlier : >>> Eduard Huguet wrote: Hi, Well, title says old... In previously linux-dvb list I was subscribed to the daily digest modality of the list, so I was getting only 2 or 3 digest messages per day. This is something I really miss now, as I really prefer this way of subscribing to a mail list, instead of just receiving every mail sent (I'm just scared thinking what I will find in my mailbox when I come back from holidays...). Is there a way to use such a modality for linux-media? Best regards, Eduard PS: if I've just missed something and the possibility exists but I'm just too dumb to find it, please send me the link with a big RTFM in it, I'll take no offense... >>> You can subscribe to a newsgroup via gmane: >>> http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure >>> >>> this way your mailbox will not be overloaded. >>> >>> -- >>> pierre >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-media" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4] v4l/tvp514x: make the module aware of rich people
On Thu, 26 Feb 2009, Hiremath, Vaibhav wrote: Hi Sebastian, I have validated the changes and it looks ok to me. As I mentioned the only issue I observed is, patch doesn't get applied cleanly (may be due to mail-server). Hans/Mauro, You can pull this patch. Applied, thanks. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 -Original Message- From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de] Sent: Saturday, February 21, 2009 2:14 PM To: Hiremath, Vaibhav Cc: video4linux-l...@redhat.com; mche...@infradead.org; linux- me...@vger.kernel.org Subject: Re: [PATCH v4] v4l/tvp514x: make the module aware of rich people * Sebastian Andrzej Siewior | 2009-02-10 20:30:39 [+0100]: because they might design two of those chips on a single board. You never know. Signed-off-by: Sebastian Andrzej Siewior --- v4: fix checkpatch issues I don't want to rush anything but is there any update on this? Sebastian -- Cheers, Mauro Carvalho Chehab http://linuxtv.org mche...@infradead.org -- 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: Is there a way to get linux-media daily digests?
Eduard Huguet wrote: > Yes, but this way implies using a feed reader or similar. I'm aware of > this way, but this would mean unsubscribing from the list to stop > receiving the mails and just read them through an external program / > webpage. What also means that, if I want to post a new message or just > answering one I'd need to re-subscribe again just for doing so. > not at all. I just disabled the reception of email through the mailing interface and I can reply to the mailing list directly from my news reader as gname does the bridge between the ml and news. > I really preferred the other way (it's what I also use for other mail > lists such as mythtv-users and mythtv-dev), and I found it very > convenient... > > Regards > Eduard > > > > 2009/2/26 Pierre Gronlier : >> Eduard Huguet wrote: >>> Hi, >>> Well, title says old... In previously linux-dvb list I was >>> subscribed to the daily digest modality of the list, so I was getting >>> only 2 or 3 digest messages per day. This is something I really miss >>> now, as I really prefer this way of subscribing to a mail list, >>> instead of just receiving every mail sent (I'm just scared thinking >>> what I will find in my mailbox when I come back from holidays...). >>> >>> Is there a way to use such a modality for linux-media? >>> >>> Best regards, >>> Eduard >>> >>> PS: if I've just missed something and the possibility exists but I'm >>> just too dumb to find it, please send me the link with a big RTFM in >>> it, I'll take no offense... >> You can subscribe to a newsgroup via gmane: >> http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure >> >> this way your mailbox will not be overloaded. >> >> -- >> pierre >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-media" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] v4l/tvp514x: make the module aware of rich people
Hiremath, Vaibhav wrote: Hi Sebastian, Hi, I have validated the changes and it looks ok to me. As I mentioned the only issue I observed is, patch doesn't get applied cleanly (may be due to mail-server). After you drop me that mail, I posted that patch at [0]. I haven't seen any patches in the v4l-next tree which might cause a clash. [0] http://download.breakpoint.cc/0001-v4l-tvp514x-make-the-module-aware-of-rich-people.patch Thanks, Vaibhav Hiremath Sebastian -- 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: zc3xx: "Creative Webcam Live!" never worked with in-tree driver
On Thu, 26 Feb 2009 00:51:51 -0800 Auke Kok wrote: > > Eventually, the v4l library is needed when using any v4l2 driver, > > not only gspca. Hopefully, many popular applications now use it > > natively, as vlc 0.9.x. > > interesting, but I can't get vlc to understand either tv:// or > /dev/video0... any hints? You may find the command line syntax opening the device/file/network flow with the GUI. For webcams, I found: vlc v4l2:// :v4l2-dev=/dev/video0 :v4l2-standard=0 You may also start the webcam from a playlist with: #EXTINF:0,webcam #EXTVLCOPT:v4l2-dev=/dev/video0 #EXTVLCOPT:v4l2-standard=0 v4l2:// -- 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: [PATCH v4] v4l/tvp514x: make the module aware of rich people
Hi Sebastian, I have validated the changes and it looks ok to me. As I mentioned the only issue I observed is, patch doesn't get applied cleanly (may be due to mail-server). Hans/Mauro, You can pull this patch. Thanks, Vaibhav Hiremath Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 > -Original Message- > From: Sebastian Andrzej Siewior [mailto:bige...@linutronix.de] > Sent: Saturday, February 21, 2009 2:14 PM > To: Hiremath, Vaibhav > Cc: video4linux-l...@redhat.com; mche...@infradead.org; linux- > me...@vger.kernel.org > Subject: Re: [PATCH v4] v4l/tvp514x: make the module aware of rich > people > > * Sebastian Andrzej Siewior | 2009-02-10 20:30:39 [+0100]: > > >because they might design two of those chips on a single board. > >You never know. > > > >Signed-off-by: Sebastian Andrzej Siewior > >--- > >v4: fix checkpatch issues > > I don't want to rush anything but is there any update on this? > > Sebastian -- 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: Is there a way to get linux-media daily digests?
Yes, but this way implies using a feed reader or similar. I'm aware of this way, but this would mean unsubscribing from the list to stop receiving the mails and just read them through an external program / webpage. What also means that, if I want to post a new message or just answering one I'd need to re-subscribe again just for doing so. I really preferred the other way (it's what I also use for other mail lists such as mythtv-users and mythtv-dev), and I found it very convenient... Regards Eduard 2009/2/26 Pierre Gronlier : > Eduard Huguet wrote: >> Hi, >> Well, title says old... In previously linux-dvb list I was >> subscribed to the daily digest modality of the list, so I was getting >> only 2 or 3 digest messages per day. This is something I really miss >> now, as I really prefer this way of subscribing to a mail list, >> instead of just receiving every mail sent (I'm just scared thinking >> what I will find in my mailbox when I come back from holidays...). >> >> Is there a way to use such a modality for linux-media? >> >> Best regards, >> Eduard >> >> PS: if I've just missed something and the possibility exists but I'm >> just too dumb to find it, please send me the link with a big RTFM in >> it, I'll take no offense... > > You can subscribe to a newsgroup via gmane: > http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure > > this way your mailbox will not be overloaded. > > -- > pierre > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] sh_mobile_ceu: Add field signal operation
On Thu, Feb 5, 2009 at 5:04 PM, Guennadi Liakhovetski
wrote:
> On Tue, 3 Feb 2009, Kuninori Morimoto wrote:
>
>> sh_mobile_ceu can support "field signal" from external module.
>> To support this operation, SH_CEU_FLAG_USE_FLDID_{HIGH, LOW}
>> are added to header.
>
> I never dealt with interlaced video, so, I probably just don't understand
> something, please explain. I understand the Field ID signal is optional,
> and, if used, it can be either active high or low. But who gets to decide
> which polarity is applicable in a specific case? The platform? Is it not
> like with other control signals, where if both partners are freely
> configurable, then any polarity can be used; if one is configurable and
> another is hard-wired, only one polarity can be used. And as long as the
> signal is available (connected), the platform has no further influence on
> its use? Ok, there can be an inverter there, but that we can handle too.
I believe you are correct. It is just yet another signal.
> So, wouldn't something like
>
> + if (pcdev->pdata->flags & SH_CEU_FLAG_USE_FLDID)
> + flags |= SOCAM_FIELD_ID_ACTIVE_HIGH |
> SOCAM_FIELD_ID_ACTIVE_LOW;
> +
>
> ...
>
> + if (common_flags & (SOCAM_FIELD_ID_ACTIVE_HIGH |
> SOCAM_FIELD_ID_ACTIVE_LOW) ==
> + SOCAM_FIELD_ID_ACTIVE_LOW)
> + /* The client only supports active low field ID */
> + value |= 1 << 16;
> + /* Otherwise we are free to choose, leave default active high */
>
> Or does Field ID work differently?
Nope, it works just like that. I guess what makes this confusing is
that we have some boards that don't have the FLD signal. So far the
CEU driver has had it's configuration passed as platform data, but
making it more generic and fit better to the soc-camera framework is
of course a good idea. But we may need a way to specify the actual
configuration of our board.
So the TV decoder chip has a field signal. So does the CEU. But not
early versions of the board.
> And what do you do, if the platform doesn't specify SH_CEU_FLAG_USE_FLDID,
> i.e., it is not connected, but the client does? Or the other way round? In
> other words, is it a working configuration, when one of the partners
> provides this signal and the other one doesn't? I guess it is, because,
> you say, it is optional. So we shouldn't test it in
> soc_camera_bus_param_compatible()?
I made a hack half a year ago that worked around the interlaced
640x480 video with missing field signal to 640x240 progressive.
Basically exactly the same as interlace for the TV decoder but the CEU
is configured in 640x240 progressive mode and gets the double amount
of frames per second.
Not sure if we want such a feature upstream though, so maybe this may
be a non-issue. =)
Cheers,
/ magnus
--
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: Is there a way to get linux-media daily digests?
Eduard Huguet wrote: > Hi, > Well, title says old... In previously linux-dvb list I was > subscribed to the daily digest modality of the list, so I was getting > only 2 or 3 digest messages per day. This is something I really miss > now, as I really prefer this way of subscribing to a mail list, > instead of just receiving every mail sent (I'm just scared thinking > what I will find in my mailbox when I come back from holidays...). > > Is there a way to use such a modality for linux-media? > > Best regards, > Eduard > > PS: if I've just missed something and the possibility exists but I'm > just too dumb to find it, please send me the link with a big RTFM in > it, I'll take no offense... You can subscribe to a newsgroup via gmane: http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure this way your mailbox will not be overloaded. -- pierre -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
news about the NetUP Dual DVB-S2-CI card
Is there any news about the NetUP Dual DVB-S2-CI card status ? (http://linuxtv.org/wiki/index.php/NetUP_Dual_DVB_S2_CI) the last thread I found was : http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030439.html and http://www.linuxtv.org/pipermail/linux-dvb/2008-November/030445.html for the STM STV0900BAB demodulator driver. Is someone manage to capture 2 transponders with two cams ? or/and use this card with a dual lnb head ? Thanks, -- pierre -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: zc3xx: "Creative Webcam Live!" never worked with in-tree driver
Auke Kok a écrit : > Jean-Francois Moine wrote: >> On Tue, 24 Feb 2009 21:19:16 -0300 >> Mauro Carvalho Chehab wrote: >>> On Tue, 24 Feb 2009 16:00:59 -0800 >>> Auke Kok wrote: >>> Auke Kok wrote: > All, > > I have a "Creative Technology, Ltd Webcam Live!/Live! Pro" that > until recently worked fine with the out-of-tree gspcav1 driver > (gspcav1-20071224.tar.gz is the latest version I used unti > 2.6.26). > > Since this driver (basically) got merged in the kernel I got my > hopes up that the in-kernel gspca_zc3xx drivers would work. > However, that does not provide a usable video0 device - mplayer > tv:// crashes with 'No stream found.' for instance: > > Playing tv://. > Cache fill: 0.00% (0 bytes) > TV file format detected. > Selected driver: v4l2 > name: Video 4 Linux 2 input > author: Martin Olschewski > comment: first try, more to come ;-) > Selected device: WebCam Live! > Capabilites: video capture read/write streaming > supported norms: > inputs: 0 = zc3xx; > Current input: 0 > Current format: unknown (0x4745504a) > tv.c: norm_from_string(pal): Bogus norm parameter, setting > default. v4l2: ioctl enum norm failed: Invalid argument > Error: Cannot set norm! > Selected input hasn't got a tuner! > v4l2: ioctl set mute failed: Invalid argument > v4l2: ioctl query control failed: Invalid argument > v4l2: ioctl query control failed: Invalid argument > FPS not specified in the header or invalid, use the -fps option. > No stream found. > > v4l2: ioctl set mute failed: Invalid argument > v4l2: 0 frames successfully processed, 0 frames dropped. > > Exiting... (End of file) > > > I've regressed back to the original import of the spca driver in > the kernel tree and this doesn't fix it, so I'm assuming that the > driver were not merged correctly for my particular device. > > Basically the driver probes and load fine as is right now, no > unusual message in dmesg as far as I can see: > > zc0301: V4L2 driver for ZC0301[P] Image Processor and Control > Chip v1:1.10 usbcore: registered new interface driver zc0301 > usbcore: deregistering interface driver zc0301 > gspca: probing 041e:4036 > zc3xx: probe 2wr ov vga 0x > zc3xx: probe sensor -> 11 > zc3xx: Find Sensor HV7131R(c) > gspca: probe ok > usbcore: registered new interface driver zc3xx > zc3xx: registered > > > I can post the output of the gspcav1 module with debug=5 for the > register writes/reads if that is interesting, or anything else > for that matter - I'd really like to keep this webcam working and > staying at kernel 2.6.25 is not an option. > > is there a way to get the gspca_zc3xx driver dump register > read/writes? this would be a quick way to compare the two drivers > and look at the differences. > seems I just found the v4lcompat.so stuff, which (apart from being a pain in the rear) makes the webcam work again... >>> This seems to be a very common error. IMO, we should write message >>> when loading a gspca that would require libv4l in order to work. >> >> First, it is strange that mplayer does not work: the v4l2 interface >> seems recognized, but why does it say: >> >> Current format: unknown (0x4745504a) >> >> while this is JPEG and it knows well how to handle it? >> >> Then, at probe time, there is: >> >> zc0301: V4L2 driver for ZC0301[P] Image Processor and Control > > I pasted too much there, as you can see below I unloaded that driver: > > zc0301: V4L2 driver for ZC0301[P] Image Processor and Control > Chip v1:1.10 usbcore: registered new interface driver zc0301 > usbcore: deregistering interface driver zc0301 > > >> >> This means that an other driver wants to handle the webcam. This may >> raise problems. >> >> Eventually, the v4l library is needed when using any v4l2 driver, not >> only gspca. Hopefully, many popular applications now use it natively, >> as vlc 0.9.x. > > interesting, but I can't get vlc to understand either tv:// or > /dev/video0... any hints? Hi, With mplayer I use : mplayer -fps 30 -tv driver=v4l2:width=640:height=480:device=/dev/video0 tv:// and it works well with my Labtec webcam Pro : zc3xx Michel. > > Auke > -- > 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
Is there a way to get linux-media daily digests?
Hi, Well, title says old... In previously linux-dvb list I was subscribed to the daily digest modality of the list, so I was getting only 2 or 3 digest messages per day. This is something I really miss now, as I really prefer this way of subscribing to a mail list, instead of just receiving every mail sent (I'm just scared thinking what I will find in my mailbox when I come back from holidays...). Is there a way to use such a modality for linux-media? Best regards, Eduard PS: if I've just missed something and the possibility exists but I'm just too dumb to find it, please send me the link with a big RTFM in it, I'll take no offense... -- 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: zc3xx: "Creative Webcam Live!" never worked with in-tree driver
Jean-Francois Moine wrote: On Tue, 24 Feb 2009 21:19:16 -0300 Mauro Carvalho Chehab wrote: On Tue, 24 Feb 2009 16:00:59 -0800 Auke Kok wrote: Auke Kok wrote: All, I have a "Creative Technology, Ltd Webcam Live!/Live! Pro" that until recently worked fine with the out-of-tree gspcav1 driver (gspcav1-20071224.tar.gz is the latest version I used unti 2.6.26). Since this driver (basically) got merged in the kernel I got my hopes up that the in-kernel gspca_zc3xx drivers would work. However, that does not provide a usable video0 device - mplayer tv:// crashes with 'No stream found.' for instance: Playing tv://. Cache fill: 0.00% (0 bytes) TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski comment: first try, more to come ;-) Selected device: WebCam Live! Capabilites: video capture read/write streaming supported norms: inputs: 0 = zc3xx; Current input: 0 Current format: unknown (0x4745504a) tv.c: norm_from_string(pal): Bogus norm parameter, setting default. v4l2: ioctl enum norm failed: Invalid argument Error: Cannot set norm! Selected input hasn't got a tuner! v4l2: ioctl set mute failed: Invalid argument v4l2: ioctl query control failed: Invalid argument v4l2: ioctl query control failed: Invalid argument FPS not specified in the header or invalid, use the -fps option. No stream found. v4l2: ioctl set mute failed: Invalid argument v4l2: 0 frames successfully processed, 0 frames dropped. Exiting... (End of file) I've regressed back to the original import of the spca driver in the kernel tree and this doesn't fix it, so I'm assuming that the driver were not merged correctly for my particular device. Basically the driver probes and load fine as is right now, no unusual message in dmesg as far as I can see: zc0301: V4L2 driver for ZC0301[P] Image Processor and Control Chip v1:1.10 usbcore: registered new interface driver zc0301 usbcore: deregistering interface driver zc0301 gspca: probing 041e:4036 zc3xx: probe 2wr ov vga 0x zc3xx: probe sensor -> 11 zc3xx: Find Sensor HV7131R(c) gspca: probe ok usbcore: registered new interface driver zc3xx zc3xx: registered I can post the output of the gspcav1 module with debug=5 for the register writes/reads if that is interesting, or anything else for that matter - I'd really like to keep this webcam working and staying at kernel 2.6.25 is not an option. is there a way to get the gspca_zc3xx driver dump register read/writes? this would be a quick way to compare the two drivers and look at the differences. seems I just found the v4lcompat.so stuff, which (apart from being a pain in the rear) makes the webcam work again... This seems to be a very common error. IMO, we should write message when loading a gspca that would require libv4l in order to work. First, it is strange that mplayer does not work: the v4l2 interface seems recognized, but why does it say: Current format: unknown (0x4745504a) while this is JPEG and it knows well how to handle it? Then, at probe time, there is: zc0301: V4L2 driver for ZC0301[P] Image Processor and Control I pasted too much there, as you can see below I unloaded that driver: zc0301: V4L2 driver for ZC0301[P] Image Processor and Control Chip v1:1.10 usbcore: registered new interface driver zc0301 usbcore: deregistering interface driver zc0301 This means that an other driver wants to handle the webcam. This may raise problems. Eventually, the v4l library is needed when using any v4l2 driver, not only gspca. Hopefully, many popular applications now use it natively, as vlc 0.9.x. interesting, but I can't get vlc to understand either tv:// or /dev/video0... any hints? Auke -- 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: zc3xx: "Creative Webcam Live!" never worked with in-tree driver
On Tue, 24 Feb 2009 21:19:16 -0300 Mauro Carvalho Chehab wrote: > > On Tue, 24 Feb 2009 16:00:59 -0800 > Auke Kok wrote: > > > Auke Kok wrote: > > > > > > All, > > > > > > I have a "Creative Technology, Ltd Webcam Live!/Live! Pro" that > > > until recently worked fine with the out-of-tree gspcav1 driver > > > (gspcav1-20071224.tar.gz is the latest version I used unti > > > 2.6.26). > > > > > > Since this driver (basically) got merged in the kernel I got my > > > hopes up that the in-kernel gspca_zc3xx drivers would work. > > > However, that does not provide a usable video0 device - mplayer > > > tv:// crashes with 'No stream found.' for instance: > > > > > > Playing tv://. > > > Cache fill: 0.00% (0 bytes) > > > TV file format detected. > > > Selected driver: v4l2 > > > name: Video 4 Linux 2 input > > > author: Martin Olschewski > > > comment: first try, more to come ;-) > > > Selected device: WebCam Live! > > > Capabilites: video capture read/write streaming > > > supported norms: > > > inputs: 0 = zc3xx; > > > Current input: 0 > > > Current format: unknown (0x4745504a) > > > tv.c: norm_from_string(pal): Bogus norm parameter, setting > > > default. v4l2: ioctl enum norm failed: Invalid argument > > > Error: Cannot set norm! > > > Selected input hasn't got a tuner! > > > v4l2: ioctl set mute failed: Invalid argument > > > v4l2: ioctl query control failed: Invalid argument > > > v4l2: ioctl query control failed: Invalid argument > > > FPS not specified in the header or invalid, use the -fps option. > > > No stream found. > > > > > > v4l2: ioctl set mute failed: Invalid argument > > > v4l2: 0 frames successfully processed, 0 frames dropped. > > > > > > Exiting... (End of file) > > > > > > > > > I've regressed back to the original import of the spca driver in > > > the kernel tree and this doesn't fix it, so I'm assuming that the > > > driver were not merged correctly for my particular device. > > > > > > Basically the driver probes and load fine as is right now, no > > > unusual message in dmesg as far as I can see: > > > > > > zc0301: V4L2 driver for ZC0301[P] Image Processor and Control > > > Chip v1:1.10 usbcore: registered new interface driver zc0301 > > > usbcore: deregistering interface driver zc0301 > > > gspca: probing 041e:4036 > > > zc3xx: probe 2wr ov vga 0x > > > zc3xx: probe sensor -> 11 > > > zc3xx: Find Sensor HV7131R(c) > > > gspca: probe ok > > > usbcore: registered new interface driver zc3xx > > > zc3xx: registered > > > > > > > > > I can post the output of the gspcav1 module with debug=5 for the > > > register writes/reads if that is interesting, or anything else > > > for that matter - I'd really like to keep this webcam working and > > > staying at kernel 2.6.25 is not an option. > > > > > > is there a way to get the gspca_zc3xx driver dump register > > > read/writes? this would be a quick way to compare the two drivers > > > and look at the differences. > > > > > > > seems I just found the v4lcompat.so stuff, which (apart from being > > a pain in the rear) makes the webcam work again... > > This seems to be a very common error. IMO, we should write message > when loading a gspca that would require libv4l in order to work. First, it is strange that mplayer does not work: the v4l2 interface seems recognized, but why does it say: Current format: unknown (0x4745504a) while this is JPEG and it knows well how to handle it? Then, at probe time, there is: zc0301: V4L2 driver for ZC0301[P] Image Processor and Control This means that an other driver wants to handle the webcam. This may raise problems. Eventually, the v4l library is needed when using any v4l2 driver, not only gspca. Hopefully, many popular applications now use it natively, as vlc 0.9.x. Cheers. -- 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
