Re: Fix for crash in dvb-usb-af9015
Antti Palosaari wrote:
I need your signed off by tag in order to forward this mainline.
Patch is correct and I tested it also.
OK, here it is again with the requested line. And thanks for taking care
of the issue.
Signed-off-by: Nils Kassube kass...@gmx.net
---
--- orig/linux-2.6.31/drivers/media/dvb/dvb-usb/af9015.c2009-06-30
11:34:45.0 +0200
+++ linux-2.6.31/drivers/media/dvb/dvb-usb/af9015.c 2009-07-07
14:58:27.0 +0200
@@ -81,7 +81,6 @@
switch (req-cmd) {
case GET_CONFIG:
- case BOOT:
case READ_MEMORY:
case RECONNECT_USB:
case GET_IR_CODE:
@@ -100,6 +99,7 @@
case WRITE_VIRTUAL_MEMORY:
case COPY_FIRMWARE:
case DOWNLOAD_FIRMWARE:
+ case BOOT:
break;
default:
err(unknown command:%d, req-cmd);
--
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: Afatech AF9013 DVB-T not working with mplayer radio streams
Antti Palosaari wrote: Hei Devin and Jelle, On 07/11/2009 12:12 AM, Antti Palosaari wrote: I'm not the maintainer for this demod, so I'm not the best person to make such a fix. I spent four hours and debugged the issue as a favor to Jelle de Jong since he loaned me some hardware a couple of months ago. I guess I can make the fix, but it's just going to take away from time better spent on things I am more qualified to work on. Devin I will fix that just right now. I think I will change demodulator from return error invalid value to force detect transmission parameters automatically in case of broken parameters given. It is fixed now as I see best way. For reason or other my MPlayer didn't give garbage and I never seen any of those debugs added. I added just similar channels.conf line as Jelle but changed freq and PIDs used here. Maybe garbage fields are filled 0 which corresponds AUTO. Anyhow, here it is. Could you test? http://linuxtv.org/hg/~anttip/af9013/ regards Antti I tried to test it but it did not work, i tried to get some more information with printk i am sure but not much luck there. Al test where done on the test system, you can login and see for yourself. Best regards, Jelle cd hg clone http://linuxtv.org/hg/~anttip/af9013/ cd af9013/ make -j3 sudo make install sudo make unload sudo modprobe dvb_usb_af9015 mplayer -nolirc -nojoystick -dvbin card=1 -dvbin timeout=10 dvb://3FM(Digitenne) # did not work -- 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
About v4l2 subdev s_config (for core) API?
Hi, The thing is - Is it possible to make the subdev device not to be turned on in registering process using any of v4l2_i2c_new_subdev*** ? You can say that I can ignore the i2c errors in booting process, but I think it is not a pretty way. And for the reason I'm asking you about this, I need you to consider following conditions I carry. 1. ARM embedded platform especially mobile handset. 2. Mass production which is very concerned about power consumption. 3. Strict and automated test process in product line. So, what I want to ask you is about s_config subdev call which is called from every single I2C subdev load in some kind of probe procedure. As s_config is supposed to do, it tries to initialize subdev device. which means it needs to turn on the subdev to make that initialized. But as I mentioned above if we make the product go through the product line, it turns on the subdev device even though nobody intended to turn the subdev on. It might be an issue in product vendor's point of view, because there should be a crystal clear reason for the consumption of power the subdev made. I'm working on camera device and speaking of which, camera devices are really power consuming device and some camera devices even take ages to be initialized as well. So far I hope I made a good explanation about why I'm asking you about following question. By the way, it seems to be similar to the issue I've faced whe using old i2c driver model..I mean probing i2c devices on boot up sequence. Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
Jelle de Jong wrote: Antti Palosaari wrote: Hei Devin and Jelle, On 07/11/2009 12:12 AM, Antti Palosaari wrote: I'm not the maintainer for this demod, so I'm not the best person to make such a fix. I spent four hours and debugged the issue as a favor to Jelle de Jong since he loaned me some hardware a couple of months ago. I guess I can make the fix, but it's just going to take away from time better spent on things I am more qualified to work on. Devin I will fix that just right now. I think I will change demodulator from return error invalid value to force detect transmission parameters automatically in case of broken parameters given. It is fixed now as I see best way. For reason or other my MPlayer didn't give garbage and I never seen any of those debugs added. I added just similar channels.conf line as Jelle but changed freq and PIDs used here. Maybe garbage fields are filled 0 which corresponds AUTO. Anyhow, here it is. Could you test? http://linuxtv.org/hg/~anttip/af9013/ regards Antti I tried to test it but it did not work, i tried to get some more information with printk i am sure but not much luck there. Al test where done on the test system, you can login and see for yourself. Best regards, Jelle cd hg clone http://linuxtv.org/hg/~anttip/af9013/ cd af9013/ make -j3 sudo make install sudo make unload sudo modprobe dvb_usb_af9015 mplayer -nolirc -nojoystick -dvbin card=1 -dvbin timeout=10 dvb://3FM(Digitenne) # did not work I keep doing test and the debug i got showed it was in auto mode, so i did a tzap -a 0 -c ~/.tzap/channels.conf -r 3FM(Digitenne) no lock :D that other bug was teasing me again... :D I manually replugged the device and mplayer works perfect. So patch confirmed to build and work. Thank you very much! Best regards, Jelle -- 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] problems with Terratec Cinergy 1200 DVB-C MK3 after mainboard switch
On Sat, 2009-07-11 at 14:44 +0200, Matthias Müller wrote: Hi, I use two Cinergy 1200 DVB-C MK3 for quite a long time and had no problems so far. Now I switched to a new mainboard (Asus m4n78 pro) and after some time, the dvb-c cards aren't usable anymore. This can be triggered by heavy IO. On both mainboards I use Ubuntu 9.04 with the same kernel version (2.6.28-13-generic, also tested with 2.6.28-14-server). While running vdr I see the following in syslog: Jul 11 12:29:52 bowser vdr: [4678] frontend 0 lost lock on channel 6, tp 121 Jul 11 12:29:52 bowser kernel: [ 1235.601266] DVB: TDA10023(0): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser vdr: [4682] frontend 1 lost lock on channel 40, tp 730 Jul 11 12:29:52 bowser kernel: [ 1235.631263] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1235.701265] DVB: TDA10023(0): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1235.741264] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1235.801262] tda10023: lock tuner fails Jul 11 12:29:52 bowser kernel: [ 1235.851263] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1235.951264] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1236.001263] tda10023: unlock tuner fails Jul 11 12:29:52 bowser kernel: [ 1236.051271] tda10023: lock tuner fails Jul 11 12:29:52 bowser kernel: [ 1236.101271] DVB: TDA10023(0): tda10023_readreg: readreg error (reg == 0x03, ret == -1) Jul 11 12:29:53 bowser kernel: [ 1236.200557] DVB: TDA10023(0): tda10023_writereg, writereg error (reg == 0x03, val == 0x00, ret == -1) Using lspci I see the following: 01:05.0 Multimedia controller: Philips Semiconductors SAA7146 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: budget_av 01:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: budget_av This is not a PCI latency problem. You appear to be experiencing PCI bus errors. Read errors on the PCI bus return 0x and it looks like that's happening on your system: (rev ff) (prog-if ff) PCI bus error are usually caused by the PCI bridge chips on your motherboard being overwhelmed or by bus signals of marginal quality or, of course, by actually defective hardware. As something simple and easy to try, I would suggest: 1. Remove *all* your PCI cards 2. Blow the dust out of *all* the slots. 3. Reseat the cards. That will hopefully improve the signal quality on the bus. You may also want to test with only 1 video capture card installed at first. Regards, Andy Before the problem the lspci output looked like this: 01:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Device 1176 Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at faeffc00 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av 01:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Device 1176 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at faeff800 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av Searching on google I found something about adjusting pci-latencies to 64, I already tried that, but it didn't help. I updated the BIOS to the latest version, but that didn't help either. Any ideas? Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
problems with Terratec Cinergy 1200 DVB-C MK3 after mainboard switch
Hi, I use two Cinergy 1200 DVB-C MK3 for quite a long time and had no problems so far. Now I switched to a new mainboard (Asus m4n78 pro) and after some time, the dvb-c cards aren't usable anymore. This can be triggered by heavy IO. On both mainboards I use Ubuntu 9.04 with the same kernel version (2.6.28-13-generic, also tested with 2.6.28-14-server). While running vdr I see the following in syslog: Jul 11 12:29:52 bowser vdr: [4678] frontend 0 lost lock on channel 6, tp 121 Jul 11 12:29:52 bowser kernel: [ 1235.601266] DVB: TDA10023(0): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser vdr: [4682] frontend 1 lost lock on channel 40, tp 730 Jul 11 12:29:52 bowser kernel: [ 1235.631263] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1235.701265] DVB: TDA10023(0): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1235.741264] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1235.801262] tda10023: lock tuner fails Jul 11 12:29:52 bowser kernel: [ 1235.851263] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1235.951264] DVB: TDA10023(1): tda10023_readreg: readreg error (reg == 0x11, ret == -1) Jul 11 12:29:52 bowser kernel: [ 1236.001263] tda10023: unlock tuner fails Jul 11 12:29:52 bowser kernel: [ 1236.051271] tda10023: lock tuner fails Jul 11 12:29:52 bowser kernel: [ 1236.101271] DVB: TDA10023(0): tda10023_readreg: readreg error (reg == 0x03, ret == -1) Jul 11 12:29:53 bowser kernel: [ 1236.200557] DVB: TDA10023(0): tda10023_writereg, writereg error (reg == 0x03, val == 0x00, ret == -1) Using lspci I see the following: 01:05.0 Multimedia controller: Philips Semiconductors SAA7146 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: budget_av 01:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: budget_av Before the problem the lspci output looked like this: 01:06.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Device 1176 Flags: bus master, medium devsel, latency 32, IRQ 16 Memory at faeffc00 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av 01:07.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: TERRATEC Electronic GmbH Device 1176 Flags: bus master, medium devsel, latency 32, IRQ 19 Memory at faeff800 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av Searching on google I found something about adjusting pci-latencies to 64, I already tried that, but it didn't help. I updated the BIOS to the latest version, but that didn't help either. Any ideas? Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] problems with Terratec Cinergy 1200 DVB-C MK3 after mainboard switch
Hi Andy, You appear to be experiencing PCI bus errors. Read errors on the PCI bus return 0x and it looks like that's happening on your system: (rev ff) (prog-if ff) PCI bus error are usually caused by the PCI bridge chips on your motherboard being overwhelmed or by bus signals of marginal quality or, of course, by actually defective hardware. As something simple and easy to try, I would suggest: 1. Remove *all* your PCI cards 2. Blow the dust out of *all* the slots. 3. Reseat the cards. That will hopefully improve the signal quality on the bus. Ok, I cleaned the cards one more and atm there's only 1 card in the system. Blew out all dust (the motherboard arrived brand new yesterday, so probably not necessary), still the same probs. After heavy IO the card dies. I plugged one of the cards back in the old motherboard and installed a backup vdr, no probs at all with that card. Everything else on the new mainboard works like a charm, so I doubt the board is broken. Still looking for any other hints, Matthias -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ivtv-devel] Fwd: [UNKNOWN IVTV CARD] (cx23416) AverMedia M113-C
On Thu, 2009-07-09 at 20:32 -0400, Andy Walls wrote: On Thu, 2009-07-09 at 23:04 +0530, Ravi A wrote: On Wed, Jul 8, 2009 at 6:07 AM, Andy Wallsawa...@radix.net wrote: - Audio - it came up briefly, but missing again now. I may need to check all the other system settings for this one. Hmmm. You may want to try and capture the MPEG stream to a file: $ cat /dev/video0 foo.mpg and then playback the file on a machine with a known good sound setup to make sure the CX25841/CX23416 is capturing the sound properly. Also, set the driver to use a 48 ksps audio sample rate and not 32 ksps. The cx25840 module drives the CX2584x chip's audio PLL out of its valid operating range for 32 ksps audio. Most newer CX25843 chips don't seem to care being told to operate too slow, but the audio PLL in some CX2584x cores stop oscillating under that condition. I captured it using vlc and played back on a windows laptop :) The sound was too low and seemed very choppy (maybe not unlike that due to a PLL operating at the edge of its hold range!). You can notice it in the video clip I linked above. Although I did not explicitly set the sample rate, mplayer reported 48ksps for the captured stream. 48 ksps is the default. VLC might change it for the capture. When VLC, or any other app, is capturing, you can use v4l2-ctl -d /dev/video0 --log-status to see how the capture is configured. (v4l2 device nodes are multiple open.) I'll look into what I might be able to do in the CX25840 driver about fixing the PLL clocks. Ravi, I have added a change here: http://linuxtv.org/hg/~awalls/ivtv to the cx25840 module. The change ensures that the Video and Aux PLLs for CX2584x chips run close to 400 MHz, the center frequency of the VCOs. The change is essentially what the cx18 driver does for it's integrated A/V core. Please see if you get reliable audio with the CX25841 on your board with this change. Regards, Andy The volume is controllable with the controls available with v4l2-ctl. Regards, Andy Thanks! Ravi -- 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
Initial scan file for es-BaixoMinho es-Pontevedra
---BeginMessage--- Since there's no inital scan file for the Baixo Minho (Pontevedra - Spain) area here is my own file. This scan file might be also valid for the whole Pontevedra area but since Im not really sure of it I'll suggest naming it es-BaixoMinho #Initial scan file begining #-- # file automatically generated by w_scan # (http://wirbel.htpc-forum.de/w_scan/index2.html) #! w_scan 20090528 1 0 OFDM ES /w_scan #-- # location and provider: Baixo Minho, Pontevedra (Spain) # date (-mm-dd): 2009-07-11 # provided by (opt): neonm...@gmail.com # # T[2] freq bw fec_hi fec_lo mod tm guard hi [# comment] #-- T 69000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # SFN T 83400 8MHz 2/3 NONEQAM64 8k 1/4 NONE # SFN T 84200 8MHz 2/3 NONEQAM64 8k 1/4 NONE T 85000 8MHz 2/3 NONEQAM64 8k 1/4 NONE # SFN T 85800 8MHz 2/3 NONEQAM64 8k 1/4 NONE T 73800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO # SFN T 77000 8MHz 2/3 NONEQAM64 8k 1/4 NONE # RAR Pontevedra T 81000 8MHz 2/3 NONEQAM64 8k 1/4 NONE # RGE GALICIA #Initial scan file end ---End Message---
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Jul 11 19:00:06 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12232:9ed0cb074784 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 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.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc1-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-rc1-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.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc1-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc1-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: Short experiment with libudev to support media controller concept
On Sat, 2009-07-04 at 13:52 -0400, Andy Walls wrote: Hans, The inline source file at the end of this post is a small program I used to play with libudev to see if it would complement the media controller concept (as you suspected it would). Documentation on the libudev calls is here: http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/ The test program I wrote takes a (type,major,minor) tuple and lists the device node and device symlinks as fetched by libudev. My test setup was a little strange since libudev is no longer maintained separately but is bundled in with udev. On my Fedora 9 system I have udev v124 (Fedora 9 stock) and libudev v143 (custom built from the udev 143 source). Here's some output: $ ./finddev -c -M 81 -m 9 Requested device: type 'c', major 81, minor 9 Device directory path: '/dev' Device node: '/dev/video0' Device link: '/dev/video' $ ls -alR /dev/* | grep '[ /]video0' lrwxrwxrwx 1 root root 6 2009-07-04 08:34 /dev/video - video0 crw-rw+ 1 root root81, 9 2009-07-04 08:34 /dev/video0 (OK for video nodes) $ ./finddev -c -M 116 -m 6 Requested device: type 'c', major 116, minor 6 Device directory path: '/dev' Device node: '/dev/snd/pcmC0D0p' $ ls -alR /dev/* | grep '[ /]pcmC0D0p' crw-rw+ 1 root root 116, 6 2009-07-04 13:43 pcmC0D0p (OK for ALSA PCM stream nodes). Do you have any other particular questions about libudev's capabilities? OK, so more tests. Two Major groups: with udev still running and with udev not running (killed after I log in). Case 1: - udev running: - Adding a manual symlink # cd /dev # ln -s video0 mpeg0 Result: finddev using libudev doesn't find the manual symlink Case 2: - udev running - A manual mknod # cd /dev # mknod mpeg0 c 81 9 Result: finddev doesn't find the manually created device node Case 3: - same as case 2, but manually delete /dev/video0 Result: finddev reports /dev/video0 ! :( Case 4: - same as case 3 - add to 50-udev-default.rules: KERNEL==video[0-9]*, SYMLINK+=mpeg%n - Reload udev rules udevadm control --reload_rules udevadm trigger --subsystem-match=video4linux Result: findddev reports the new '/dev/mpeg0' symlink for /dev/video0 as well as the the '/dev/video' synmlink and the '/dev/video0' device node. :) Case 5: - same as case 3 - add to 50-udev-default.rules: KERNEL==video[0-9]*, NAME=mpeg%n - Reload udev rules udevadm control --reload_rules udevadm trigger --subsystem-match=video4linux Result: SELinux gripes at me because HAL is allowed to acces the attributes of /dev/mpeg*. :) finddev reports the new /dev/mpeg0 and the /dev/video symlink to it and they both exist in the filesystem. :) Case 6: - after case 5 - kill udevd. :) Result: finddev finds /dev/mpeg0 and the /dev/video symlink Case 7: - after case 6: - manually remove /dev/mpeg0 and /dev/video Result: finddev reports /dev/mpeg0 and the /dev/video symlink. :? Apparently libudev uses what's in the udev database and /sys but doesn't look in the /dev directory for manual actions, even when udevd is dead. Regards, Andy Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Short experiment with libudev to support media controller concept
On Saturday 11 July 2009 21:19:46 Andy Walls wrote: On Sat, 2009-07-04 at 13:52 -0400, Andy Walls wrote: Hans, The inline source file at the end of this post is a small program I used to play with libudev to see if it would complement the media controller concept (as you suspected it would). Documentation on the libudev calls is here: http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/ The test program I wrote takes a (type,major,minor) tuple and lists the device node and device symlinks as fetched by libudev. My test setup was a little strange since libudev is no longer maintained separately but is bundled in with udev. On my Fedora 9 system I have udev v124 (Fedora 9 stock) and libudev v143 (custom built from the udev 143 source). Here's some output: $ ./finddev -c -M 81 -m 9 Requested device: type 'c', major 81, minor 9 Device directory path: '/dev' Device node: '/dev/video0' Device link: '/dev/video' $ ls -alR /dev/* | grep '[ /]video0' lrwxrwxrwx 1 root root 6 2009-07-04 08:34 /dev/video - video0 crw-rw+ 1 root root81, 9 2009-07-04 08:34 /dev/video0 (OK for video nodes) $ ./finddev -c -M 116 -m 6 Requested device: type 'c', major 116, minor 6 Device directory path: '/dev' Device node: '/dev/snd/pcmC0D0p' $ ls -alR /dev/* | grep '[ /]pcmC0D0p' crw-rw+ 1 root root 116, 6 2009-07-04 13:43 pcmC0D0p (OK for ALSA PCM stream nodes). Do you have any other particular questions about libudev's capabilities? OK, so more tests. Two Major groups: with udev still running and with udev not running (killed after I log in). Case 1: - udev running: - Adding a manual symlink # cd /dev # ln -s video0 mpeg0 Result: finddev using libudev doesn't find the manual symlink Case 2: - udev running - A manual mknod # cd /dev # mknod mpeg0 c 81 9 Result: finddev doesn't find the manually created device node Case 3: - same as case 2, but manually delete /dev/video0 Result: finddev reports /dev/video0 ! :( That's not surprising as cases 1-3 by-pass udev, so libudev knows nothing about those changes. Case 4: - same as case 3 - add to 50-udev-default.rules: KERNEL==video[0-9]*, SYMLINK+=mpeg%n - Reload udev rules udevadm control --reload_rules udevadm trigger --subsystem-match=video4linux Result: findddev reports the new '/dev/mpeg0' symlink for /dev/video0 as well as the the '/dev/video' synmlink and the '/dev/video0' device node. :) Nice! Case 5: - same as case 3 - add to 50-udev-default.rules: KERNEL==video[0-9]*, NAME=mpeg%n - Reload udev rules udevadm control --reload_rules udevadm trigger --subsystem-match=video4linux Result: SELinux gripes at me because HAL is allowed to acces the attributes of /dev/mpeg*. :) finddev reports the new /dev/mpeg0 and the /dev/video symlink to it and they both exist in the filesystem. :) Nice again! Case 6: - after case 5 - kill udevd. :) Result: finddev finds /dev/mpeg0 and the /dev/video symlink Nice test :-) and nice result. Case 7: - after case 6: - manually remove /dev/mpeg0 and /dev/video Result: finddev reports /dev/mpeg0 and the /dev/video symlink. :? Similar to cases 1-3: you bypass udev so libudev won't know about it. Apparently libudev uses what's in the udev database and /sys but doesn't look in the /dev directory for manual actions, even when udevd is dead. That makes sense as udev is basically in charge of the /dev/ contents and making manual /dev/ changes while udev is running defeats the purpose of udev. I'm really happy finddev finds the symlinks as well. This means that the major and minor numbers are all that is needed in order to reliably find the right device nodes in /dev. Thanks! Hans Regards, Andy Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [PATCH] Implement V4L2_CAP_STREAMING for zr364xx driver
Hi guys. Any news about this patch? I really think is important to make zr364xx driver works with libv4l, mplayer, kopete and skype. Maintaining this patch out of tree is also troublesome for me, I would really appreciate if you could add it to the tree. If there is any problem with the patch let me know that will fix it. Em Thursday 02 July 2009, Lamarque Vieira Souza escreveu: Hi all, I have noticed the patch mentioned in the subject was not included in 2.6.30. Do you plan to add it to 2.6.31? Em Saturday 28 March 2009, Lamarque Vieira Souza escreveu: This patch implements V4L2_CAP_STREAMING for the zr364xx driver, by converting the driver to use videobuf. Tested with Creative PC-CAM 880. It basically: . implements V4L2_CAP_STREAMING using videobuf; . re-implements V4L2_CAP_READWRITE using videobuf; . copies cam-udev-product to the card field of the v4l2_capability struct. That gives more information to the users about the webcam; . moves the brightness setting code from before requesting a frame (in read_frame) to the vidioc_s_ctrl ioctl. This way the brightness code is executed only when the application requests a change in brightness and not before every frame read; . comments part of zr364xx_vidioc_try_fmt_vid_cap that says that Skype + libv4l do not work. This patch fixes zr364xx for applications such as mplayer, Kopete+libv4l and Skype+libv4l can make use of the webcam that comes with zr364xx chip. Signed-off-by: Lamarque V. Souza lamar...@gmail.com --- --- v4l-dvb/linux/drivers/media/video/zr364xx.c 2009-03-27 15:18:54.050413997 -0300 +++ v4l-dvb/linux-lvs/drivers/media/video/zr364xx.c 2009-03-27 15:22:47.914414277 -0300 ... stripped off to not bloat the e-mail. -- Lamarque V. Souza http://www.geographicguide.com/brazil.htm Linux User #57137 - http://counter.li.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: About v4l2 subdev s_config (for core) API?
2009/7/12 Hans Verkuil hverk...@xs4all.nl: On Saturday 11 July 2009 13:02:33 Dongsoo, Nathaniel Kim wrote: Hi, The thing is - Is it possible to make the subdev device not to be turned on in registering process using any of v4l2_i2c_new_subdev*** ? You can say that I can ignore the i2c errors in booting process, but I think it is not a pretty way. And for the reason I'm asking you about this, I need you to consider following conditions I carry. 1. ARM embedded platform especially mobile handset. 2. Mass production which is very concerned about power consumption. 3. Strict and automated test process in product line. So, what I want to ask you is about s_config subdev call which is called from every single I2C subdev load in some kind of probe procedure. As s_config is supposed to do, it tries to initialize subdev device. which means it needs to turn on the subdev to make that initialized. Actually, all s_config does is to pass the irq and platform_data arguments to the subdev driver. The subdev driver can just store that information somewhere and only use it when needed. It does not necessarily have to turn on the sub-device. Whether to just store this info or turn on the sub-device is something that each subdev driver writer has to decide. Note that this really has nothing to do with the existance of s_config: s_config was only introduced in order to support legacy v4l2 drivers and subdev drivers. In the (far?) future this will probably disappear and this information will always be passed via struct i2c_board_info. But as I mentioned above if we make the product go through the product line, it turns on the subdev device even though nobody intended to turn the subdev on. It might be an issue in product vendor's point of view, because there should be a crystal clear reason for the consumption of power the subdev made. I'm working on camera device and speaking of which, camera devices are really power consuming device and some camera devices even take ages to be initialized as well. So far I hope I made a good explanation about why I'm asking you about following question. By the way, it seems to be similar to the issue I've faced whe using old i2c driver model..I mean probing i2c devices on boot up sequence. That at least should no longer be a problem anymore (as long as you don't use the address-probing variants). Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Hello Hans, I just needed an API for initializing soc camera device ;-( but after reading your mail, it seems to be that I'm using a wrong API. As you know, almost every cmos camera module needs to be programmed through I2C(or SPI) when it is turned on to be initialized. And I thought that s_config is the one which could be used. If I'm getting wrong, which one can I use for that initialization purpose? I referenced every v4l2 device driver in linuxtv repository and cherry-picked the API in my own way. Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
