Re: ngene Satix-S2 dual problems
On 20 Nov 2010, at 19:22, Oliver Endriss wrote: Hi, On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote: Hi all, I have a Satix-S2 Dual that I'm trying to get to work properly so that I can use it under MythTv however I'm running into a few issues. I previously posted about the problems I'm having here to the mythtv list[1], but didn't really get anywhere. I've had chance to have a bit more of a play and I now seem to have a definite repeatable problem. The problem is when a recording stops on one of the inputs, after about 40s it causes the other input to loose it's signal lock and stop the recording as well. Steps to demonstrate the problem (My Satix card is adapters 5 and 6) In 3 seperate terminals set up femon/szap/cat to make a recording from one of the inputs: 1 - femon -a 6 -f 0 -H 2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL BBC 1 London 3 - cat /dev/dvb/adapter6/dvr0 ad6.mpg In 2 seperate terminals tune in the other input: 4 - femon -a 5 -f 0 -H 5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL ITV1 London Both inputs are fine, signal is good, recording from adapter 6 works. 6 - Ctrl-C the szap process created in (5). femon in (4) still reports status=SCVYL and decent signal strengh as if the adapter is still tuned and FE_HAS_LOCK. After approximately 40 seconds, either: a) the signal drops significantly but the status remains at SCVYL and FE_HAS_LOCK or b) the signal drops and the status goes blank with no lock. It doesn't seem to matter which of these two happen, but at the same time the recording on the other tuner looses it signal and stops recording, despite the fact that szap is still running in (2). femon in (1) no longer reports FE_HAS_LOCK. Strangely if I then try to restart the szap process created in terminal 2 (to try and retune it) it just waits after printing out using '/dev/dvb/. However if I then restart the szap process in terminal 5, the one in terminal 2 suddenly kicks in and gets a lock. Interestingly I found a link describing a 60s period the card is kept open for [2], which seems to be similar to my ~40s delay. So it looks like when the second input on the card is closed the first input looses it's lock. This obviously makes it pretty useless for MythTv and as a result it's not currently being used, which is a shame! I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo. Does anyone else see this problem? Is there anything I can do to try and fix / debug it? Are there any bug fixes in the latest kernel that might help, or in the linux-dvb drivers that would help? Any help or advice much appreciated. Please try this driver: http://linuxtv.org/hg/~endriss/ngene-test2 Great news, I'll give it a try this evening too. Andre CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: ngene Satix-S2 dual problems
On 20 Nov 2010, at 19:22, Oliver Endriss wrote: Hi, On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote: Hi all, I have a Satix-S2 Dual that I'm trying to get to work properly so that I can use it under MythTv however I'm running into a few issues. I previously posted about the problems I'm having here to the mythtv list[1], but didn't really get anywhere. I've had chance to have a bit more of a play and I now seem to have a definite repeatable problem. The problem is when a recording stops on one of the inputs, after about 40s it causes the other input to loose it's signal lock and stop the recording as well. Steps to demonstrate the problem (My Satix card is adapters 5 and 6) In 3 seperate terminals set up femon/szap/cat to make a recording from one of the inputs: 1 - femon -a 6 -f 0 -H 2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL BBC 1 London 3 - cat /dev/dvb/adapter6/dvr0 ad6.mpg In 2 seperate terminals tune in the other input: 4 - femon -a 5 -f 0 -H 5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL ITV1 London Both inputs are fine, signal is good, recording from adapter 6 works. 6 - Ctrl-C the szap process created in (5). femon in (4) still reports status=SCVYL and decent signal strengh as if the adapter is still tuned and FE_HAS_LOCK. After approximately 40 seconds, either: a) the signal drops significantly but the status remains at SCVYL and FE_HAS_LOCK or b) the signal drops and the status goes blank with no lock. It doesn't seem to matter which of these two happen, but at the same time the recording on the other tuner looses it signal and stops recording, despite the fact that szap is still running in (2). femon in (1) no longer reports FE_HAS_LOCK. Strangely if I then try to restart the szap process created in terminal 2 (to try and retune it) it just waits after printing out using '/dev/dvb/. However if I then restart the szap process in terminal 5, the one in terminal 2 suddenly kicks in and gets a lock. Interestingly I found a link describing a 60s period the card is kept open for [2], which seems to be similar to my ~40s delay. So it looks like when the second input on the card is closed the first input looses it's lock. This obviously makes it pretty useless for MythTv and as a result it's not currently being used, which is a shame! I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo. Does anyone else see this problem? Is there anything I can do to try and fix / debug it? Are there any bug fixes in the latest kernel that might help, or in the linux-dvb drivers that would help? Any help or advice much appreciated. Please try this driver: http://linuxtv.org/hg/~endriss/ngene-test2 Well that's progress, trying Robert's procedure fails with my stock driver (Ubuntu 10.10's 2.6.35-22-generic) but recording continues with your ngene-test2 driver :-) NB I needed to go grab ngene_18.fw before it would work and I have three unexpected extra frontends, adapter 0,12 as well as the configured 56, not sure what's going on there yet! There's a ber bump on the other tuner when you retune but it carries on which is the main thing at this stage. Can see glitches at the corresponding spot in the recording but worth a try with Myth perhaps? I've been running with only one of the tuners for months, perhaps best to switch off active eit collection though looking at that ber bump. Great stuff Oliver. Andre CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: ngene Satix-S2 dual problems
On 21 Nov 2010, at 11:40 AM, Andre linux-me...@dinkum.org.uk wrote: On 20 Nov 2010, at 19:22, Oliver Endriss wrote: Hi, On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote: Hi all, I have a Satix-S2 Dual that I'm trying to get to work properly so that I can use it under MythTv however I'm running into a few issues. I previously posted about the problems I'm having here to the mythtv list[1], but didn't really get anywhere. I've had chance to have a bit more of a play and I now seem to have a definite repeatable problem. The problem is when a recording stops on one of the inputs, after about 40s it causes the other input to loose it's signal lock and stop the recording as well. Steps to demonstrate the problem (My Satix card is adapters 5 and 6) In 3 seperate terminals set up femon/szap/cat to make a recording from one of the inputs: 1 - femon -a 6 -f 0 -H 2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL BBC 1 London 3 - cat /dev/dvb/adapter6/dvr0 ad6.mpg In 2 seperate terminals tune in the other input: 4 - femon -a 5 -f 0 -H 5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL ITV1 London Both inputs are fine, signal is good, recording from adapter 6 works. 6 - Ctrl-C the szap process created in (5). femon in (4) still reports status=SCVYL and decent signal strengh as if the adapter is still tuned and FE_HAS_LOCK. After approximately 40 seconds, either: a) the signal drops significantly but the status remains at SCVYL and FE_HAS_LOCK or b) the signal drops and the status goes blank with no lock. It doesn't seem to matter which of these two happen, but at the same time the recording on the other tuner looses it signal and stops recording, despite the fact that szap is still running in (2). femon in (1) no longer reports FE_HAS_LOCK. Strangely if I then try to restart the szap process created in terminal 2 (to try and retune it) it just waits after printing out using '/dev/dvb/. However if I then restart the szap process in terminal 5, the one in terminal 2 suddenly kicks in and gets a lock. Interestingly I found a link describing a 60s period the card is kept open for [2], which seems to be similar to my ~40s delay. So it looks like when the second input on the card is closed the first input looses it's lock. This obviously makes it pretty useless for MythTv and as a result it's not currently being used, which is a shame! I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo. Does anyone else see this problem? Is there anything I can do to try and fix / debug it? Are there any bug fixes in the latest kernel that might help, or in the linux-dvb drivers that would help? Any help or advice much appreciated. Please try this driver: http://linuxtv.org/hg/~endriss/ngene-test2 Well that's progress, trying Robert's procedure fails with my stock driver (Ubuntu 10.10's 2.6.35-22-generic) but recording continues with your ngene-test2 driver :-) NB I needed to go grab ngene_18.fw before it would work and I have three unexpected extra frontends, adapter 0,12 as well as the configured 56, not sure what's going on there yet! There's a ber bump on the other tuner when you retune but it carries on which is the main thing at this stage. Can see glitches at the corresponding spot in the recording but worth a try with Myth perhaps? I've been running with only one of the tuners for months, perhaps best to switch off active eit collection though looking at that ber bump. Great stuff Oliver. Andre That does sound like good news, I'll try and give it a go later today now that I have a process to test with. If it does appear to have fixed it then I'll switch myth over to using it later next week and see how it gets on. Will report back with the results later. Robert. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: ngene Satix-S2 dual problems
On 21 Nov 2010, at 13:07, Robert Longbottom wrote: On 21 Nov 2010, at 11:40 AM, Andre linux-me...@dinkum.org.uk wrote: On 20 Nov 2010, at 19:22, Oliver Endriss wrote: Hi, On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote: Hi all, I have a Satix-S2 Dual that I'm trying to get to work properly so that I can use it under MythTv however I'm running into a few issues. I previously posted about the problems I'm having here to the mythtv list[1], but didn't really get anywhere. I've had chance to have a bit more of a play and I now seem to have a definite repeatable problem. The problem is when a recording stops on one of the inputs, after about 40s it causes the other input to loose it's signal lock and stop the recording as well. Steps to demonstrate the problem (My Satix card is adapters 5 and 6) In 3 seperate terminals set up femon/szap/cat to make a recording from one of the inputs: 1 - femon -a 6 -f 0 -H 2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL BBC 1 London 3 - cat /dev/dvb/adapter6/dvr0 ad6.mpg In 2 seperate terminals tune in the other input: 4 - femon -a 5 -f 0 -H 5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL ITV1 London Both inputs are fine, signal is good, recording from adapter 6 works. 6 - Ctrl-C the szap process created in (5). femon in (4) still reports status=SCVYL and decent signal strengh as if the adapter is still tuned and FE_HAS_LOCK. After approximately 40 seconds, either: a) the signal drops significantly but the status remains at SCVYL and FE_HAS_LOCK or b) the signal drops and the status goes blank with no lock. It doesn't seem to matter which of these two happen, but at the same time the recording on the other tuner looses it signal and stops recording, despite the fact that szap is still running in (2). femon in (1) no longer reports FE_HAS_LOCK. Strangely if I then try to restart the szap process created in terminal 2 (to try and retune it) it just waits after printing out using '/dev/dvb/. However if I then restart the szap process in terminal 5, the one in terminal 2 suddenly kicks in and gets a lock. Interestingly I found a link describing a 60s period the card is kept open for [2], which seems to be similar to my ~40s delay. So it looks like when the second input on the card is closed the first input looses it's lock. This obviously makes it pretty useless for MythTv and as a result it's not currently being used, which is a shame! I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo. Does anyone else see this problem? Is there anything I can do to try and fix / debug it? Are there any bug fixes in the latest kernel that might help, or in the linux-dvb drivers that would help? Any help or advice much appreciated. Please try this driver: http://linuxtv.org/hg/~endriss/ngene-test2 Well that's progress, trying Robert's procedure fails with my stock driver (Ubuntu 10.10's 2.6.35-22-generic) but recording continues with your ngene-test2 driver :-) NB I needed to go grab ngene_18.fw before it would work and I have three unexpected extra frontends, adapter 0,12 as well as the configured 56, not sure what's going on there yet! There's a ber bump on the other tuner when you retune but it carries on which is the main thing at this stage. Can see glitches at the corresponding spot in the recording but worth a try with Myth perhaps? I've been running with only one of the tuners for months, perhaps best to switch off active eit collection though looking at that ber bump. Great stuff Oliver. Andre That does sound like good news, I'll try and give it a go later today now that I have a process to test with. If it does appear to have fixed it then I'll switch myth over to using it later next week and see how it gets on. I tried it with Myth 0.24 and just got six simultaneous HD recordings out of it :-)) total seven if you count the one I started to keep the HD-S2 card busy, can't try any more with that sat and my sub. No glitches I can see, tried it a couple of times with different muxes, so far so good. Will report back with the results later. You can have your thread back now ;-) Andre Robert. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media
Re: For those that uses Pinnacle PCTV 340e
Tried your code today and it works slightly better since the tuner still works after a reboot. The remote stops working tho. I get this in dmesg: dib0700: rc submit urb failed. Can't say I notice any difference on how warm it becomes tho. /Magnus Alm Thank you for trying the patch. The patch is just a quick and simple patch, to make xc4000 works with linux 2.6.35, and I only just want to make sure the DVB feature is up and running. I remembered that Devin had said something about RC polling, which make the 'load' getting high (1.00) eventhough the system proccesses are in idle or sleeping. In my case, the PCTV 340e dongle is cooler when it is in idle; ie, not streaming to the host; compared to the original xc4000 driver. One more thing is, the SNR, signal strength, ... are quite not reported correctly. if you use 'femon -H'. I really hope other experienced developers can take a look into the code, and make it better compability with current kernel. :) Thank you very much. -- 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: New initial DVB-T tuning for Tours (France)
2010/11/6 Alexandre LISSY lis...@lissyx.dyndns.org: Hello, A couple of weeks ago, the transponder for Tours in Chissay (Loir-et-Cher, 41) has been updated and new frequencies are used. Consequently, the initial DVB-T tuning informations used by many software (dvb-apps, kaffeine, etc.) are now unusable for people depending on this transponder. Attached is an updated file (fr-Tours) I just generated with the new values. A sample channels.conf, channels.tmp.conf, is also attached for information. This one has been generated using the fr-Tours provided. Updated, thanks. Christoph -- 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
Problem with HVR 900 (B2C0) and USB detection
Hi I have been using this device for years using Markuses Driver. Now for some bizarre reason using both this driver and devins the wrong USB driver is being used (ohci rather than ehci), which means it is recognised as a USB 1.1 device, which makes it stop working Anyone know if there is any way to force it to use USB 2 Other usb devices use the correct usb speed thanks -- 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: ngene Satix-S2 dual problems
On 21/11/2010 13:15, Andre wrote: On 21 Nov 2010, at 13:07, Robert Longbottom wrote: On 21 Nov 2010, at 11:40 AM, Andrelinux-me...@dinkum.org.uk wrote: On 20 Nov 2010, at 19:22, Oliver Endriss wrote: Hi, On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote: Hi all, I have a Satix-S2 Dual that I'm trying to get to work properly so that I can use it under MythTv however I'm running into a few issues. I previously posted about the problems I'm having here to the mythtv list[1], but didn't really get anywhere. I've had chance to have a bit more of a play and I now seem to have a definite repeatable problem. The problem is when a recording stops on one of the inputs, after about 40s it causes the other input to loose it's signal lock and stop the recording as well. Steps to demonstrate the problem (My Satix card is adapters 5 and 6) In 3 seperate terminals set up femon/szap/cat to make a recording from one of the inputs: 1 - femon -a 6 -f 0 -H 2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL BBC 1 London 3 - cat /dev/dvb/adapter6/dvr0 ad6.mpg In 2 seperate terminals tune in the other input: 4 - femon -a 5 -f 0 -H 5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL ITV1 London Both inputs are fine, signal is good, recording from adapter 6 works. 6 - Ctrl-C the szap process created in (5). femon in (4) still reports status=SCVYL and decent signal strengh as if the adapter is still tuned and FE_HAS_LOCK. After approximately 40 seconds, either: a) the signal drops significantly but the status remains at SCVYL and FE_HAS_LOCK or b) the signal drops and the status goes blank with no lock. It doesn't seem to matter which of these two happen, but at the same time the recording on the other tuner looses it signal and stops recording, despite the fact that szap is still running in (2). femon in (1) no longer reports FE_HAS_LOCK. Strangely if I then try to restart the szap process created in terminal 2 (to try and retune it) it just waits after printing out using '/dev/dvb/. However if I then restart the szap process in terminal 5, the one in terminal 2 suddenly kicks in and gets a lock. Interestingly I found a link describing a 60s period the card is kept open for [2], which seems to be similar to my ~40s delay. So it looks like when the second input on the card is closed the first input looses it's lock. This obviously makes it pretty useless for MythTv and as a result it's not currently being used, which is a shame! I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo. Does anyone else see this problem? Is there anything I can do to try and fix / debug it? Are there any bug fixes in the latest kernel that might help, or in the linux-dvb drivers that would help? Any help or advice much appreciated. Please try this driver: http://linuxtv.org/hg/~endriss/ngene-test2 Well that's progress, trying Robert's procedure fails with my stock driver (Ubuntu 10.10's 2.6.35-22-generic) but recording continues with your ngene-test2 driver :-) NB I needed to go grab ngene_18.fw before it would work and I have three unexpected extra frontends, adapter 0,12 as well as the configured 56, not sure what's going on there yet! There's a ber bump on the other tuner when you retune but it carries on which is the main thing at this stage. Can see glitches at the corresponding spot in the recording but worth a try with Myth perhaps? I've been running with only one of the tuners for months, perhaps best to switch off active eit collection though looking at that ber bump. Great stuff Oliver. Andre That does sound like good news, I'll try and give it a go later today now that I have a process to test with. If it does appear to have fixed it then I'll switch myth over to using it later next week and see how it gets on. I tried it with Myth 0.24 and just got six simultaneous HD recordings out of it :-)) total seven if you count the one I started to keep the HD-S2 card busy, can't try any more with that sat and my sub. No glitches I can see, tried it a couple of times with different muxes, so far so good. Will report back with the results later. You can have your thread back now ;-) Thanks ;-) The more people that test this and iron out the bugs the better :-) I've run through my procedure again using the ngene-test2 drivers from Oliver and I can report success as well. I too see a glitch on the 2nd tuner when you retune the 1st, or after about 30s from killing an szap against the 1st, but the stream on the second tuner continues, so thats a massive improvement. Good work. I'll give it a quick go with MythTV as well tonight, and later next week. Previously when I tried this tuner with MythTV it would record upto 6 streams with no problem, but of couse when one tuner dropped out of use the streams using the other tuner would stop recording (but I didn't know why at the time). I
Problem with Compro T200 (TDA1004x) and tuning Hi
I am trying to tune channels with this card (which seems to be installed OK). However the output is Using DVB card Philips TDA10046H DVB-T tuning DVB-T (in United Kingdom) to 497833000 Hz polling Getting frontend event FE_STATUS: polling polling polling etc,etc -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
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:Sun Nov 21 19:00:13 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene Satix-S2 dual problems
On 21 Nov 2010, at 17:23, Robert Longbottom wrote: On 21/11/2010 13:15, Andre wrote: On 21 Nov 2010, at 13:07, Robert Longbottom wrote: On 21 Nov 2010, at 11:40 AM, Andrelinux-me...@dinkum.org.uk wrote: On 20 Nov 2010, at 19:22, Oliver Endriss wrote: Hi, On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote: Hi all, I have a Satix-S2 Dual that I'm trying to get to work properly so that I can use it under MythTv however I'm running into a few issues. I previously posted about the problems I'm having here to the mythtv list[1], but didn't really get anywhere. I've had chance to have a bit more of a play and I now seem to have a definite repeatable problem. The problem is when a recording stops on one of the inputs, after about 40s it causes the other input to loose it's signal lock and stop the recording as well. Steps to demonstrate the problem (My Satix card is adapters 5 and 6) In 3 seperate terminals set up femon/szap/cat to make a recording from one of the inputs: 1 - femon -a 6 -f 0 -H 2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL BBC 1 London 3 - cat /dev/dvb/adapter6/dvr0 ad6.mpg In 2 seperate terminals tune in the other input: 4 - femon -a 5 -f 0 -H 5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL ITV1 London Both inputs are fine, signal is good, recording from adapter 6 works. 6 - Ctrl-C the szap process created in (5). femon in (4) still reports status=SCVYL and decent signal strengh as if the adapter is still tuned and FE_HAS_LOCK. After approximately 40 seconds, either: a) the signal drops significantly but the status remains at SCVYL and FE_HAS_LOCK or b) the signal drops and the status goes blank with no lock. It doesn't seem to matter which of these two happen, but at the same time the recording on the other tuner looses it signal and stops recording, despite the fact that szap is still running in (2). femon in (1) no longer reports FE_HAS_LOCK. Strangely if I then try to restart the szap process created in terminal 2 (to try and retune it) it just waits after printing out using '/dev/dvb/. However if I then restart the szap process in terminal 5, the one in terminal 2 suddenly kicks in and gets a lock. Interestingly I found a link describing a 60s period the card is kept open for [2], which seems to be similar to my ~40s delay. So it looks like when the second input on the card is closed the first input looses it's lock. This obviously makes it pretty useless for MythTv and as a result it's not currently being used, which is a shame! I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo. Does anyone else see this problem? Is there anything I can do to try and fix / debug it? Are there any bug fixes in the latest kernel that might help, or in the linux-dvb drivers that would help? Any help or advice much appreciated. Please try this driver: http://linuxtv.org/hg/~endriss/ngene-test2 Well that's progress, trying Robert's procedure fails with my stock driver (Ubuntu 10.10's 2.6.35-22-generic) but recording continues with your ngene-test2 driver :-) NB I needed to go grab ngene_18.fw before it would work and I have three unexpected extra frontends, adapter 0,12 as well as the configured 56, not sure what's going on there yet! There's a ber bump on the other tuner when you retune but it carries on which is the main thing at this stage. Can see glitches at the corresponding spot in the recording but worth a try with Myth perhaps? I've been running with only one of the tuners for months, perhaps best to switch off active eit collection though looking at that ber bump. Great stuff Oliver. Andre That does sound like good news, I'll try and give it a go later today now that I have a process to test with. If it does appear to have fixed it then I'll switch myth over to using it later next week and see how it gets on. I tried it with Myth 0.24 and just got six simultaneous HD recordings out of it :-)) total seven if you count the one I started to keep the HD-S2 card busy, can't try any more with that sat and my sub. No glitches I can see, tried it a couple of times with different muxes, so far so good. Will report back with the results later. You can have your thread back now ;-) Thanks ;-) The more people that test this and iron out the bugs the better :-) I've got an email monitor looking for any mention of the ngene in here, mythtv, hts vdr lists so I can see if there is any activity, looking for just this kind of email :-) I've run through my procedure again using the ngene-test2 drivers from Oliver and I can report success as well. I too see a glitch on the 2nd tuner when you retune the 1st, or after about 30s from killing an szap against the 1st, but the stream on the second tuner continues, so thats a massive
Re: ngene Satix-S2 dual problems
On 21/11/2010 19:23, Andre wrote: On 21 Nov 2010, at 17:23, Robert Longbottom wrote: On 21/11/2010 13:15, Andre wrote: On 21 Nov 2010, at 13:07, Robert Longbottom wrote: On 21 Nov 2010, at 11:40 AM, Andrelinux-me...@dinkum.org.uk wrote: On 20 Nov 2010, at 19:22, Oliver Endriss wrote: Hi, On Saturday 20 November 2010 16:52:34 Robert Longbottom wrote: Hi all, I have a Satix-S2 Dual that I'm trying to get to work properly so that I can use it under MythTv however I'm running into a few issues. I previously posted about the problems I'm having here to the mythtv list[1], but didn't really get anywhere. I've had chance to have a bit more of a play and I now seem to have a definite repeatable problem. The problem is when a recording stops on one of the inputs, after about 40s it causes the other input to loose it's signal lock and stop the recording as well. Steps to demonstrate the problem (My Satix card is adapters 5 and 6) In 3 seperate terminals set up femon/szap/cat to make a recording from one of the inputs: 1 - femon -a 6 -f 0 -H 2 - szap -a 6 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL BBC 1 London 3 - cat /dev/dvb/adapter6/dvr0 ad6.mpg In 2 seperate terminals tune in the other input: 4 - femon -a 5 -f 0 -H 5 - szap -a 5 -f 0 -d 0 -r -H -p -c scanResult07Oct2010_Satix -l UNIVERSAL ITV1 London Both inputs are fine, signal is good, recording from adapter 6 works. 6 - Ctrl-C the szap process created in (5). femon in (4) still reports status=SCVYL and decent signal strengh as if the adapter is still tuned and FE_HAS_LOCK. After approximately 40 seconds, either: a) the signal drops significantly but the status remains at SCVYL and FE_HAS_LOCK or b) the signal drops and the status goes blank with no lock. It doesn't seem to matter which of these two happen, but at the same time the recording on the other tuner looses it signal and stops recording, despite the fact that szap is still running in (2). femon in (1) no longer reports FE_HAS_LOCK. Strangely if I then try to restart the szap process created in terminal 2 (to try and retune it) it just waits after printing out using '/dev/dvb/. However if I then restart the szap process in terminal 5, the one in terminal 2 suddenly kicks in and gets a lock. Interestingly I found a link describing a 60s period the card is kept open for [2], which seems to be similar to my ~40s delay. So it looks like when the second input on the card is closed the first input looses it's lock. This obviously makes it pretty useless for MythTv and as a result it's not currently being used, which is a shame! I'm using the ngene driver from the stock 2.6.35.4 kernel on Gentoo. Does anyone else see this problem? Is there anything I can do to try and fix / debug it? Are there any bug fixes in the latest kernel that might help, or in the linux-dvb drivers that would help? Any help or advice much appreciated. Please try this driver: http://linuxtv.org/hg/~endriss/ngene-test2 Well that's progress, trying Robert's procedure fails with my stock driver (Ubuntu 10.10's 2.6.35-22-generic) but recording continues with your ngene-test2 driver :-) NB I needed to go grab ngene_18.fw before it would work and I have three unexpected extra frontends, adapter 0,12 as well as the configured 56, not sure what's going on there yet! There's a ber bump on the other tuner when you retune but it carries on which is the main thing at this stage. Can see glitches at the corresponding spot in the recording but worth a try with Myth perhaps? I've been running with only one of the tuners for months, perhaps best to switch off active eit collection though looking at that ber bump. Great stuff Oliver. Andre That does sound like good news, I'll try and give it a go later today now that I have a process to test with. If it does appear to have fixed it then I'll switch myth over to using it later next week and see how it gets on. I tried it with Myth 0.24 and just got six simultaneous HD recordings out of it :-)) total seven if you count the one I started to keep the HD-S2 card busy, can't try any more with that sat and my sub. No glitches I can see, tried it a couple of times with different muxes, so far so good. Will report back with the results later. You can have your thread back now ;-) Thanks ;-) The more people that test this and iron out the bugs the better :-) I've got an email monitor looking for any mention of the ngene in here, mythtv, hts vdr lists so I can see if there is any activity, looking for just this kind of email :-) Ah, neat :-) I've run through my procedure again using the ngene-test2 drivers from Oliver and I can report success as well. I too see a glitch on the 2nd tuner when you retune the 1st, or after about 30s from killing an szap against the 1st, but the stream on the second tuner continues, so thats a massive improvement. Good work. I'll give it a quick go with MythTV
[PATCH 0/5] [FOR 2.6.37] uvcvideo: BKL removal
Hi everybody, Here are 5 patches to the uvcvideo driver that implements proper locking where it was missing and switch from ioctl to unlocked_ioctl, getting rid of the BKL. As locking can be tricky, patch review would be appreciated. Laurent Pinchart (5): uvcvideo: Lock controls mutex when querying menus uvcvideo: Move mutex lock/unlock inside uvc_free_buffers uvcvideo: Move mmap() handler to uvc_queue.c uvcvideo: Lock stream mutex when accessing format-related information uvcvideo: Convert to unlocked_ioctl drivers/media/video/uvc/uvc_ctrl.c | 48 +- drivers/media/video/uvc/uvc_queue.c | 133 +- drivers/media/video/uvc/uvc_v4l2.c | 183 +++ drivers/media/video/uvc/uvc_video.c |3 - drivers/media/video/uvc/uvcvideo.h | 10 ++- 5 files changed, 221 insertions(+), 156 deletions(-) -- 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
[PATCH 1/5] uvcvideo: Lock controls mutex when querying menus
uvc_find_control() must be called with the controls mutex locked. Fix
uvc_query_v4l2_menu() accordingly.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_ctrl.c | 48 +++-
drivers/media/video/uvc/uvc_v4l2.c | 36 +--
drivers/media/video/uvc/uvcvideo.h |4 +-
3 files changed, 50 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index f169f77..59f8a9a 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -785,7 +785,7 @@ static void __uvc_find_control(struct uvc_entity *entity,
__u32 v4l2_id,
}
}
-struct uvc_control *uvc_find_control(struct uvc_video_chain *chain,
+static struct uvc_control *uvc_find_control(struct uvc_video_chain *chain,
__u32 v4l2_id, struct uvc_control_mapping **mapping)
{
struct uvc_control *ctrl = NULL;
@@ -944,6 +944,52 @@ done:
return ret;
}
+/*
+ * Mapping V4L2 controls to UVC controls can be straighforward if done well.
+ * Most of the UVC controls exist in V4L2, and can be mapped directly. Some
+ * must be grouped (for instance the Red Balance, Blue Balance and Do White
+ * Balance V4L2 controls use the White Balance Component UVC control) or
+ * otherwise translated. The approach we take here is to use a translation
+ * table for the controls that can be mapped directly, and handle the others
+ * manually.
+ */
+int uvc_query_v4l2_menu(struct uvc_video_chain *chain,
+ struct v4l2_querymenu *query_menu)
+{
+ struct uvc_menu_info *menu_info;
+ struct uvc_control_mapping *mapping;
+ struct uvc_control *ctrl;
+ u32 index = query_menu-index;
+ u32 id = query_menu-id;
+ int ret;
+
+ memset(query_menu, 0, sizeof(*query_menu));
+ query_menu-id = id;
+ query_menu-index = index;
+
+ ret = mutex_lock_interruptible(chain-ctrl_mutex);
+ if (ret 0)
+ return -ERESTARTSYS;
+
+ ctrl = uvc_find_control(chain, query_menu-id, mapping);
+ if (ctrl == NULL || mapping-v4l2_type != V4L2_CTRL_TYPE_MENU) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ if (query_menu-index = mapping-menu_count) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ menu_info = mapping-menu_info[query_menu-index];
+ strlcpy(query_menu-name, menu_info-name, sizeof query_menu-name);
+
+done:
+ mutex_unlock(chain-ctrl_mutex);
+ return ret;
+}
+
/* --
* Control transactions
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index 6d15de9..0f865e9 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -101,40 +101,6 @@ done:
*/
/*
- * Mapping V4L2 controls to UVC controls can be straighforward if done well.
- * Most of the UVC controls exist in V4L2, and can be mapped directly. Some
- * must be grouped (for instance the Red Balance, Blue Balance and Do White
- * Balance V4L2 controls use the White Balance Component UVC control) or
- * otherwise translated. The approach we take here is to use a translation
- * table for the controls that can be mapped directly, and handle the others
- * manually.
- */
-static int uvc_v4l2_query_menu(struct uvc_video_chain *chain,
- struct v4l2_querymenu *query_menu)
-{
- struct uvc_menu_info *menu_info;
- struct uvc_control_mapping *mapping;
- struct uvc_control *ctrl;
- u32 index = query_menu-index;
- u32 id = query_menu-id;
-
- ctrl = uvc_find_control(chain, query_menu-id, mapping);
- if (ctrl == NULL || mapping-v4l2_type != V4L2_CTRL_TYPE_MENU)
- return -EINVAL;
-
- if (query_menu-index = mapping-menu_count)
- return -EINVAL;
-
- memset(query_menu, 0, sizeof(*query_menu));
- query_menu-id = id;
- query_menu-index = index;
-
- menu_info = mapping-menu_info[query_menu-index];
- strlcpy(query_menu-name, menu_info-name, sizeof query_menu-name);
- return 0;
-}
-
-/*
* Find the frame interval closest to the requested frame interval for the
* given frame format and size. This should be done by the device as part of
* the Video Probe and Commit negotiation, but some hardware don't implement
@@ -624,7 +590,7 @@ static long uvc_v4l2_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
}
case VIDIOC_QUERYMENU:
- return uvc_v4l2_query_menu(chain, arg);
+ return uvc_query_v4l2_menu(chain, arg);
case VIDIOC_G_EXT_CTRLS:
{
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index d97cf6d..4520924 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -606,10 +606,10 @@
[PATCH 2/5] uvcvideo: Move mutex lock/unlock inside uvc_free_buffers
Callers outside uvc_queue.c should not be forced to lock/unlock the
queue mutex manually. Move the mutex operations inside
uvc_free_buffers().
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_queue.c | 57 +--
drivers/media/video/uvc/uvc_v4l2.c |2 -
2 files changed, 34 insertions(+), 25 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c
index ed6d544..32c1822 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -90,6 +90,39 @@ void uvc_queue_init(struct uvc_video_queue *queue, enum
v4l2_buf_type type,
}
/*
+ * Free the video buffers.
+ *
+ * This function must be called with the queue lock held.
+ */
+static int __uvc_free_buffers(struct uvc_video_queue *queue)
+{
+ unsigned int i;
+
+ for (i = 0; i queue-count; ++i) {
+ if (queue-buffer[i].vma_use_count != 0)
+ return -EBUSY;
+ }
+
+ if (queue-count) {
+ vfree(queue-mem);
+ queue-count = 0;
+ }
+
+ return 0;
+}
+
+int uvc_free_buffers(struct uvc_video_queue *queue)
+{
+ int ret;
+
+ mutex_lock(queue-mutex);
+ ret = __uvc_free_buffers(queue);
+ mutex_unlock(queue-mutex);
+
+ return ret;
+}
+
+/*
* Allocate the video buffers.
*
* Pages are reserved to make sure they will not be swapped, as they will be
@@ -110,7 +143,7 @@ int uvc_alloc_buffers(struct uvc_video_queue *queue,
unsigned int nbuffers,
mutex_lock(queue-mutex);
- if ((ret = uvc_free_buffers(queue)) 0)
+ if ((ret = __uvc_free_buffers(queue)) 0)
goto done;
/* Bail out if no buffers should be allocated. */
@@ -152,28 +185,6 @@ done:
}
/*
- * Free the video buffers.
- *
- * This function must be called with the queue lock held.
- */
-int uvc_free_buffers(struct uvc_video_queue *queue)
-{
- unsigned int i;
-
- for (i = 0; i queue-count; ++i) {
- if (queue-buffer[i].vma_use_count != 0)
- return -EBUSY;
- }
-
- if (queue-count) {
- vfree(queue-mem);
- queue-count = 0;
- }
-
- return 0;
-}
-
-/*
* Check if buffers have been allocated.
*/
int uvc_queue_allocated(struct uvc_video_queue *queue)
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index 0f865e9..0fd9848b 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -494,11 +494,9 @@ static int uvc_v4l2_release(struct file *file)
if (uvc_has_privileges(handle)) {
uvc_video_enable(stream, 0);
- mutex_lock(stream-queue.mutex);
if (uvc_free_buffers(stream-queue) 0)
uvc_printk(KERN_ERR, uvc_v4l2_release: Unable to
free buffers.\n);
- mutex_unlock(stream-queue.mutex);
}
/* Release the file handle. */
--
1.7.2.2
--
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 3/5] uvcvideo: Move mmap() handler to uvc_queue.c
The mmap() implementation belongs to the video buffers queue, move it
there.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_queue.c | 76 +++
drivers/media/video/uvc/uvc_v4l2.c | 67 +--
drivers/media/video/uvc/uvcvideo.h |2 +
3 files changed, 79 insertions(+), 66 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_queue.c
b/drivers/media/video/uvc/uvc_queue.c
index 32c1822..f14581b 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -380,6 +380,82 @@ done:
}
/*
+ * VMA operations.
+ */
+static void uvc_vm_open(struct vm_area_struct *vma)
+{
+ struct uvc_buffer *buffer = vma-vm_private_data;
+ buffer-vma_use_count++;
+}
+
+static void uvc_vm_close(struct vm_area_struct *vma)
+{
+ struct uvc_buffer *buffer = vma-vm_private_data;
+ buffer-vma_use_count--;
+}
+
+static const struct vm_operations_struct uvc_vm_ops = {
+ .open = uvc_vm_open,
+ .close = uvc_vm_close,
+};
+
+/*
+ * Memory-map a video buffer.
+ *
+ * This function implements video buffers memory mapping and is intended to be
+ * used by the device mmap handler.
+ */
+int uvc_queue_mmap(struct uvc_video_queue *queue, struct vm_area_struct *vma)
+{
+ struct uvc_buffer *uninitialized_var(buffer);
+ struct page *page;
+ unsigned long addr, start, size;
+ unsigned int i;
+ int ret = 0;
+
+ start = vma-vm_start;
+ size = vma-vm_end - vma-vm_start;
+
+ mutex_lock(queue-mutex);
+
+ for (i = 0; i queue-count; ++i) {
+ buffer = queue-buffer[i];
+ if ((buffer-buf.m.offset PAGE_SHIFT) == vma-vm_pgoff)
+ break;
+ }
+
+ if (i == queue-count || size != queue-buf_size) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ /*
+* VM_IO marks the area as being an mmaped region for I/O to a
+* device. It also prevents the region from being core dumped.
+*/
+ vma-vm_flags |= VM_IO;
+
+ addr = (unsigned long)queue-mem + buffer-buf.m.offset;
+ while (size 0) {
+ page = vmalloc_to_page((void *)addr);
+ if ((ret = vm_insert_page(vma, start, page)) 0)
+ goto done;
+
+ start += PAGE_SIZE;
+ addr += PAGE_SIZE;
+ size -= PAGE_SIZE;
+ }
+
+ vma-vm_ops = uvc_vm_ops;
+ vma-vm_private_data = buffer;
+ uvc_vm_open(vma);
+
+done:
+ mutex_unlock(queue-mutex);
+ return ret;
+}
+
+/*
* Poll the video queue.
*
* This function implements video queue polling and is intended to be used by
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index 0fd9848b..07dd235 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -1032,79 +1032,14 @@ static ssize_t uvc_v4l2_read(struct file *file, char
__user *data,
return -EINVAL;
}
-/*
- * VMA operations.
- */
-static void uvc_vm_open(struct vm_area_struct *vma)
-{
- struct uvc_buffer *buffer = vma-vm_private_data;
- buffer-vma_use_count++;
-}
-
-static void uvc_vm_close(struct vm_area_struct *vma)
-{
- struct uvc_buffer *buffer = vma-vm_private_data;
- buffer-vma_use_count--;
-}
-
-static const struct vm_operations_struct uvc_vm_ops = {
- .open = uvc_vm_open,
- .close = uvc_vm_close,
-};
-
static int uvc_v4l2_mmap(struct file *file, struct vm_area_struct *vma)
{
struct uvc_fh *handle = file-private_data;
struct uvc_streaming *stream = handle-stream;
- struct uvc_video_queue *queue = stream-queue;
- struct uvc_buffer *uninitialized_var(buffer);
- struct page *page;
- unsigned long addr, start, size;
- unsigned int i;
- int ret = 0;
uvc_trace(UVC_TRACE_CALLS, uvc_v4l2_mmap\n);
- start = vma-vm_start;
- size = vma-vm_end - vma-vm_start;
-
- mutex_lock(queue-mutex);
-
- for (i = 0; i queue-count; ++i) {
- buffer = queue-buffer[i];
- if ((buffer-buf.m.offset PAGE_SHIFT) == vma-vm_pgoff)
- break;
- }
-
- if (i == queue-count || size != queue-buf_size) {
- ret = -EINVAL;
- goto done;
- }
-
- /*
-* VM_IO marks the area as being an mmaped region for I/O to a
-* device. It also prevents the region from being core dumped.
-*/
- vma-vm_flags |= VM_IO;
-
- addr = (unsigned long)queue-mem + buffer-buf.m.offset;
- while (size 0) {
- page = vmalloc_to_page((void *)addr);
- if ((ret = vm_insert_page(vma, start, page)) 0)
- goto done;
-
- start += PAGE_SIZE;
- addr += PAGE_SIZE;
[PATCH 5/5] uvcvideo: Convert to unlocked_ioctl
The uvcvideo driver now locks all ioctls correctly on its own, the BKL
isn't needed anymore.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_v4l2.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index b4615e2..3349e26 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -1088,7 +1088,7 @@ const struct v4l2_file_operations uvc_fops = {
.owner = THIS_MODULE,
.open = uvc_v4l2_open,
.release= uvc_v4l2_release,
- .ioctl = uvc_v4l2_ioctl,
+ .unlocked_ioctl = uvc_v4l2_ioctl,
.read = uvc_v4l2_read,
.mmap = uvc_v4l2_mmap,
.poll = uvc_v4l2_poll,
--
1.7.2.2
--
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 4/5] uvcvideo: Lock stream mutex when accessing format-related information
The stream mutex protects access to the struct uvc_streaming ctrl,
cur_format and cur_frame fields as well as to the hardware probe
control. Lock it appropriately.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_v4l2.c | 76 +--
drivers/media/video/uvc/uvc_video.c |3 -
drivers/media/video/uvc/uvcvideo.h |4 +-
3 files changed, 57 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index 07dd235..b4615e2 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -226,12 +226,14 @@ static int uvc_v4l2_try_format(struct uvc_streaming
*stream,
* developers test their webcams with the Linux driver as well as with
* the Windows driver).
*/
+ mutex_lock(stream-mutex);
if (stream-dev-quirks UVC_QUIRK_PROBE_EXTRAFIELDS)
probe-dwMaxVideoFrameSize =
stream-ctrl.dwMaxVideoFrameSize;
/* Probe the device. */
ret = uvc_probe_video(stream, probe);
+ mutex_unlock(stream-mutex);
if (ret 0)
goto done;
@@ -255,14 +257,21 @@ done:
static int uvc_v4l2_get_format(struct uvc_streaming *stream,
struct v4l2_format *fmt)
{
- struct uvc_format *format = stream-cur_format;
- struct uvc_frame *frame = stream-cur_frame;
+ struct uvc_format *format;
+ struct uvc_frame *frame;
+ int ret = 0;
if (fmt-type != stream-type)
return -EINVAL;
- if (format == NULL || frame == NULL)
- return -EINVAL;
+ mutex_lock(stream-mutex);
+ format = stream-cur_format;
+ frame = stream-cur_frame;
+
+ if (format == NULL || frame == NULL) {
+ ret = -EINVAL;
+ goto done;
+ }
fmt-fmt.pix.pixelformat = format-fcc;
fmt-fmt.pix.width = frame-wWidth;
@@ -273,6 +282,8 @@ static int uvc_v4l2_get_format(struct uvc_streaming *stream,
fmt-fmt.pix.colorspace = format-colorspace;
fmt-fmt.pix.priv = 0;
+done:
+ mutex_unlock(stream-mutex);
return 0;
}
@@ -287,18 +298,24 @@ static int uvc_v4l2_set_format(struct uvc_streaming
*stream,
if (fmt-type != stream-type)
return -EINVAL;
- if (uvc_queue_allocated(stream-queue))
- return -EBUSY;
-
ret = uvc_v4l2_try_format(stream, fmt, probe, format, frame);
if (ret 0)
return ret;
+ mutex_lock(stream-mutex);
+
+ if (uvc_queue_allocated(stream-queue)) {
+ ret = -EBUSY;
+ goto done;
+ }
+
memcpy(stream-ctrl, probe, sizeof probe);
stream-cur_format = format;
stream-cur_frame = frame;
- return 0;
+done:
+ mutex_unlock(stream-mutex);
+ return ret;
}
static int uvc_v4l2_get_streamparm(struct uvc_streaming *stream,
@@ -309,7 +326,10 @@ static int uvc_v4l2_get_streamparm(struct uvc_streaming
*stream,
if (parm-type != stream-type)
return -EINVAL;
+ mutex_lock(stream-mutex);
numerator = stream-ctrl.dwFrameInterval;
+ mutex_unlock(stream-mutex);
+
denominator = 1000;
uvc_simplify_fraction(numerator, denominator, 8, 333);
@@ -336,7 +356,6 @@ static int uvc_v4l2_get_streamparm(struct uvc_streaming
*stream,
static int uvc_v4l2_set_streamparm(struct uvc_streaming *stream,
struct v4l2_streamparm *parm)
{
- struct uvc_frame *frame = stream-cur_frame;
struct uvc_streaming_control probe;
struct v4l2_fract timeperframe;
uint32_t interval;
@@ -345,28 +364,36 @@ static int uvc_v4l2_set_streamparm(struct uvc_streaming
*stream,
if (parm-type != stream-type)
return -EINVAL;
- if (uvc_queue_streaming(stream-queue))
- return -EBUSY;
-
if (parm-type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
timeperframe = parm-parm.capture.timeperframe;
else
timeperframe = parm-parm.output.timeperframe;
- memcpy(probe, stream-ctrl, sizeof probe);
interval = uvc_fraction_to_interval(timeperframe.numerator,
timeperframe.denominator);
-
uvc_trace(UVC_TRACE_FORMAT, Setting frame interval to %u/%u (%u).\n,
timeperframe.numerator, timeperframe.denominator, interval);
- probe.dwFrameInterval = uvc_try_frame_interval(frame, interval);
+
+ mutex_lock(stream-mutex);
+
+ if (uvc_queue_streaming(stream-queue)) {
+ mutex_unlock(stream-mutex);
+ return -EBUSY;
+ }
+
+ memcpy(probe, stream-ctrl, sizeof probe);
+ probe.dwFrameInterval =
+ uvc_try_frame_interval(stream-cur_frame, interval);
/* Probe the device with the new settings. */
ret =
Re: [PATCH 1/5] uvcvideo: Lock controls mutex when querying menus
Just one comment:
On Sunday, November 21, 2010 21:32:49 Laurent Pinchart wrote:
uvc_find_control() must be called with the controls mutex locked. Fix
uvc_query_v4l2_menu() accordingly.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_ctrl.c | 48
+++-
drivers/media/video/uvc/uvc_v4l2.c | 36 +--
drivers/media/video/uvc/uvcvideo.h |4 +-
3 files changed, 50 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c
index f169f77..59f8a9a 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -785,7 +785,7 @@ static void __uvc_find_control(struct uvc_entity *entity,
__u32 v4l2_id,
}
}
-struct uvc_control *uvc_find_control(struct uvc_video_chain *chain,
+static struct uvc_control *uvc_find_control(struct uvc_video_chain *chain,
__u32 v4l2_id, struct uvc_control_mapping **mapping)
{
struct uvc_control *ctrl = NULL;
@@ -944,6 +944,52 @@ done:
return ret;
}
+/*
+ * Mapping V4L2 controls to UVC controls can be straighforward if done well.
+ * Most of the UVC controls exist in V4L2, and can be mapped directly. Some
+ * must be grouped (for instance the Red Balance, Blue Balance and Do White
+ * Balance V4L2 controls use the White Balance Component UVC control) or
+ * otherwise translated. The approach we take here is to use a translation
+ * table for the controls that can be mapped directly, and handle the others
+ * manually.
+ */
+int uvc_query_v4l2_menu(struct uvc_video_chain *chain,
+ struct v4l2_querymenu *query_menu)
+{
+ struct uvc_menu_info *menu_info;
+ struct uvc_control_mapping *mapping;
+ struct uvc_control *ctrl;
+ u32 index = query_menu-index;
+ u32 id = query_menu-id;
+ int ret;
+
+ memset(query_menu, 0, sizeof(*query_menu));
+ query_menu-id = id;
+ query_menu-index = index;
+
+ ret = mutex_lock_interruptible(chain-ctrl_mutex);
+ if (ret 0)
+ return -ERESTARTSYS;
Just return 'ret' here (which is -EINTR).
+
+ ctrl = uvc_find_control(chain, query_menu-id, mapping);
+ if (ctrl == NULL || mapping-v4l2_type != V4L2_CTRL_TYPE_MENU) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ if (query_menu-index = mapping-menu_count) {
+ ret = -EINVAL;
+ goto done;
+ }
+
+ menu_info = mapping-menu_info[query_menu-index];
+ strlcpy(query_menu-name, menu_info-name, sizeof query_menu-name);
+
+done:
+ mutex_unlock(chain-ctrl_mutex);
+ return ret;
+}
+
snip
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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 4/5] uvcvideo: Lock stream mutex when accessing format-related information
Another comment:
On Sunday, November 21, 2010 21:32:52 Laurent Pinchart wrote:
The stream mutex protects access to the struct uvc_streaming ctrl,
cur_format and cur_frame fields as well as to the hardware probe
control. Lock it appropriately.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_v4l2.c | 76
+--
drivers/media/video/uvc/uvc_video.c |3 -
drivers/media/video/uvc/uvcvideo.h |4 +-
3 files changed, 57 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c
index 07dd235..b4615e2 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
@@ -226,12 +226,14 @@ static int uvc_v4l2_try_format(struct uvc_streaming
*stream,
* developers test their webcams with the Linux driver as well as with
* the Windows driver).
*/
+ mutex_lock(stream-mutex);
if (stream-dev-quirks UVC_QUIRK_PROBE_EXTRAFIELDS)
probe-dwMaxVideoFrameSize =
stream-ctrl.dwMaxVideoFrameSize;
/* Probe the device. */
ret = uvc_probe_video(stream, probe);
+ mutex_unlock(stream-mutex);
if (ret 0)
goto done;
@@ -255,14 +257,21 @@ done:
static int uvc_v4l2_get_format(struct uvc_streaming *stream,
struct v4l2_format *fmt)
{
- struct uvc_format *format = stream-cur_format;
- struct uvc_frame *frame = stream-cur_frame;
+ struct uvc_format *format;
+ struct uvc_frame *frame;
+ int ret = 0;
if (fmt-type != stream-type)
return -EINVAL;
- if (format == NULL || frame == NULL)
- return -EINVAL;
+ mutex_lock(stream-mutex);
+ format = stream-cur_format;
+ frame = stream-cur_frame;
+
+ if (format == NULL || frame == NULL) {
+ ret = -EINVAL;
ret is set...
+ goto done;
+ }
fmt-fmt.pix.pixelformat = format-fcc;
fmt-fmt.pix.width = frame-wWidth;
@@ -273,6 +282,8 @@ static int uvc_v4l2_get_format(struct uvc_streaming
*stream,
fmt-fmt.pix.colorspace = format-colorspace;
fmt-fmt.pix.priv = 0;
+done:
+ mutex_unlock(stream-mutex);
return 0;
But not returned?!
}
snip
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] uvcvideo: Lock controls mutex when querying menus
Hi Hans,
Thanks for the comment.
On Sunday 21 November 2010 22:18:41 Hans Verkuil wrote:
On Sunday, November 21, 2010 21:32:49 Laurent Pinchart wrote:
uvc_find_control() must be called with the controls mutex locked. Fix
uvc_query_v4l2_menu() accordingly.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_ctrl.c | 48
+++- drivers/media/video/uvc/uvc_v4l2.c
| 36 +-- drivers/media/video/uvc/uvcvideo.h |
4 +-
3 files changed, 50 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_ctrl.c
b/drivers/media/video/uvc/uvc_ctrl.c index f169f77..59f8a9a 100644
--- a/drivers/media/video/uvc/uvc_ctrl.c
+++ b/drivers/media/video/uvc/uvc_ctrl.c
@@ -785,7 +785,7 @@ static void __uvc_find_control(struct uvc_entity
*entity, __u32 v4l2_id,
}
}
-struct uvc_control *uvc_find_control(struct uvc_video_chain *chain,
+static struct uvc_control *uvc_find_control(struct uvc_video_chain
*chain,
__u32 v4l2_id, struct uvc_control_mapping **mapping)
{
struct uvc_control *ctrl = NULL;
@@ -944,6 +944,52 @@ done:
return ret;
}
+/*
+ * Mapping V4L2 controls to UVC controls can be straighforward if done
well. + * Most of the UVC controls exist in V4L2, and can be mapped
directly. Some + * must be grouped (for instance the Red Balance, Blue
Balance and Do White + * Balance V4L2 controls use the White Balance
Component UVC control) or + * otherwise translated. The approach we take
here is to use a translation + * table for the controls that can be
mapped directly, and handle the others + * manually.
+ */
+int uvc_query_v4l2_menu(struct uvc_video_chain *chain,
+ struct v4l2_querymenu *query_menu)
+{
+ struct uvc_menu_info *menu_info;
+ struct uvc_control_mapping *mapping;
+ struct uvc_control *ctrl;
+ u32 index = query_menu-index;
+ u32 id = query_menu-id;
+ int ret;
+
+ memset(query_menu, 0, sizeof(*query_menu));
+ query_menu-id = id;
+ query_menu-index = index;
+
+ ret = mutex_lock_interruptible(chain-ctrl_mutex);
+ if (ret 0)
+ return -ERESTARTSYS;
Just return 'ret' here (which is -EINTR).
Hmmm... The uvcvideo driver uses -ERESTARTSYS extensively. What's the
rationale behind using -EINTR instead ? Allowing users to interrupt the ioctl
with ctrl-C ? If so, I wonder if it's worth it in this case, as the controls
mutex will not be locked by another thread for an extensive period of time
anyway.
ERESTARTSYS is meant to be used to deliver signals to application right away
and then restart the system call. With EINTR applications would see an error
in response to a VIDIOC_QUERYMENU call if SIGALRM arrives at the same time. I
don't think that's something we want.
--
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: [PATCH 4/5] uvcvideo: Lock stream mutex when accessing format-related information
Hi Hans,
Thanks for the comment.
On Sunday 21 November 2010 22:23:38 Hans Verkuil wrote:
On Sunday, November 21, 2010 21:32:52 Laurent Pinchart wrote:
The stream mutex protects access to the struct uvc_streaming ctrl,
cur_format and cur_frame fields as well as to the hardware probe
control. Lock it appropriately.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/video/uvc/uvc_v4l2.c | 76
+-- drivers/media/video/uvc/uvc_video.c
|3 -
drivers/media/video/uvc/uvcvideo.h |4 +-
3 files changed, 57 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_v4l2.c
b/drivers/media/video/uvc/uvc_v4l2.c index 07dd235..b4615e2 100644
--- a/drivers/media/video/uvc/uvc_v4l2.c
+++ b/drivers/media/video/uvc/uvc_v4l2.c
[snip]
@@ -255,14 +257,21 @@ done:
static int uvc_v4l2_get_format(struct uvc_streaming *stream,
struct v4l2_format *fmt)
{
- struct uvc_format *format = stream-cur_format;
- struct uvc_frame *frame = stream-cur_frame;
+ struct uvc_format *format;
+ struct uvc_frame *frame;
+ int ret = 0;
if (fmt-type != stream-type)
return -EINVAL;
- if (format == NULL || frame == NULL)
- return -EINVAL;
+ mutex_lock(stream-mutex);
+ format = stream-cur_format;
+ frame = stream-cur_frame;
+
+ if (format == NULL || frame == NULL) {
+ ret = -EINVAL;
ret is set...
+ goto done;
+ }
fmt-fmt.pix.pixelformat = format-fcc;
fmt-fmt.pix.width = frame-wWidth;
@@ -273,6 +282,8 @@ static int uvc_v4l2_get_format(struct uvc_streaming
*stream,
fmt-fmt.pix.colorspace = format-colorspace;
fmt-fmt.pix.priv = 0;
+done:
+ mutex_unlock(stream-mutex);
return 0;
But not returned?!
My bad. I'll fix it. Thanks.
--
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: [RFC/PATCH v5 01/12] media: Media device node support
Hi Jonathan,
I forgot to answer one of your comments.
On Wednesday 17 November 2010 01:31:15 Jonathan Corbet wrote:
[snip]
+static unsigned int media_poll(struct file *filp,
+ struct poll_table_struct *poll)
+{
+ struct media_devnode *mdev = media_devnode_data(filp);
+
+ if (!mdev-fops-poll || !media_devnode_is_registered(mdev))
+ return DEFAULT_POLLMASK;
+ return mdev-fops-poll(filp, poll);
+}
If it's not registered, I would expect poll() to return an error.
Agreed. I'll return POLLERR | POLLHUP in that case. Is that fine with you ?
--
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
Race condition between v4l2_open() and video_unregister_device()
Hi Hans, I believe you've introduced a race condition in commit dd0daf2a6fb6bec436a3ef68bd585ea09a2a54b7 v4l2-dev: remove unnecessary lock around atomic clear_bit By removing the mutex_lock/unlock around clear_bit, you're allowing device_unregister() to race with v4l2_open(). The device can be unregistered between the video_devdata() and video_get() calls. Could you confirm my analysis ? -- 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: Problem with Compro T200 (TDA1004x) and tuning Hi
Hi Mike, Am Sonntag, den 21.11.2010, 17:58 + schrieb Mike Martin: I am trying to tune channels with this card (which seems to be installed OK). However the output is Using DVB card Philips TDA10046H DVB-T tuning DVB-T (in United Kingdom) to 497833000 Hz polling Getting frontend event FE_STATUS: polling polling polling usually, in the UK, this can be caused by the missing ability to detect some frequencies offsets by the tda10046. Since you have already a minus of 167000Hz, typically for the UK, in your initial scan/tuning file, this most common problem likely can be excluded. So there are eventually three variants causing the problem on a first idea. 1. They changed to 498 MHz. (or did change something else too, auto is your friend in the initial scan file then, except for the freq.) 2. Your overall signal is not good enough. 3. You sit on some kernel with some bug. Case one and two are not hard to come through, for case three, the remedies are slipping away. You might have to install some latest .rc-git stuff, likely without support for your graphics card, coming up in vesa mode only, try to record something, and boot back into some kernel with support for displaying the record, we all have HDTV these days ... It might look like that, since the mobile devices and webcams took it all over here ;) 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
