Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
On Sun, Jul 19, 2009 at 9:15 AM, Mark Lordl...@rtr.ca wrote: Devin, Thanks for your good efforts and updates on the xc5000 driver. But the version in 2.6.31 no longer works with mythfrontend from the 0.21-fixes branch of MythTV. The mythbackend (recording) program tunes/records fine with it, but any attempt to watch Live TV via mythfrontend just locks up the UI for 30 seconds or so, and then it reverts to the menus. I find that rather odd, as mythfrontend normally has very little interaction with the tuner devices. But it does try to read the signal strength and quality from the tuner, so perhaps this is a clue as to what has gone wrong? I also took just the xc5000.[ch] files from 2.6.31 and tried them with 2.6.30, to help isolate things. Exactly the same behaviour was observed there, too. The mythbackend could tune/record, but the mythfrontend would lock up. ??? Hello Mark, Thank you for the bug report. Michael Krufky and I tested the tuner changes with what I thought were all the tuners that used the xc5000 (yes, between the two of us we have quite a collection). Perhaps we missed one though. Replacing xc5000.[ch] would normally be a good idea from a testing standpoint. However, in this case it isn't very conclusive since the xc5000 performance and power management improvements exposed numerous bugs in various demods, bridges, and even one in dvb core (all of which I had to fix before the xc5000 work could be submitted upstream). Could you please provide the following: 1. Exactly which product you are using (including the USB/PCI id) 2. dmesg output from the time the card is inserted (or booted up if PCI) to the time *after* you attempted to use the frontend with mythtv. 3. Whether you are using the device for digital, analog, or both, and which the mythtv attempted to use when running the mythfrontend. Also, Could you please install the latest v4l-dvb code using the directions at http://linuxtv.org/repo and see if the problem still occurs. This will tell us if the problem is some patch that didn't make it upstream, and will make it easier for me to give you patches that provide more debug info. I will be afk until tonight, but will check my email as soon as I get home. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The em28xx driver is creating /dev/video* entry for dvb only cards
On Sun, Jul 19, 2009 at 10:39 AM, ac...@fastmail.fm wrote: The em28xx driver is creating /dev/video* entry for dvb only cards. Yes, you are correct. This is something that has fixing has been on my todo list for a while, but I haven't gotten around to it because the fix will require considerable testing to ensure that it doesn't cause a regression with any existing cards (for example, some devices may be relying on incorrect GPIO configuration which would break if we just skipped the analog initialization phase). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
On Sun, Jul 19, 2009 at 6:42 PM, Mark Lordl...@rtr.ca wrote: Mark Lord wrote: .. 3. In mythtv-setup - CaptureCards - DVB:1 - RecordingOptions there is a tickbox for Open DVB Card on Demand. It was ticked, so I un-ticked that box. Everything now works! When that tickbox was selected, the xc5000 took five (5) seconds to open, as it did the firmware upload every time. This appeared to exceed some timeout inside myth. With the tickbox NOT ticked, myth just opens the tuner once at startup, and keeps it open, so no more delay when it wants to use it. I wonder if we can be smarter/faster about the xc5000 firmware uploads? .. The firmware downloads take a little over six seconds, each time, and appear to be done after any sleep of the device. The un-ticked checkbox above means that the device will NEVER be put to sleep, though.. One problem (not new) remains: the device remains live on the USB even when the system is powered-off. It stays quite warm to the touch and is obviously wasting power this way. Is there not something the driver could do to put it to sleep on system shutdown, so that it draws much less power, per USB spec ? thanks! Hello Mark, Yeah, the situation with the seven second firmware load time is well known. It's actually a result of the i2c's implementation in the au0828 hardware not properly supporting i2c clock stretching. Because of some bugs in the hardware, I have it clocked down to something like 30KHz as a workaround. I spent about a week investigating the i2c bus issue with my logic analyzer, and had to move on to other things. I documented the gory details here back in March if you really care: http://devinjh.livejournal.com/169333.html http://devinjh.livejournal.com/169075.html (and there is more discussion of the various issues at http://www.kernellabs.com/blog ) That said, the issue only occurs with the HVR-950q (and other devices that have both xc5000 and au0828). On most boards, the combined time to load the firmware and do the initial tune is actually about half the time required compared to before the xc5000 improvements (for example, the initial tune time on the PCTV 801e went from 3200ms down to 1100ms with subsequent tunes now taking about 350ms). There is a modprobe option I added for xc5000 called no_poweroff=1 which results in the tuner never being put to sleep. People who are hitting the MythTV issue can work around the problem that way, at the expense of no power management (which is exactly how the product behaved before the xc5000 improvements). It is a limitation of the xc5000 hardware design that after putting the chip to sleep, the firmware must be reloaded. The xc5000 pulls about 300ma when powered up, which is why it is warm. In fact, my discomfort with how warm it got even when not in use was the whole reason I got the power management working in the first place. Regarding your comments on being able to put it to sleep on system shutdown, *this* is something I actually was unaware of. I had not really investigated the behavior of the device after shutdown, but this is an area that could certainly use some additional investigation. I've heard similar comments about em28xx, so perhaps what needs to be happening is the dvb core needs to be calling the tuner's sleep function when the module is being unloaded. I would have to figure out the right place to make such a change though (dvb core? the bridge driver? the tuner driver?). Regarding the analog issue with audio, I am aware of the problem, and it is the big outstanding issue preventing people from using the analog support under MythTV (the issue *is* specific to MythTV as other apps work fine with analog audio). I just haven't had the cycles to investigate it yet, but I suspect it's probably a timing issue combined with MythTV doing something really dumb when it hits the exception condition (which causes the segfault). So in summary: 1. You found a regression in MythTV due to the need to reload firmware on the first tune. I can't help but want to blame MythTV for at least part of this given it must have some crappy code for timeout if it cannot distinguish between the time spent in the tuner initalization phase versus the actual tuning request (the timeout seems to be inclusive for both operations). Either I will have to spend some more time trying to fix the au0828 i2c bus so the firmware time is actually reasonable, or see if I can trace down which timeout MythTV hits and see if I can change the driver to load the firmware somewhere earlier (if possible). In the meantime, the workarounds are to use the no_poweroff option or uncheck that box in the mythtv-setup) 2. You hit the known analog audio issue that is preventing people from using analog with MythTV. I guess you can look at the analog support as a work in progress - it works with most apps, but there is something going on specific to MythTV that I haven't isolated yet. Note this issue
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
On Sun, Jul 19, 2009 at 9:57 PM, Mark Lordl...@rtr.ca wrote: Devin Heitmueller wrote: 2. You hit the known analog audio issue that is preventing people from using analog with MythTV. I guess you can look at the analog support as a work in progress - it works with most apps, but there is something going on specific to MythTV that I haven't isolated yet. Note this issue is completely related to the 950q analog project and has nothing to do with the xc5000 tuner improvements. .. One additional thing I noticed here, is that when tuning analog for the first time, the firmware is reloaded yet again.. even though it has already been loaded once for digital operation. Perhaps the extra 6-7second delay here is contributing to Myth's problems. That theory would be very easy to check. Just modprobe xc5000 with no_poweroff=1, load up under digital mode, and then try analog mode and see if you hit the segfault. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
On Sun, Jul 19, 2009 at 10:18 PM, Mark Lordl...@rtr.ca wrote: Devin Heitmueller wrote: Yeah, the situation with the seven second firmware load time is well known. It's actually a result of the i2c's implementation in the au0828 hardware not properly supporting i2c clock stretching. Because of some bugs in the hardware, I have it clocked down to something like 30KHz as a workaround. I spent about a week investigating the i2c bus issue with my logic analyzer, and had to move on to other things. I documented the gory details here back in March if you really care: .. From your livejournal comments, it sounded like the slow clock might not be necessary until *after* the firmware transfer. Mmm.. I wonder if perhaps a higher clock speed could be used during the firmware download, and then switch to the slower 30KHz speed afterward ? This could reduce the firmware transfer to a couple of seconds, much better than the current 6-7 second pause. I did experiment with introducing a tuner callback to inform the bridge to enter a high speed mode, which in theory would have allowed the firmware load at 250Khz (and then revert to the slower speed after the load finished). However, for some unknown reason the tuner would not work after the load. I would see i2c errors on the bus when doing the tune, and I was not able to identify the cause. I spent a couple of nights playing with the idea, but didn't have more time to spend on it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Terratec Grabby
On Sat, Jul 18, 2009 at 6:16 AM, Alina Friedrichsenx-al...@gmx.net wrote: Hello, how to solve the following kernel error message? em28xx #0: vidioc_s_fmt_vid_cap queue busy I want watch TV with the good old xawtv of Debian lenny with linux 2.6.31-rc3-git3 and the current driver of the v4l-dvb git repository. When I want to use the vlc for it then get the following error messages: [0x1ce7848] v4l2 access debug: opening device '/dev/video0' [0x1ce7848] v4l2 access debug: V4L2 device: Terratec Grabby using driver: em28xx (version: 0.1.2) on usb-:00:1d.7-1 [0x1ce7848] v4l2 access debug: the device has the capabilities: (X) Video Capure, (X) Audio, ( ) Tuner [0x1ce7848] v4l2 access debug: supported I/O methods are: (X) Read/Write, (X) Streaming, ( ) Asynchronous [0x1ce7848] v4l2 access debug: video input 0 (Composite1) has type: External analog input [0x1ce7848] v4l2 access debug: video input 1 (S-Video) has type: External analog input * [0x1ce7848] v4l2 access error: cannot get video input characteristics (Das Argument ist ungültig) [0x1ce7848] main access warning: no access module matching v4l2 could be loaded [0x1ce7848] main access debug: TIMER module_need() : 611.941 ms - Total 611.941 ms / 1 intvls (Avg 611.941 ms) [0x1f64538] main input error: open of `v4l2://' failed: (null) Thanks! Regards Alina -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser Hello Alina, Generally speaking, questions like this are best sent to the linux-media mailing list. That said, it looks like your kernel build might have a problem and may not have all the required modules. Did you build the kernel yourself from source? I would have to look at the source to better understand the source of that particular error. Could you please provide the full dmesg output? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] em28xx: kworld 340u
On Sat, Jul 18, 2009 at 5:34 PM, ac...@fastmail.fm wrote: support for kworld 340u. 8vsb and qam256 work, qam64 untested. Hello Acano, You should talk to Jarod Wilson about this. He did a bunch of work to get the 340u working over the last couple of months, and you two could probably collaborate on a unified solution. There were also some problems related to the fact that the device can have either the tda18271c1 or the c2 (both have the same USB id), which would have to be accommodated in the final solution. The patch itself also needs alot of cleanup and doesn't meet the coding standards. It would need considerable cleanup before it could be taken upstream. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881
On Sun, Jul 12, 2009 at 11:23 PM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881 for the following: em28xx: set GPIO properly for Pinnacle Hybrid Pro analog support em28xx: make support work for the Pinnacle Hybrid Pro (eb1a:2881) Thanks, Devin Mauro, Please note that the PULL has been updated with two additional patches, which were necessary for this board to work. I had them in my working directory from when I did the initial work, but accidentally did not include them in the patch series. The final series is as follows: em28xx: set demod profile for Pinnacle Hybrid Pro 320e em28xx: Make sure the tuner is initialized if generic empia USB id was used em28xx: set GPIO properly for Pinnacle Hybrid Pro analog support em28xx: make support work for the Pinnacle Hybrid Pro (eb1a:2881) Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881
On Mon, Jul 13, 2009 at 9:51 AM, Markus Rechbergermrechber...@gmail.com wrote: On Mon, Jul 13, 2009 at 5:23 AM, Devin Heitmuellerdheitmuel...@kernellabs.com wrote: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881 for the following: em28xx: set GPIO properly for Pinnacle Hybrid Pro analog support em28xx: make support work for the Pinnacle Hybrid Pro (eb1a:2881) You might add a message to dmesg, that this setting can burn other devices which use the eb1a:2881 vendor/productid. Especially Pinnacle they didn't add Svideo/Composite to their device and it works slightly different than the others. Best Regards, Markus Hello Markus, Thank you for taking the time to review the patch and provide feedback. Two questions: 1. Are you suggesting that a warning be shown if someone manually uses card=52, or do you mean that we should show a warning if they actually have the Pinnacle Hybrid Pro 320e? I am using an eeprom checksum to ensure that not all devices with eb1a:2881 use the device profile, but rather only devices with the matching hash, so in theory the profile should only be associated with that one card. 2. Are there any additional details you can provide about the differences in the Pinnacle device you know of which is wired up differently than all the others? Personally, I would like to get rid of the card= modprobe option completely, as it presents a considerable risk of users who do not know any better damaging their hardware. I am obviously very concerned about any cases where devices could be damaged, and any additional information you could provide to help mitigate that risk is certainly welcome. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/hvr-900-tuning-fix
Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/hvr-900-tuning-fix for the following: em28xx: fix tuning problem in HVR-900 (R1) Thank you, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352
Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352 for the following: em28xx: make tuning work for Terratec Cinergy T XS USB (mt352 variant) Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352
On Sun, Jul 12, 2009 at 5:34 PM, Andy Wallsawa...@radix.net wrote:
On Sun, 2009-07-12 at 17:03 -0400, Devin Heitmueller wrote:
Mauro,
Please pull from
http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352 for the
following:
em28xx: make tuning work for Terratec Cinergy T XS USB (mt352 variant)
Did you intend to write 0x5d to register 0x5d?:
+ static u8 tuner_go[] = { TUNER_GO, 0x5d}
Regards,
Andy
Nope, that's a typo (although it works). It should write 0x01 to that register.
Thanks for noticing. Will update the tree now and submit a second PULL.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352
On Sun, Jul 12, 2009 at 5:34 PM, Andy Wallsawa...@radix.net wrote:
On Sun, 2009-07-12 at 17:03 -0400, Devin Heitmueller wrote:
Mauro,
Please pull from
http://kernellabs.com/hg/~dheitmueller/terratec-xs-mt352 for the
following:
em28xx: make tuning work for Terratec Cinergy T XS USB (mt352 variant)
Did you intend to write 0x5d to register 0x5d?:
+ static u8 tuner_go[] = { TUNER_GO, 0x5d}
Regards,
Andy
Thanks,
Devin
Mauro,
The tree has been updated with a fix suggested by Andy. Please PULL
both of these
patches:
em28xx: fix typo in mt352 init sequence for Terratec Cinergy T XS USB
em28xx: make tuning work for Terratec Cinergy T XS USB (mt352 variant)
Thanks,
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/pinnacle_hybrid_2881 for the following: em28xx: set GPIO properly for Pinnacle Hybrid Pro analog support em28xx: make support work for the Pinnacle Hybrid Pro (eb1a:2881) Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
On Fri, Jul 10, 2009 at 8:09 AM, Antti Palosaaricr...@iki.fi wrote: af9013 is correct in my mind. af9013 will return -EINVAL (error invalid value) in case of first garbage value met (maybe better to switch auto mode when garbage value meet and print debug log?). Of course there should be at least debug printing to inform that... but fix you suggest is better for compatibility. You can do that, it is ok for me. From a purist standpoint, I agree that the application at fault, and if it were some no-name application I would just say fix the broken application. Except it's not a no-name application - it's mplayer. Are you familiar with Postel's Law? http://en.wikipedia.org/wiki/Postel%27s_Law Saying this demod is not going to work properly with all versions of one of the most popular applications, especially when other demods handle the condition gracefully, is the sort of thing that causes real problems for the Linux community. 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 -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
On Fri, Jul 10, 2009 at 11:40 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Antti if you can fix this issue and help in the future to make some signal strength API for application, like w_scan, you can keep the Realtek based dvb-t device I sent to you as a gift, some credits for me in patches would also be nice since it takes up a lot of time and money on my side to :D I would *really* like to get the strength/SNR situation straightened out, since it effects all applications, including just the end user's ability to get some idea of the strength in Kaffeine (something that should be relatively simple). I am continuing to brainstorm ideas some for of solution that won't be considered ridiculous to some percentage of the demod maintainers. I did make an effort to credit you for the patches based on your hardware so far: http://www.kernellabs.com/hg/~dheitmueller/em28xx-terratec-zl10353/rev/274eda5953b4 I tolled the mplayer people maybe 5 month's ago about this issue. They were quite simple I had 4 devices that worked with mplayer one did not the problem was with the device, they did not want to listen to the idea something was wrong with there mplayer. If somebody want to convince them with this new prove/research please do so, I let it rest. In fairness, I can appreciate why the mplayer developers' initial impression would be that this is a device-level problem since the software works with many other devices. I did definitely confirm it to be a bug though, and now that we know *exactly* what is wrong, getting a fix upstream into mplayer shouldn't be very hard (it should be a ten line patch). I cannot possibly see them suggesting that sending garbage values from the stack in an ioctl() call is appropriate behavior. :-) If you want, do a cvs checkout of the latest mplayer source, get it to successfully compile and work in your environment, and I will see about logging in next week to cook up a patch we can submit upstream. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
On Fri, Jul 10, 2009 at 11:40 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Antti if you can fix this issue and help in the future to make some signal strength API for application, like w_scan, you can keep the Realtek based dvb-t device I sent to you as a gift, some credits for me in patches would also be nice since it takes up a lot of time and money on my side to :D I would *really* like to get the strength/SNR situation straightened out, since it effects all applications, including just the end user's ability to get some idea of the strength in Kaffeine (something that should be relatively simple). I am continuing to brainstorm ideas some for of solution that won't be considered ridiculous to some percentage of the demod maintainers. I did make an effort to credit you for the patches based on your hardware so far: http://www.kernellabs.com/hg/~dheitmueller/em28xx-terratec-zl10353/rev/274eda5953b4 I tolled the mplayer people maybe 5 month's ago about this issue. They were quite simple I had 4 devices that worked with mplayer one did not the problem was with the device, they did not want to listen to the idea something was wrong with there mplayer. If somebody want to convince them with this new prove/research please do so, I let it rest. In fairness, I can appreciate why the mplayer developers' initial impression would be that this is a device-level problem since the software works with many other devices. I did definitely confirm it to be a bug though, and now that we know *exactly* what is wrong, getting a fix upstream into mplayer shouldn't be very hard (it should be a ten line patch). I cannot possibly see them suggesting that sending garbage values from the stack in an ioctl() call is appropriate behavior. :-) If you want, do a cvs checkout of the latest mplayer source, get it to successfully compile and work in your environment, and I will see about logging in next week to cook up a patch we can submit upstream. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
On Thu, Jul 9, 2009 at 11:44 AM, Jarod Wilsonja...@redhat.com wrote: On Tuesday 07 April 2009 08:36:17 Jean Delvare wrote: So, let's just forget the workarounds and go straight to the point: focus on merging lirc-i2c drivers. Will this happen next week? I fear not. Which is why I can't wait for it. And anyway, in order to merge the lirc_i2c driver, it must be turned into a new-style I2C driver first, so bridge drivers must be prepared for this, which is exactly what my patches are doing. For what its worth, I fixed up lirc_i2c a few days ago, and now have it working just fine with my pvr-250 under 2.6.31-rc2. Real Soon Now (I swear), I'm hoping to get up another head of steam for submitting lirc upstream. Multiple drivers have received a bunch of love in the past few weeks, so I think we're in a pretty good state to have another go at it... -- Jarod Wilson ja...@redhat.com Jarod, This is excellent news. Keep up the good work! Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
On Fri, Jul 3, 2009 at 12:01 PM, Jelle de Jongjelledej...@powercraft.nl wrote: Antti Palosaari wrote: On 06/26/2009 11:07 AM, Jelle de Jong wrote: Hi all, Because i now use a new kernel and new mplayer versions I did some testing again on one of my long standing issues. My Afatech AF9015 DVB-T USB2.0 stick does not work with mplayer, other em28xx devices do work with mplayer. Would somebody be willing to do some tests and see if mplayers works on your devices? Debian 2.6.30-1 /usr/bin/mplayer -identify -v -dvbin timeout=10 dvb://3FM(Digitenne) See the attachments for full details. For me, this works. I tested this with MT2060 tuner device, as you have also. If I remember correctly it worked for you also when channel is selected by using tzap. I don't know what mplayer does differently. Do the television channels in that same multiplex work with mplayer? /usr/bin/mplayer -identify -v -dvbin timeout=10 dvb://TELEVISION CHANNEL I added some delay for demod to wait lock. Could you try if this helps? http://linuxtv.org/hg/~anttip/af9015_delay/ regards Antti Hi Antti, I will get back to this next week, its a lot of work for me to compile the drivers but I will see if i can get it running. (a pre-compiled driver and some insmod for the 686 2.9.30 kernel would be an fast track option if you want to test it a.s.a.p.) Thanks in advance, Jelle de Jong -- 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 Antti, Thanks to Jelle providing an environment to debug the issue in, I isolated the problem. This is actually a combination of bugs in mplayer and the af9013 driver not handling the condition as gracefully as some other demods. First the bugs in mplayer: The following is the line from the channels.conf where tuning failed: Frequency in question: 3FM(Digitenne):72200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:7142:1114 Mplayer does not support TRANSMISSION_MODE_AUTO, GUARD_INTERVAL_AUTO and QAM_AUTO (for the constellation). In the case of the transmission mode and constellation, mplayer does not populate the field at all in the struct sent to the ioctl(), so you get whatever garbage is on the stack. For the guard interval field, it defaults to GUARD_INTERVAL_1_4 if it is an unrecognized value. I confirmed the mplayer behavior with the version Jelle has, as well as checking the source code in the svn trunk for the latest mplayer. So, why does it work with some tuners but not the af9013? Well, some demodulators check to see if *any* of the fields are _AUTO and if any of them are, then it puts the demod into auto mode and disregards whatever is in the other fields. However, the af9013 looks at each field, and if any of them are an unrecognized value, the code bails out in af9013_set_ofdm_params(). As a result, the tuning never actually happens. The behavior should be readily apparent if you were to put the above line into your channels.conf and try to tune (note I had to add printk() lines to af9013_set_ofdm_params() to see it bail out in the first switch statement. Anitti, do you want to take it from here, or would you prefer I rework the routine to put the device into auto mode if any of the fields are auto? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Status of em28xx support
On Mon, Jul 6, 2009 at 4:42 AM, Mike Martinredt...@googlemail.com wrote: Hi Is there any working support for empia chips at the moment (Hauppage HVR900 B2C) I have been using Markus's driver but its been taken offline and my copy doesnt compile with latest kernel (F11) thanks Hello Mike, The B2C model is otherwise known as the HVR-900 R2. The problem for the R2 isn't the em28xx support - it's support for the Micronas drx-d demodulator. The em28xx is fully supported, but the demodulator driver is not and therefore the product is known to not work in the v4l-dvb mainline. I have one of the boards, but given the sheer complexity of the drx-d driver combined with a lack of a DVB-T signal, I haven't tried to make it work. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Who is interested in analog support for dib0700 devices?
Hello all, Some discussion I have been having with Andrej Falout has prompted me to consider finally adding analog support for dib0700 based devices? As a result, I am interested in trying to figure out how many people care about this. In particular, this is a rather large project, so I want to get an idea how many people would actually benefit from this support (and might be willing to donate a couple of dollars toward the effort). I've got all the specs and information required to do the work - it's just a matter of deciding whether it is worth spending three or four weeks of my time that could be spent doing stuff that I would almost certainly consider more interesting. If you are interested in seeing this work, please reply here, or email me privately. Also, include what dib0700 based device you have (and what video decoder and tuner chips it uses if you happen to know). Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC2028 Tuner - firmware issues
On Wed, Jul 1, 2009 at 12:19 AM, Andrej Faloutand...@falout.org wrote: Devin, thank you for your reply, please see below; I did the work for the au0828 bridge, which is used in the US based HVR-950q tuner. I've also done alot of work on the em28xx bridge. I understand the problem but unfortunately this is of little use to identify the product to purchase :-( All I need is a USB hybrid analog PAL/DVB-T TV with FM tuner. (I'm in Australia) That's a tough one. I am in the United States, so I'm not in a good position to recommend DVB-T tuners. To make matters worse, vendors often come out with new hardware designs with the same name as tuners that were previously supported under Linux, so even when a user looks in the LinuxTV wiki, there's a chance that the tuner he then goes out and buys will not be the same hardware. Well we can always return such devices, and send a thank-you-not! email to the vendor in question. Maybe if they knew why are people returning there products, they'll stop doing it and label there products correctly depending on hardware built-in... So a list of known working devices would still be of great help http://devinjh.livejournal.com/174527.html Please see my response, and my donation. Also see: http://www.smolts.org/static/stats/by_class_CAPTURE.html We know there are few million Linux boxes out there, but even for 100.000, 0.4% means There are 400 Bt878 devices out there on Linux... plus, look at the second, and fifth lines :-) I would doubt any vendor would ignore sale of few thousand of there devices, especially the maker of the chip used in all of them. Just for example. And Smolts is a) a very new thing, b) disabled by default so user must explicitly enable collection of data from his/hers PC, c) still not included in all major distros. So regardless of absolute numbers, take a look at percentages - they are the key for getting both vendor and user support. Cheers, Andrej Falout Hello Andrej, I took the ideas you put forth and put together a reply in the form of a blog post. http://devinjh.livejournal.com/ Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
On Thu, Jul 2, 2009 at 4:43 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Is there an other USB DVB-T device that works out of the box with the 2.9.30 kernel? Could somebody show me a link or name of this device so I can buy and test it? You might want to check out the WinTV-Ministick, which is both currently available for sale and supported in Linux. http://www.hauppauge.co.uk/site/products/data_ministickhd.html Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
On Thu, Jul 2, 2009 at 4:51 PM, Jelle de Jongjelledej...@powercraft.nl wrote: Devin Heitmueller wrote: On Thu, Jul 2, 2009 at 4:43 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Is there an other USB DVB-T device that works out of the box with the 2.9.30 kernel? Could somebody show me a link or name of this device so I can buy and test it? You might want to check out the WinTV-Ministick, which is both currently available for sale and supported in Linux. http://www.hauppauge.co.uk/site/products/data_ministickhd.html Devin Hi Devin, Thanks for your response, I am kind of hitting a deadline next Tuesday. I must a kind of working dvb-t system here. The af9013 will be a backup plan. So this is my local supplier. Can I ask you to just make a list of product ids (ArtNr) and I will order them, if they do not work I will sent them out to developers that volunteer: http://www.informatique.nl/cgi-bin/iqshop.cgi?M=ARTG=167 I am only interested in USB DVB-T devices. I will try to make the order tomorrow morning. Thanks in advance, Cheers, Jelle Jelle, Well, before I offer any suggestions, bear in mind that I actually don't use DVB-T and I don't have these products, so I cannot claim that they work from my own experience. Looking at the DVB-T USB entries in list you sent: the ASUS U3000 works according to the Wiki: http://linuxtv.org/wiki/index.php/ASUS_My_Cinema-U3000_Mini From the Hauppauge list, the any HVR-900 you would buy today would almost certainly be an HVR-900 R2, which is known to not be supported in the current tree. From the Pinnacle list, I can tell you that both versions of the 340e are not supported (I am actively developing the xc4000 driver required for them this week). According to the wiki, both the 72e and 73e do work: http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_72e http://linuxtv.org/wiki/index.php/Pinnacle_PCTV_nano_Stick_%2873e%29 I'm not familiar with the products from Plextor and Technisat. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 10:34 AM, George Adamsg_adam...@hotmail.com wrote: Y'all are very kind to help - thank you. I am indeed running Ubuntu Hardy (8.04.2 LTS), kernel on a quad-core Q9550 box. I'll be happy to provide any other system details that may assist. uname -a returns: Linux spurgeon 2.6.24-24-server #1 SMP Wed Apr 15 16:36:01 UTC 2009 i686 GNU/Linux George, FYI: The fix got merged into the mainline two days ago, so if you update to the latest v4l-dvb code, the analog support should now be working properly under your Ubuntu Hardy setup. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC2028 Tuner - firmware issues
On Mon, Jun 29, 2009 at 10:08 PM, Andrej Faloutand...@falout.org wrote: The dvb-usb framework doesn't have any analog support. Therefore none of the dib0700 based devices will support analog either (the problem is not specific to your device and has nothing to do with the xc3028 firmware). Thanks for this, Devin. Are there no plans to support analog in dvb-usb in the future, or is someone maybe working on this? It's been in this state for years now, and nobody is working on it. I've been thinking about doing it myself for a while since I have a couple of dib0700 boards, but it's a big project and I'm not sure I have the motivation since I just completed work on analog support for a different bridge (I'm also working on other drivers right now so it's a question of priorities). It's a non-trivial project - easily a couple thousand lines of code. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Hauppauge HVR-1800 not working at all
On Tue, Jun 30, 2009 at 3:18 PM, Michael Krufkymkru...@linuxtv.org wrote: Mike, thanks for the reply. Two questions... 1. What do you mean by spigots? 2. By the tuner module, do you mean the cx23885?? Output of lsmod shows that cx25840, cx23885 cx2341x are loaded cx25840 27856 0 cx23885 85552 0 cx2341x 12800 1 cx23885 videobuf_dma_sg 12160 1 cx23885 videobuf_dvb 6848 1 cx23885 dvb_core 86112 1 videobuf_dvb videobuf_core 17888 3 cx23885,videobuf_dma_sg,videobuf_dvb v4l2_common 16220 3 cx25840,cx23885,cx2341x videodev 40320 3 cx25840,cx23885,v4l2_common v4l1_compat 13440 1 videodev btcx_risc 4772 1 cx23885 tveeprom 11872 1 cx23885 Please, never remove cc from the public mailinglist. (cc re-added) When I said 'tuner' module, I meant 'tuner' module :-P Hope this helps, Mike To clarify Mike's point, he means there is a module called tuner that you should see in the lsmod. Also, when he refers to spigots, he is referring to the F-connectors on the edge card that you would connect the coax cable to. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Hauppauge HVR-1800 not working at all
On Tue, Jun 30, 2009 at 3:48 PM, George Czerwgcz...@comcast.net wrote: Devin, thanks for the reply. Lsmod showed that tuner was NOT loaded (wonder why?), a modprobe tuner took care of that and now the HVR-1800 is displaying video perfectly and the tuning function works. I guess that I'll have to add tuner into modprobe.preload.d Now if only I can get the sound functioning along with the video! George Admittedly, I don't know why you would have to load the tuner module manually on the HVR-1800. I haven't had to do this on other products? If you are doing raw video capture, then you need to manually tell applications where to find the ALSA device that provides the audio. If you're capturing via the MPEG encoder, then the audio will be embedded in the stream. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Call for testers: Terratec Cinergy T XS USB support
Hello all, A few weeks ago, I did some work on support for the Terratec Cinergy T XS USB product. I successfully got the zl10353 version working and issued a PULL request last week (http://www.kernellabs.com/hg/~dheitmueller/em28xx-terratec-zl10353) However, the other version of the product, which contains a mt352 is not yet working. I am looking for people who own the device and would be willing to do testing of a tree to help debug the issue. Ideal candidates should have the experience using DVB devices under Linux in addition to some other known-working tuner product so we can be sure that certain frequencies are available and that the antenna/location work properly. If you are willing to provide remote SSH access for short periods of time if necessary, also indicate that in your email. Please email me if you are interested in helping out getting the device working. Thank you, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC2028 Tuner - firmware issues
On Mon, Jun 29, 2009 at 8:19 PM, Andrej Faloutand...@falout.org wrote: Hello *, Device: Kaiser Baas USB Hybrid (Analogue and Digital) TV Tuner (KBA01003): http://www.kaiserbaas.com/KBA01003_KB202-1_Kaiser_Baas_USB_Hybrid_HD_TV_Tuner.html Digital DVB-T works fine, but analogue TV FM radio does not. Current Mercurial: Jun 29 18:53:53 polar kernel: usb 8-1: new high speed USB device using ehci_hcd and address 4 Jun 29 18:53:54 polar kernel: usb 8-1: configuration #1 chosen from 1 choice Jun 29 18:53:54 polar kernel: dvb-usb: found a 'YUAN High-Tech STK7700PH' in cold state, will try to load a firmware Jun 29 18:53:54 polar kernel: firmware: requesting dvb-usb-dib0700-1.20.fw Jun 29 18:53:54 polar kernel: dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' Jun 29 18:53:54 polar kernel: dib0700: firmware started successfully. Jun 29 18:53:54 polar kernel: dvb-usb: found a 'YUAN High-Tech STK7700PH' in warm state. Jun 29 18:53:54 polar kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Jun 29 18:53:54 polar kernel: DVB: registering new adapter (YUAN High-Tech STK7700PH) Jun 29 18:53:55 polar kernel: DVB: registering adapter 2 frontend 0 (DiBcom 7000PC)... Jun 29 18:53:55 polar kernel: xc2028 11-0061: creating new instance Jun 29 18:53:55 polar kernel: xc2028 11-0061: type set to XCeive xc2028/xc3028 tuner Jun 29 18:53:55 polar kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb8/8-1/input/input11 Jun 29 18:53:55 polar kernel: dvb-usb: schedule remote query interval to 50 msecs. Jun 29 18:53:55 polar kernel: dvb-usb: YUAN High-Tech STK7700PH successfully initialized and connected. Jun 29 18:53:55 polar kernel: usb 8-1: New USB device found, idVendor=1164, idProduct=1f08 Jun 29 18:53:55 polar kernel: usb 8-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jun 29 18:53:55 polar kernel: usb 8-1: Product: STK7700D Jun 29 18:53:55 polar kernel: usb 8-1: Manufacturer: YUANRD Jun 29 18:53:55 polar kernel: usb 8-1: SerialNumber: 01 Please note that xc2028 load ended WITHOUT an attempt to load the firmware. Reading on http://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028 : In order for the proper firmware to load, the bridge chip must be coded with a xc3028-specific setup and a tuner_callback, with the proper GPIO codes to reset the xc2028/3038. ... etc Googling around I also found that there was/is a known problem with loading firmware: http://www.linuxtv.org/pipermail/linux-dvb/2008-September/028559.html : [ 274.439468] xc2028 3-0061: seek_firmware called, want type=D2620 DTV6 (28), id . [ 274.439472] xc2028 3-0061: Can't find firmware for type=D2620 DTV6 (28), id . [ 274.439475] xc2028 3-0061: load_firmware called [ 274.439477] xc2028 3-0061: seek_firmware called, want type=D2620 DTV6 (28), id . [ 274.439481] xc2028 3-0061: Can't find firmware for type=D2620 DTV6 (28), id . I also find out that others are experiencing exactly the same behavior: https://www.linuxquestions.org/questions/linux-hardware-18/tv-tuner-yuan-mc770a-analog-part-help-719282/ I did spend a fair bit of time researching this, so please dont hate me if the answer is already available somewhere :-) Just a pointer will do... If this is not an issue with a known solution, is there anything I can do? I am a SW developer, but my understanding of HW drivers is close to zero. Your knowledge and help is very much appreciated! Cheers, Andrej Falout -- 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 The dvb-usb framework doesn't have any analog support. Therefore none of the dib0700 based devices will support analog either (the problem is not specific to your device and has nothing to do with the xc3028 firmware). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bah! How do I change channels?
On Sat, Jun 27, 2009 at 8:17 PM, Andy Wallsawa...@radix.net wrote: Oh, I'm not against power management. But state is lost - somethings that's fixable with a lot of work apparently. I was thinking maybe the V4L2 spec could change. I was also pondering maybe the final close() shouldn't be the trigger for powering devices down. How about the final close() + 30 seconds? Or the final close() + some user set interval. It seems like scheduling delayed work to do something like that should be easy enough. That would require a spec change about state being only preserved until power management powered the thing down and probably an additional ioctl() added to set the powerdown delay. The driver could probably default delay to some interval that would be good for most users. I don't know. Just ideas... On the DVB side, there actually is a modprobe parameter for dvb_frontend that allows you to defer putting the device to sleep (defaults to zero seconds). It would be a little trickier to do this in v4l because of the differences in the in-kernel threading (dvb has a dedicated thread for controlling the device). Also, it's globally defined, which is good from a consistency standpoint but annoying in cases where some devices really should defer sleep for some period. For example, the HVR-950q's i2c implementation is *really* slow (8 seconds to load the xc5000 firmware). If I had been able to control the delay on a per-device basis in the board definition I could have set it to sleep after 10 seconds by default, which would have helped in cases like the Kaffeine channel scanner which continuously closes/opens the frontend as it scans. Anyway, it's good to discuss this issue, since I hadn't really considered the implications of the power management until George's email. I'm just not sure what the best approach is at this point and will have to give it some more thought. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pinnacle Systems PCTV 330e and Hauppauge WinTV HVR 900 (R2) not working under Debian 2.6.30-1
On Fri, Jun 26, 2009 at 4:26 AM, Jelle de Jongjelledej...@powercraft.nl wrote: Hi all, This is sort of an updated report, I tested my em28xx based hybrid devices again and the dvb-t still does not work under the 2.6.30 kernel. I am not interested in the analog parts. So how is the process going on getting support for dvb-t in the kernel. I am also not interested in any non free non mainstream maintained code bases. I believe I sent some em28xx devices to Devin, so how is the process going, any luck? Question for Antti if he had any luck with the devices (rtl2831-r2) I send? Best regards, Jelle de Jong Hello Jelle, Unfortunately, I could have told you without your having done any testing that the 330e and HVR-900 R2 are not any closer to working - nobody is working on them. They both use the Micronas drx-d, for which we have a reverse engineered driver that is not currently used in any devices and it is unknown whether it actually works. Devices attempting to use the driver require a config structure which has something like 27 inputs, so while I do have the HVR-900 R2 hardware I didn't feel comfortable attempting to get it to work without a signal generator. Regarding the Terratec Cinergy T XS USB you sent me... there are two variants of the same device with the same USB ID. One has the zl10353 and the other has the mt352. I found one bug that was common to both, one bug in the zl10353 version, and one bug in the mt352. I issued a PULL request for the zl10353 version last Tuesday. So, I've fixed three bugs and gotten the zl10353 version working. The mt352 version (which is the one you sent me) has the fixes above, but according to the one user who has been willing to test the changes, the device still does not work. I do not know whether this is really a bug in the driver or a problem in the user's environment (since he doesn't own any other tuners to verify his signal and antenna with). Contrary to my expectations, I haven't been been able to get access to the signal generator, so I haven't been able to fully test/debug the device myself. If there are any other users out there with the mt352 version of the Terratec Cinergy T XS who can do testing, I would definitely be willing to work with them. I am continuing to try to get access to a generator, and looking for other testers who can try the changes. I'm at a point now where I was debating just sending it back to you and having you see if it works (given the fixes I've already made), and attempting to debug any issues remotely. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bah! How do I change channels?
On Fri, Jun 26, 2009 at 7:50 AM, Andy Wallsawa...@radix.net wrote: I use either v4l2-ctl or ivtv-tune $ ivtv-tune -d /dev/video0 -t us-bcast -c 3 /dev/video0: 61.250 MHz $ v4l2-ctl -d /dev/video0 -f 61.250 Frequency set to 980 (61.25 MHz) Regards, Andy Hello Andy, I had sent George some email off-list with basically the same commands. I think what might be happening here is the tuner gets powered down when not in use, so I think it might be powered down between the v4l-ctl command and the running of the other application. I have sent him a series of commands to try where he modprobes the xc3028 driver with no_poweroff=1, and we will see if that starts working. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pinnacle Systems PCTV 330e and Hauppauge WinTV HVR 900 (R2) not working under Debian 2.6.30-1
On Fri, Jun 26, 2009 at 10:36 AM, Simon Kenyonsi...@koala.ie wrote: as you know i have the xl10353 variant. and you got it to work on my machine. now i know you don't want to hear this but the same code will not work on another machine. both are running 2.6.28-gentoo-r5, however i'm pretty sure the configurations are different. the working machine has an MSI KA780G MS-7551 [SB700 chipset] motherboard and the non-working machine has an ASUSTeK M3N78-EM [GeForce 8200 chipset] motherboard in fact, i've seen reference on this list to the fact that there are problems with the SB700. that seems to be the opposite to me. i will check it out on an Atom based netbook and an old Intel Centrino laptop to see if the code works there. i suspect it will - but need to confirm it. i'm afriad it is two steps forward and one step backwards -- simon Well, that's better than one step forward and two steps backward. :-) Send me the dmesg offline and I will work with you to try to debug the issue. I have some significant doubts this is an em28xx issue though. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: LGDT3304 help (AverMedia Duet A188)
On Fri, Jun 26, 2009 at 10:42 AM, oblibobl...@yahoo.com wrote: I'm trying to put together a driver for the AverMedia A188, which is currently unsupported. Manu Abraham is working on the SAA716x driver which it needs, but the frontends seem to be two LGDT3304's. My google-fu is failing me and I can't find any documentation on the chip. Support for the chip was committed last year, but I don't see any drivers actually using it. Does anyone have any documentation for the chip, or even better, some examples of how to set it up for a driver. Also I don't know how to find their I2C addresses. Thanks for any help in advance. Work was recently done for lgdt3304 support for the K-World 330u by Jarod Wilson and Michael Krufky. That work should be making its way into the mainline driver soon. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bah! How do I change channels?
On Fri, Jun 26, 2009 at 1:28 PM, Robert Krakorarob.krak...@messagenetsystems.com wrote: Yes, it is run after mplayer initially tunes it. However, what is the difference between mplayer tuning and v4l-ctl tuning? They are both submitting the same IOCTLs to the driver to accomplish the same end result; or is mplayer probably submitting some additional IOCTLS to wake the device? The issue is that the tuner gets powered down when the v4l device is closed. So, when running mplayer first, and then v4l-ctl is being used to tune, the file handle is held active by mplayer. But if you run v4l-ctl first, the v4l-ctl opens the handle, tunes successfully, and then closes the handle (which powers down the tuner). Then when running mplayer (or whatever app), the handle gets reopened but the tuner is not tuned to the target frequency that v4l-ctl set. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bah! How do I change channels?
On Fri, Jun 26, 2009 at 2:34 PM, Andy Wallsawa...@radix.net wrote: Hmm, that sure sounds like a V4L2 spec violation. From the V4L2 close() description: Closes the device. Any I/O in progress is terminated and resources associated with the file descriptor are freed. However data format parameters, current input or output, control values or other properties remain unchanged. Regards, Andy I have no idea how that would work with power management. It would mean that all the tuners and demod drivers which don't maintain state across powerdown would have to maintain some sort of cache of all of the programmed registers, and we would need to add some sort of wakeup callback which reprograms the device accordingly (currently we have a sleep callback but not a corresponding callback to wake the device back up). As a requirement, it might have been suitable for PCI cards where you don't care about power management (and therefore never power anything down), but I don't know how practical that is for USB or minicard devices where power management is critical because you're on a battery. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bah! How do I change channels?
On Fri, Jun 26, 2009 at 3:02 PM, Andy Wallsawa...@radix.net wrote: All I'm saying is that it is obviously the expected behavior, it the specified behavior, and all the userland apps and scripts are written with that behavior in mind. The applications' expectation of that behavior is, of course, why we are having this discussion. Assuming arguendo, maintaing state in the face of power management is a hard requirement on the driver; I'll still contend it's harder to change the existing base of applications and user scripts. Until the spec and all the existing apps change, not adhering to the spec leads to user confusion. I guess that means that every product that has a tuner which implements the sleep callback is broken. And yet this is the first case I've heard a user complain, which makes me wonder how big a population is out there that is using scripts to control the tuner. I suspect most people are just using applications like MythTV, xawtv or tvtime, which won't have these issues. I don't intend to come across as argumentative, but if we haven't heard a massive outcry about this by now, maybe nobody actually cares and thus we shouldn't spend the time to build a whole infrastructure to preserve the driver state across the low power mode. Those people who really do care can just disable the power management with a modprobe option. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bah! How do I change channels?
On Fri, Jun 26, 2009 at 3:56 PM, Robert Vincent I care and I love the infrastructure that has been created. However, it seems as though there are devices that do not conform to the paradigm or maybe they are not truly in low power mode. My guess is the latter otherwise there would be a flurry of complaints. Unfortunately, it's a little more complicated. In the beginning, none of the drivers did power management, and nobody cared because they were all PCI cards and nobody would notice a 1 watt difference in consumption on a 300 watt power supply. These devices would maintain persistent state across v4l closes because the chips were never powered down. Other devices, such as some USB devices, do have the power management hooks implemented. I don't know what the percentages are here (I would have to look at the driver code to figure that out). These devices power down the chips when asked to by the bridge, and it is typically triggered when no userland apps still have the v4l device open. In cases such as this, the power management works but it would break cases where people used scripts to control the device. There's probably a third class of devices worth mentioning: those that really should be doing power management but aren't. This includes all the USB devices which burn your fingers and drain your laptop battery from the time you plug it in until the time you unplug it, regardless of whether you are using it. It's not about caring or how much we do or do not love the infrastructure. It's about deciding what are the most important goals given limited developer resources. In this case, it's a question of which is more important: incurring the cost of overhauling all the drivers that do power management to have state persist after a power down versus telling those users who use scripts to manually disable power management. Since we have no idea how many users use scripts to control their tuners, and right now we don't know how many devices are effected, we cannot really make any decisions one way or the other. My hope is to see power management properly implemented in more drivers since I'm concerned about the environment. However, if I have to do a huge overhaul of the state management in every driver just to accommodate an unknown quantity of users, then I would have to think twice about that. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 1:17 AM, George Adamsg_adam...@hotmail.com wrote: Hello! In a last ditch effort, I decided to try downloading a v4l driver snapshot from February back when I had my Pinnacle HD Pro Stick device working. To my amazement, the old drivers worked! By process of elimination (trying newer and newer drivers until my Pinnacle device was once again not recognized), it appears that changeset 11331 (http://linuxtv.org/hg/v4l-dvb/rev/00525b115901), from Mar. 31 2009, is the first one that causes my device to not be recognized. This is the changeset that updated the em28xx driver from 0.1.1 to 0.1.2. Here, again, is the dmesg output from a newer driver that does NOT work (this one from a driver set one day later, on Apr. 1, 2009): Interesting. What distro and version of the kernel are you running? Yesterday Michael Krufky pointed out to me that the v4l subdev registration is broken for the au0828 driver when using the current tip against Ubuntu Hardy (2.6.24), so it now seems likely that it's the exact same issue. Thanks for taking the time to narrow down the actual change that caused the issue. I guess somebody is going to have to build a box with Hardy and debug this issue. :-/ Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 9:43 AM, Hans Verkuilhverk...@xs4all.nl wrote: Hmm, I have Hardy on my laptop at work so I can test this tomorrow with my USB stick. It's a Hauppauge HVRsomething, but it does have a tvp5150. So it should be close enough. Regards, Hans Hans, Oh thank goodness. I was really hoping you would volunteer since you are clearly the best candidate for debugging subdev issues. It took me two days to debug my last issue with v4l2_subdev registration and it required me to recompile the distro's kernel from source to debug the i2c stack. If you've got an em28xx device with the tvp5150, then it's probably an HVR-950, which is almost identical to the Pinnacle 800e. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 10:34 AM, George Adamsg_adam...@hotmail.com wrote: Y'all are very kind to help - thank you. I am indeed running Ubuntu Hardy (8.04.2 LTS), kernel on a quad-core Q9550 box. I'll be happy to provide any other system details that may assist. uname -a returns: Linux spurgeon 2.6.24-24-server #1 SMP Wed Apr 15 16:36:01 UTC 2009 i686 GNU/Linux No, if you are running Hardy then we know what the issue is. No further information is required. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Thu, Jun 25, 2009 at 10:59 AM, George Adamsg_adam...@hotmail.com wrote: Surely there must be some command-line way to change the Pinnacle device to channel 3 before I launch Helix Producer? v4lctl setchannel 3 Or you might want to consider using the composite or s-video input if that's available to you (the quality will be better). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why is the old DVB ML still alive?
On Thu, Jun 25, 2009 at 11:40 AM, wkhandygewinnsp...@gmx.de wrote: Why is the old dvb (linux-dvb) mailing list still alive? One of the arguments migrating all dvb related stuff to this combined ml was to reduce overhead. But in fact some information might be lost now, since not everybody will look at both ML's. Wouldn't it be a good idea to close the old ml now / is this foreseen at all? --Winfried Well, the old linux-dvb list forwards all messages to the new list, so no information is actually lost. However, this does often result in multiple posts with the same content, since the auto-reply message sent back to users posting to linux-dvb often leads them to think the message wasn't delivered. That said, I think enough time has gone by where we can finally just drop the linux-dvb mailing list. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PARTIALLY SOLVED] Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
Hans, I just spoke with mkrufky, and he confirmed the issue does occur with the HVR-950. However, the em28xx driver does not do a printk() when the subdev registration fails (I will submit a patch to fix that). Please let me know if you have any further question. Thanks for your assistance, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Mon, Jun 22, 2009 at 5:39 PM, George Adamsg_adam...@hotmail.com wrote: Hello again. I have some updates now that I've been able to make some further tests. 1) My Pinnacle PCTV HD Pro (800e) stick does, in fact, work correctly under Windows. The scanning detects the one channel we're running over our closed circuit cable (channel 3) and displays it on-screen just fine. (audio over channel 3 works as well) 2) Devin, my installation process is hg clone http://linuxtv.org/hg/v4l-dvb; cd v4l-dvb; make rminstall; make distclean; make; make install This appears to install everything v4l-related as modules in the appropriate directories. For instance: uname -r 2.6.24-24-server find /lib/modules/`uname -r` -type f -name em28xx\* -o -name tvp\* /lib/modules/2.6.24-24-server/kernel/drivers/media/video/tvp5150.ko /lib/modules/2.6.24-24-server/kernel/drivers/media/video/em28xx/em28xx.ko /lib/modules/2.6.24-24-server/kernel/drivers/media/video/em28xx/em28xx-dvb.ko 3) tvtime still hangs when launched. 4) Running zapping gives the error VBI Initialization failed. /dev/vbi0 (Pinnacle PCTV HD Pro) is not a raw vbi device). Continuing on and trying to choose the Preferences menu option segfaults the program (and this is the Ubuntu-distributed zapping package) 5) Running Paul's suggested mplayer command gives the following: mplayer -vo xv tv:// -tv driver=v4l2:alsa:immediatemode=0:adevice=hw.1,0:norm=ntsc:chanlist=us-cable:channel=3 MPlayer 1.0rc2-4.2.4 (C) 2000-2007 MPlayer Team CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (Family: 6, Model: 23, Stepping: 10) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. mplayer: could not connect to socket mplayer: No such file or directory Failed to open LIRC support. You will not be able to use your remote control. Playing tv://. TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski comment: first try, more to come ;-) Selected device: Pinnacle PCTV HD Pro Stick Tuner cap: Tuner rxs: Capabilites: video capture tuner audio read/write streaming supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR; 4 = NTSC-443; 5 = PAL; 6 = PAL-BG; 7 = PAL-H; 8 = PAL-I; 9 = PAL-DK; 10 = PAL-M; 11 = PAL-N; 12 = PAL-Nc; 13 = PAL-60; 14 = SECAM; inputs: 0 = Television; 1 = Composite1; 2 = S-Video; Current input: 0 Current format: YUYV v4l2: current audio mode is : MONO v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument v4l2: ioctl set format failed: Invalid argument Selected channel: 3 (freq: 61.250) Video buffer shorter than 3 times audio frame duration. You will probably experience heavy framedrops. v4l2: ioctl query control failed: Invalid argument v4l2: ioctl query control failed: Invalid argument v4l2: ioctl query control failed: Invalid argument v4l2: ioctl query control failed: Invalid argument xscreensaver_disable: Could not find XScreenSaver window. GNOME screensaver disabled == Opening video decoder: [raw] RAW Uncompressed Video VDec: vo config request - 640 x 480 (preferred colorspace: Packed YUY2) VDec: using Packed YUY2 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. VO: [xv] 640x480 = 640x480 Packed YUY2 Selected video codec: [rawyuy2] vfm: raw (RAW YUY2) == == Forced audio codec: mad Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 44100 Hz, 1 ch, s16le, 705.6 kbit/100.00% (ratio: 88200-88200) Selected audio codec: [pcm] afm: pcm (Uncompressed PCM) == AO: [pulse] 44100Hz 1ch s16le (2 bytes per sample) Starting playback... v4l2: select timeout A: 0.5 V: 0.0 A-V: 0.472 ct: 0.000 1/ 1 ??% ??% ??,?% 1 0 [[JMA: 0.9 V: 0.0 A-V: 0.940 ct: 0.003 2/ 2 ??% ??% ??,?% 2 0 [[JMv4l2: select timeout A: 1.5 V: 0.0 A-V: 1.479 ct: 0.007 3/ 3 ??% ??% ??,?% 3 0 [[JMA: 2.0 V: 0.0 A-V: 1.981 ct: 0.010 4/ 4 ??% ??% ??,?% 4 0 [[JMv4l2: select timeout A: 2.5 V: 0.0 A-V: 2.485 ct: 0.013 5/ 5 ??% ??% ??,?% 5 0 [[JMA: 3.0 V: 0.0 A-V: 2.957 ct: 0.017 6/ 6 ??% ??% ??,?% 6 0 [[JMv4l2: select timeout A: 3.5 V: 0.0 A-V: 3.460 ct: 0.020 7/ 7 ??% ??% ??,?% 7 0 [[JMA: 4.0 V: 0.0 A-V: 3.956 ct: 0.022 8/ 8 ??% ??% ??,?% 8 0 [[JMv4l2: select timeout A: 4.5 V: 0.0 A-V: 4.460 ct: 0.025 9/ 9 ??% ??% ??,?% 9 0 [[JMA: 5.0 V: 0.0 A-V: 4.956 ct: 0.027 10/ 10 ??% ??% ??,?% 10 0 [[JMv4l2: select timeout The Mplayer screen itself remains green the whole time. So the surprise to me is that the Pinnacle device
Re: Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Mon, Jun 22, 2009 at 5:39 PM, George Adamsg_adam...@hotmail.com wrote: Hello again. I have some updates now that I've been able to make some further tests. snip Also, do you have the device plugged in via a powered USB hub? And if so, are you unplugging the 800e from the hub, or are you unplugging the hub from the PC? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Can't use my Pinnacle HDTV USB stick
On Sun, Jun 21, 2009 at 9:49 AM, Paul Guzowskiguzows...@linuxmail.org wrote: George, I can appreciate your frustration because I went through the same struggle a while back. Fortunately, persistence and a lot of help from the great people on this forum helped me finally solve the problems I was having. I have had enough time to study your message line by line and compare it with my own but will offer a few words on what I did. I am using the same stick to capture cable channel three from my cable set-top box. I had a lot of struggles in the process of getting it to work beginning with Ubuntu 8.04 but it has worked flawlessly through all the upgrades to Ubuntu 9.04. I do know there were and maybe still are two different sets of firmware for the 800e and I had both or parts of both installed at the same time and that was causing a problem. Once I got the hardware, firmware, and drivers sorted out, I think I tried just about every video/tv software program available for linux and couldn't get any of the full-featured ones with GUIs to work though I admit I didn't try very hard with MythTV. When I tried to scan for a signal either from the basic cable coming out of the wall or from the RF-out on the back of my set-top box, I could not get anything with any of the pre-built frequency scanning tables and I never succeeded to find a channel configuration file for my cable company's (Brighthouse Networks, panhandle of Florida) signal. I finally found a reference somewhere to using mplayer from the command line and feeding it several specific arguments. Once I got it to work, I put the following in a launcher for easy activation: mplayer -vo xv tv:// -tv driver=v4l2:alsa:immediatemode=0:adevice=hw.1,0:norm=ntsc:chanlist=us-cable:channel=3 Admittedly, all this does is put whatever is selected on my cable box in a window with sound on my desktop. The only thing I can do is resize the window or turn it off but I can control the volume or change the channel with the cable box remote so it does the basics I need. I haven't tried the fancy programs since upgrading to 9.04 nor have I tried mencoder but I would like to eventually be able to record the signal for delayed viewing (i.e. use my computer as a PVR). Hope this helps. Paul in NW Florida Hello Paul, The bulk of the problems you had are usability issues with userland applications rather than issues with the drivers themselves. When it comes to Linux TV applications, the US is much worse off in terms of digital support than Europe and other parts of the world. Much of this is a result of the fact that so much of this country uses cable rather than terrestrial broadcasting, combined with the significantly worse situation with regards to the DRM found in US digital cable systems which effectively prevents people from accessing digital cable on a PC. I can count the list of developers on one hand who work on US based ATSC and QAM drivers. Even fewer actively contribute to application support for these standards. The documentation is lousy, and those who go through the trouble to figure out how to get their stuff to work do not contribute back the information into the wiki. There are just too many devices out there, too many applications out there, and two few developers willing to dedicate the time and energy to do the work. The fact that there is also no way for developers to even recover their costs just further discourages doing new work (a challenge I've had given I've now spent hundreds of dollars on devices and tools and that money is long gone)... I'll get off my soapbox now. :-) Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can't use my Pinnacle PCTV HD Pro stick - what am I doing wrong?
On Sun, Jun 21, 2009 at 3:51 PM, George Adamsg_adam...@hotmail.com wrote: Thank you so much, everyone who has replied to my question! It's nice to find a community of people willing to help. Here is the dmesg output that appears when the Pinnacle device gets plugged in, along with a few ls commands: snip George, It will definitely be interesting to see if the device works under Windows. It is very interesting that the tvp5150 driver isn't being loaded at all, nor the xc3028 during analog initialization (and as a result the DVB won't work because the analog initialization sets the firmware to be used). We've got the exact same USB device ids and last night I confirmed the board is working fine here with the latest tree, suggesting no regression in the driver code. Did you happen to configure for only a subset of drivers to be compiled? Or did you just do a checkout and cd v4l-dvb, make, make install, reboot? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] Kworld DVB-T 323UR problems
On Sun, Jun 21, 2009 at 5:44 PM, Laszlo Kustanlkus...@gmail.com wrote: Hi everyone, I have a Kword DVB-T 323UR connected to a Linux Mint 7 Gloria (based on Ubuntu Jaunty), kernel 2.6.28. I successfully compiled em28xx, the firmware was obtained based on these steps: 1) Download the windows driver with something like: wget http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip 2) Extract the file hcw85bda.sys from the zip into the current dir: unzip -j HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip Driver85/hcw85bda.sys 3) run the script: ./extract_xc3028.pl 4) copy the generated file: cp xc3028-v27.fw /lib/firmware My windows driver is called embda.sys, so I'm not sure whether the firmware is 100% good for my tuner or not. I have a couple of problems: 1. no analog audio, but I found out this works with workarounds I tried several tricks: a. sox -c 2 -r 32000 -t ossdsp /dev/dsp1 -t ossdsp /dev/dsp this works, but with a 4-5 second delay between audio and video b. arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | play -q -c 2 -r 32000 -t wav - I get an error: l...@laco-desktop ~ $ arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | play -q -c 2 -r 32000 -t wav - [1] 9084 l...@laco-desktop ~ $ Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 32000 Hz, Stereo Warning: rate is not accurate (requested = 32000Hz, got = 48000Hz) please, try the plug plugin arecord: pcm_read:1529: read error: Input/output error play wav: Premature EOF on .wav input file c. install modified tvtime from mcentral.de I get an error in this case too: Reading configuration from /usr/etc/tvtime/tvtime.xml Reading configuration from /home/laco/.tvtime/tvtime.xml HDA NVidia : AD198x Analog hw:0,0 Em28xx Audio : Empia 28xx Capture hw:1,0 opening: hw:1,0 Access type not available My arecord -l output is: l...@laco-desktop ~ $ arecord -l List of CAPTURE Hardware Devices card 0: NVidia [HDA NVidia], device 0: AD198x Analog [AD198x Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: Em28xx Audio [Em28xx Audio], device 0: Em28xx Audio [Empia 28xx Capture] Subdevices: 1/1 Subdevice #0: subdevice #0 2. my remote is not recognized. Here is the em28xx part from dmesg: l...@laco-desktop ~ $ dmesg | grep em28xx [11231.562817] em28xx v4l2 driver version 0.0.1 loaded [11231.564913] em28xx: new video device (eb1a:e323): interface 0, class 255 [11231.564920] em28xx: setting up device on a USB 1.1 bus [11231.564924] em28xx: your device won't work properly when [11231.564927] em28xx: not attached to a USB 2.0 highspeed bus [11231.564931] em28xx: more information: [11231.564933] em28xx: http://mcentral.de/wiki/index.php5/Talk:Em2880 [11231.564942] em28xx #0: Alternate settings: 8 [11231.564946] em28xx #0: Alternate setting 0, max size= 0 [11231.564950] em28xx #0: Alternate setting 1, max size= 512 [11231.564954] em28xx #0: Alternate setting 2, max size= 640 [11231.564958] em28xx #0: Alternate setting 3, max size= 768 [11231.564962] em28xx #0: Alternate setting 4, max size= 832 [11231.564966] em28xx #0: Alternate setting 5, max size= 896 [11231.564969] em28xx #0: Alternate setting 6, max size= 960 [11231.564973] em28xx #0: Alternate setting 7, max size= 1020 [11240.939178] em28xx #0: V4L2 VBI device registered as /dev/vbi0 [11240.998075] em28xx #0: V4L2 device registered as /dev/video0 [11240.998087] em28xx #0: Found KWorld E323 [11240.998153] usbcore: registered new interface driver em28xx [11241.064491] em28xx-audio.c: probing for em28x1 non standard usbaudio [11241.064497] em28xx-audio.c: Copyright (C) 2006 Markus Rechberger [11241.922736] em28xx-audio: device is currently in analog TV mode Nothing about input devices here and neither in /proc/bus/input/devices. 3. heat problems I noticed that when it is connected, it gets quite hot, even if no dvb software is running. In Windows it does not get so hot, even when watching tv. Sorry for this long mail. The first point would be the most important to solve, if you need more details to help me, no problem. Thanks, Laszlo Hello Laszlo, Please send correspondence to the linux-media mailing list, as the linux-dvb list is deprecated. Your firmware is fine. The extract_xc3027.pl script will *only* work if the md5 checksum matches, so if it matched then you ended up with the correct firmware. Regarding #1, the audio is working correctly. The problem is that for raw capture devices there is no way currently for the v4l2 to inform applications where to find the ALSA device that provides the audio. Your card is behaving consistently with *every* other product currently supported that provides a raw video stream (as opposed to products with an MPEG encoder onboard). The reason you see the audio being out of sync with the video is because of buffering of the audio prior to playback. You can usually control this behavior with command line arguments for arecord or sox.
Re: [linux-dvb] Can't use my Pinnacle PCTV HD Pro st ick - what am I doing wrong?
2009/6/20 George Adams g_adam...@hotmail.com: Hello. I'm having problems getting my (USB) PCTV HD Pro Stick (800e, the old style) to work under V4L. Could anyone spot the problem in what I'm doing? I'm running Ubuntu 8.04.2 LTS (the 2.6.24-24-server kernel), and am following this procedure (based on http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers). I intend to use this to tune to USA NTSC channel 3 (to capture a close-captioned feed inside our building) 1) Extract and copy the firmware file I need (xc3028-v27.fw) to /lib/firmware 2) cd /usr/local/src 3) hg clone http://linuxtv.org/hg/v4l-dvb 4) cd v4l-dvb 5) make rminstall; make distclean; make; make install These seems to do what it's supposed to - installs the drivers into /lib/modules/2.6.24-24-server . My PCTV HD Pro Stick uses the em28xx drivers. find /lib/modules/ -type f -name em28* -mtime -1 /lib/modules/2.6.24-24-server/kernel/drivers/media/video/em28xx/em28xx.ko /lib/modules/2.6.24-24-server/kernel/drivers/media/video/em28xx/em28xx-dvb.ko 6) Reboot with the USB capture device plugged in 7) Examine dmesg for details related to the capture device - em28xx: New device Pinnacle Systems PCTV 800e @ 480 Mbps (2304:0227, interface 0, class 0) - em28xx #0: Identified as Pinnacle PCTV HD Pro Stick (card=17) - em28xx #0: chip ID is em2882/em2883 - - - GSI 22 (level, low) - IRQ 22 - PCI: Setting latency timer of device :00:1b.0 to 64 - em28xx #0: i2c eeprom 00: 1a eb 67 95 04 23 27 02 d0 12 5c 03 8e 16 a4 1c - em28xx #0: i2c eeprom 10: 6a 24 27 57 46 07 01 00 00 00 00 00 00 00 00 00 - em28xx #0: i2c eeprom 20: 46 00 01 00 f0 10 02 00 b8 00 00 00 5b 1c 00 00 - em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 - em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 24 03 50 00 69 00 - em28xx #0: i2c eeprom 70: 6e 00 6e 00 61 00 63 00 6c 00 65 00 20 00 53 00 - em28xx #0: i2c eeprom 80: 79 00 73 00 74 00 65 00 6d 00 73 00 00 00 16 03 - em28xx #0: i2c eeprom 90: 50 00 43 00 54 00 56 00 20 00 38 00 30 00 30 00 - em28xx #0: i2c eeprom a0: 65 00 00 00 1c 03 30 00 36 00 31 00 30 00 30 00 - em28xx #0: i2c eeprom b0: 31 00 30 00 33 00 39 00 34 00 34 00 32 00 00 00 - em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0x2de5abbf - em28xx #0: EEPROM info: - em28xx #0: AC97 audio (5 sample rates) - em28xx #0: 500mA max power - em28xx #0: Table at 0x27, strings=0x168e, 0x1ca4, 0x246a - hda_codec: Unknown model for ALC882, trying auto-probe from BIOS... - input: em28xx IR (em28xx #0) as /devices/pci:00/:00:1a.7/usb4/4-3/input/input6 - - - GSI 20 (level, low) - IRQ 23 - Vortex: init em28xx #0: Config register raw data: 0xd0 - em28xx #0: AC97 vendor ID = 0x - em28xx #0: AC97 features = 0x6a90 - em28xx #0: Empia 202 AC97 audio processor detected - em28xx #0: v4l2 driver version 0.1.2 - em28xx #0: V4L2 device registered as /dev/video0 and /dev/vbi0 - usbcore: registered new interface driver em28xx - em28xx driver loaded - xc2028 0-0061: creating new instance - xc2028 0-0061: type set to XCeive xc2028/xc3028 tuner - em28xx #0/2: xc3028 attached - DVB: registering new adapter (em28xx #0) - DVB: registering adapter 0 frontend 0 (LG Electronics LGDT3303 VSB/QAM Frontend)... - Successfully loaded em28xx-dvb - Em28xx: Initialized (Em28xx dvb Extension) extension - done. Everything looks good - the drivers are getting called and the card is recognized. However, all my attempts to get something out of it aren't working. I tried firing up tvtime, but it just launches a blank, black screen and hanges. The menu won't come up, the channel won't change, right-clicking isn't responsive, it won't close, and I have to kill it. I also tried mencoder, but I get this: mencoder -nosound -tv driver=v4l2:width=640:height=480 tv://3 -o /tmp/tv.avi -ovc raw -endpos 5 MEncoder 2:1.0~rc2-0ubuntu13.1+medibuntu1 (C) 2000-2007 MPlayer Team CPU: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz (Family: 6, Model: 23, Stepping: 10) CPUflags: Type: 6 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. success: format: 9 data: 0x0 - 0x0 TV file format detected. Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski comment: first try, more to come ;-) Selected device:
Re: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
On Fri, Jun 19, 2009 at 12:41 PM, Hans Verkuilhverk...@xs4all.nl wrote: On Friday 19 June 2009 18:11:11 Devin Heitmueller wrote: On Fri, Jun 19, 2009 at 12:04 PM, Hans Verkuilhverk...@xs4all.nl wrote: Hmm, I discovered that firedtv-1394.c isn't compiled in the daily build even though ieee1394 is enabled in the kernel. I can manually enable it, though: make menuconfig, disable and enable the firedtv driver, and then it magically works. But even then it still compiles fine against the vanilla 2.6.30 kernel. Well, I'm obviously kicking myself for not having captured the output last night when I was at home. So, you're saying that firedvt-1394.c is being compiled? Let me rephrase the question: Take a look at firedtv-1394.c, line 22, and tell me where the file csr1212.h can be found either in your kernel source tree or your v4l-dvb tree. Devin It's here: /usr/src/linux/drivers/ieee1394/csr1212.h Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom Ok, I see what is going on: the header files in question are available if you have the full Linux source installed, but they are not part of the kernel-headers package, at least on Ubuntu. Combined with the fact that the file now gets built with 2.6.30 causes the compile failures: CC [M] /home/devin/800e_test/v4l/firedtv-1394.o /home/devin/800e_test/v4l/firedtv-1394.c:21:17: error: dma.h: No such file or directory /home/devin/800e_test/v4l/firedtv-1394.c:22:21: error: csr1212.h: No such file or directory /home/devin/800e_test/v4l/firedtv-1394.c:23:23: error: highlevel.h: No such file or directory /home/devin/800e_test/v4l/firedtv-1394.c:24:19: error: hosts.h: No such file or directory /home/devin/800e_test/v4l/firedtv-1394.c:25:22: error: ieee1394.h: No such file or directory /home/devin/800e_test/v4l/firedtv-1394.c:26:17: error: iso.h: No such file or directory /home/devin/800e_test/v4l/firedtv-1394.c:27:21: error: nodemgr.h: No such file or directory Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use kzalloc for frontend states to have struct dvb_frontend properly initialized
On Fri, Jun 19, 2009 at 8:41 AM, Matthias Schwarzottz...@gentoo.org wrote: Yes, I did verify that. There are no memset calls for that memory. If so, you can add my Acked-by: Andreas Oberritter o...@linuxtv.org. Regards Matthias I'm glad to see this finally happen. This has been bugging me for a while on s5h1409/s5h1411 and I just never got around to submitting a patch. Thanks! Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.kernellabs.com/hg/~dheitmueller/em28xx-indtube2
Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/em28xx-indtube2 for the following: - em28xx: make sure the analog GPIOs are set if we used a card hint - em28xx: add support for EVGA inDtube Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
It seems that attempting to compile the current v4l-dvb against a stock Karmic Koala build fails. I suspect this has to do with the fact that 2.6.30 is built with ieee1394 enabled, which causes firedtv-ieee1394.c to get compiled, and that file references #include files that do not exist. As far as I can tell, IEEE1394 is not enabled in my 2.6.27 build, which is why I was not seeing it before. Other users reported this issue on the #linuxtv irc a few days ago, and I though it was just something weird about their environment. I'm not familiar with the firedtv driver, so if someone who is wants to chime in, I would appreciate it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
On Fri, Jun 19, 2009 at 11:33 AM, Hans Verkuilhverk...@xs4all.nl wrote: What's the compile error exactly? The firedtv driver compiles fine in the daily build against the vanilla 2.6.30 kernel. Regards, Hans Unfortunately, I sent the email from work and didn't have the output in front of me (or else I would have pasted it into the email). Several people also reported it on #linuxtv on 6/11, but it looks like the pastebins have already expired. :-( I will provide the output tonight. I started to debug it last night, and it seems that firedtv-ieee1494.c doesn't normally get compiled at all, so if you add 1394 support to your build you will likely also see the issue. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: v4l-dvb compile broken with stock Ubuntu Karmic build (firedtv-ieee1394.c errors)
On Fri, Jun 19, 2009 at 12:04 PM, Hans Verkuilhverk...@xs4all.nl wrote: Hmm, I discovered that firedtv-1394.c isn't compiled in the daily build even though ieee1394 is enabled in the kernel. I can manually enable it, though: make menuconfig, disable and enable the firedtv driver, and then it magically works. But even then it still compiles fine against the vanilla 2.6.30 kernel. Well, I'm obviously kicking myself for not having captured the output last night when I was at home. So, you're saying that firedvt-1394.c is being compiled? Let me rephrase the question: Take a look at firedtv-1394.c, line 22, and tell me where the file csr1212.h can be found either in your kernel source tree or your v4l-dvb tree. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/au8522-qam64
Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/au8522-qam64 for the following: - au8522: add support for QAM-64 modulation type The patch went in unmodified after doing some testing to ensure it didn't break anything with VSB or QAM256 (and adding a proper patch description). There is some opportunity for refactoring a bit in relation to the QAM256 code, but there is not a pressing need for such a change and I don't want to hold up support for this any longer since it works as-is. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Em28xx Log as requested
On Sat, Jun 13, 2009 at 8:30 AM, Andrea Merelloandrea.mere...@gmail.com wrote: I got it work only one time, and I cannot reproduce it anymore. I loaded forcing card=7 When worked it could find the philips video decoder IC. Other times, when it does not work, it does not claim to find that IC (see previous mail with log) Maybe you are interested in the log.. It worked by setting input 1 (the second starting by 0) as video composite. I suppose input 0 is the svideo Andrea Hello Andrea, This board shouldn't be too hard to make work. Could you please do the following: In the case where the device failed with card=7, send the dmesg output (it should be slightly different). Are you using rmmod/modprobe to test, or are you physically unplugging/replugging the device? Also, can you provide a link to a digital photo of the device, so we can confirm what inputs/outputs the device has? Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: funny colors from XC5000 on big endian systems
On Mon, Jun 8, 2009 at 7:09 PM, W. Michael Petullo m...@flyn.org wrote: I have a VCR connected to my 950Q using the coaxial interface. Kernel is 2.6.29.4. I am using streamer from Fedora's xawtv-3.95-11.fc11.ppc: v4lctl setchannel 3 streamer -r 30 -s 640x480 -f jpeg -i Television -n NTSC-M -c /dev/video0 -o ~/Desktop/foo.avi -t 00:60:00 I am using gstreamer-plugins-good-0.10.14-2.fc11.ppc: gst-launch v4l2src ! ffmpegcolorspace ! ximagesink Mike Hello Mike, Just a quick follow up, I was up until 1am debugging this issue. It appears that a couple of the ioctl calls are failing when negotiating the capabilities of the analog support. As a result, the gstreamer v4l code is falling back to a default colorspace. The command I sent you should be good enough for it to work for you, but I obviously need to debug this further so that the autonegotiation works properly. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 10:21 AM, Steven Toth st...@kernellabs.com wrote: I ruled out 30db on ATSC because that sounds incredibly high, I assumed cable because that would be consistent with the numbers. You could well be right. -- Steven Toth - Kernel Labs http://www.kernellabs.com I agree it's high, but certainly possible. I've got a 30 dB signal, but my situation is a bit unusual. I spent all of last night working on another issue, but I am hoping to get back to it this week. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 2:52 PM, David Ward david.w...@gatech.edu wrote: On 06/09/2009 10:24 AM, Steven Toth wrote: David has called out Comcast to review his installation. After replacing all the connectors and some cables from the pole all the way to the outlet, their meter ultimately showed 39-40dB at the outlet. My card is showing the same SNR values as before. Go figure. I want to say that the SNR counter for the s5h1409 caps out at 30dB, but I would have to double check the source code. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Tue, Jun 9, 2009 at 3:04 PM, Steven Toth st...@kernellabs.com wrote: 40db. -- Steven Toth - Kernel Labs http://www.kernellabs.com Just checked the source. It's 40dB for QAM256, but 30dB for ATSC and QAM64. Are we sure he's doing QAM256 and not QAM64? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Mon, Jun 8, 2009 at 10:14 AM, Steven Toth st...@kernellabs.com wrote: Please let me know how I should proceed in solving this. I would be happy to provide samples of captured video, results from new tests, etc. When you tune using azap, and you can see UNC and BER values, what is the SNR value and does it move over the course of 30 seconds? -- Steven Toth - Kernel Labs http://www.kernellabs.com Also, I believe UNC and BER display garbage when signal lock is lost, so do you see the status field change when the BER/UNC fields show data? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18, s5h1409: chronic bit errors, only under Linux
On Mon, Jun 8, 2009 at 5:03 PM, David Ward david.w...@gatech.edu wrote: Devin, I would really really appreciate this. I hesitated to e-mail this list for several weeks, because I wanted to investigate thoroughly first and avoid wasting anyone's time as much as possible. I hope you are able to reproduce this. Well, I've got a few different combinations of s5h1409 tuners and demods (including the HVR-1600), so if I can reproduce the issue, I can probably narrow it down as to whether it's a tuner or a demod issue. I've spent a good bit of time analyzing the s5h1409 driver in the past, although I don't have the datasheet for the chip. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: funny colors from XC5000 on big endian systems
On Sun, Jun 7, 2009 at 9:20 PM, Andy Wallsawa...@radix.net wrote: You may also want to check if CVBS or S-Video also shows the problem. A simple test that will conclusively eliminate the XC5000. Regards, Andy Well, it won't really be conclusive in this case - it's an intermittent bug in the hardware, and is much more likely to occur with the xc5000 because it happens when the signal needs to resync (the 16-bit YUYV byte pair sometimes is read on the wrong boundary). Hence it tends to occur more often with the xc5000 because of changing channels (but can occur on the CVBS or S-Video inputs as well). The au0828 driver has code to detect this condition but there might be an issue with the check. Once I know the answer to the questions posed to Mike, I can work with him to debug the issue. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: funny colors from XC5000 on big endian systems
On Sun, Jun 7, 2009 at 10:12 PM, W. Michael Petullom...@flyn.org wrote: Do you see the issue using tvtime? This will help isolate whether it's an application compatibility issue or whether it's related to endianness (and I do almost all my testing with tvtime). Tvtime works like a charm. The colors look fine. This is the first I've seen tvtime and it seems great. Now we may be getting off the topic, but does anyone know why xawtv, streamer and GStreamer's v4l2src would muck up the colors? Ok, that's good to know. Perhaps it's some difference in the way the v4l stream is read and the frames are dequeued (mmap versus read(), etc). You indicated that you had reason to believe it's a PowerPC issue. Is there any reason that you came to that conclusion other than that you're running on ppc? I'm not discounting the possibility, but it would be good to know if you have other information that supports your theory. It was a hypothesis, but based on experience in seeing endian bugs in video code and hearing endian bugs in audio code. After using PowerPC long enough, you learn to jump to the endian conclusion pretty quickly. I was wrong! Ok, well that's good to know. I did look at the code and couldn't see how it could possibly be an endianness bug. Bear in mind that the analog support for the 950q is still relatively new, and its entirely possible there are some application specific bugs to be worked out as there is more testing. Could you please describe in more detail the *exact* configuration you are attempting, including the versions of the applications you are using and command line arguments you are passing. If I can reproduce the issue here then I can probably debug it much faster. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] em28xx device mode detection based on endpoints
On Sat, May 23, 2009 at 11:05 AM, Markus Rechberger mrechber...@gmail.com wrote: Hi, On Sat, May 23, 2009 at 4:49 PM, Markus Rechberger mrechber...@gmail.com wrote: On Sat, May 23, 2009 at 4:04 PM, Markus Rechberger mrechber...@gmail.com wrote: Hi, for em28xx devices the device node detection can be based on the encoded endpoint address, for example EP 0x81 (USB IN, Interrupt), 0x82 (analog video EP), 0x83 (analog audio ep), 0x84 (mpeg-ts input EP). It is not necessary that digital TV devices have a frontend, the em28xx chip only specifies an MPEG-TS input EP. Following patch adds a check based on the Endpoints, although it might be extended that all devices match the possible devicenodes based on the endpoints, currently the driver registers an analog TV node by default for all unknown devices which is not necessarily correct, this patch disables the ATV node if no analog TV endpoint is available. attached patch fixes the deregistration, as well loads the em28xx-dvb module automatically as soon as an MPEG-TS endpoint was found. Signed-off-by: Markus Rechberger mrechber...@gmail.com best regards, Markus Hello Markus, I spent some time reviewing this patch, and the patch's content does not seem to match your description of its functionality. Further, this patch appears to be a combination of a number of several different changes, rather than being broken into separate patches. First off, I totally agree that the analog subsystem should not be loaded on devices such as em287[0-4]. I was going to do this work (using the chip id to determine analog support) but just had not had a chance to doing the necessary testing to ensure it did not break anything. The patch appears to be primarily for devices that are not supported in the kernel. In fact, the logic as written *only* gets used for unknown devices. Further, the code that doesn't create the frontend device has no application in the kernel. All devices currently in the kernel make use of the dvb frontend interface, so there is no practical application to loading the driver and setting up the isoc handlers but blocking access to the dvb frontend device. Aside from the code that selectively disables analog support, the patch only seems to advance compatibility with your userland em28xx framework while providing no benefit to the in-kernel driver. Regarding the possibility of custom firmware, we currently do not have any devices in the in-kernel driver that make use of custom firmware. If you could tell me how to check for custom firmware versus the default vendor firmware, I could potentially do a patch that uses the vendor registers unless custom firmware is installed, at which point we could have custom logic (such as using the endpoint definition). However, given there are no such devices in-kernel, this is not a high priority as far as I am concerned. For what it's worth, I did add an additional patch to allow the user to disable the 480Mbps check via a modprobe option (to avoid a regression for any of your existing customers), and I will be checking in the code to properly compute the isoc size for em2874/em2884 based on the vendor registers (even though there are currently no supported devices in the kernel that require it currently). However, I do not believe the patch you have proposed is appropriate for inclusion in the mainline kernel. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Wed, May 27, 2009 at 9:00 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Thu, 21 May 2009 22:26:35 -0400 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes for the following: em28xx: don't create the audio device if no onboard audio processor I don't think that this patch is right. There are some devices that are equipped with non ac97 audio processors, for example the ones with msp34xx. Those devices have digital audio. I'm not sure if they work with em28xx-audio or with snd-usb-audio. So, the safest way is not to deny the load of em28xx-audio. Mauro, The code does take into account devices that provide I2S audio. However, I think you may be correct that if I2S audio is configured, the driver will not load. I think I'm going to need to rework the patch a bit. The correct behavior should be that the em28xx-audio driver should only be loaded if vendor audio is required (either AC97 or I2S), and it appears that my logic didn't accomplish that [I confused an if() for an else if()]. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] fe status values
On Wed, May 27, 2009 at 6:59 AM, Markus Oliver Hahn markus.o.h...@gmx.de wrote: Hi there, I was just going throug the dvbapi 5.0 but I couldn`t find ow to interpret the values which I get by int ioctl( int fd, int request = FE_READ_SIGNAL_STRENGTH, int16_t *strength); and int ioctl(int fd, int request = FE_READ_SNR, int16_t *snr) strengt should be (signed) dBm and 0.snr dB is this right ? regards markus -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Hello Markus, Unfortunately, there is currently no standard way in which the return values can be interpreted. The content varies by demodulator. This has been discussed at length on the linux-media ML if you want to read the back history. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes-2
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes-2 for the following: em28xx: Don't let device work unless connected to a high speed USB port au0828: Don't let device work unless connected to a high speed USB port em28xx: Add support for the K-World 2800d tuner-core: fix warning introduced when cleaning up xc5000 init routine em28xx: provide module option to disable USB speed check au0828: provide module option to disable USB speed check The series changes the comment as you requested, adds a routine to allow advanced users to override the bus speed check (at their own risk), and removes the patch related to the loading of the em28xx-audio if no audio present. I will need to revisit that code and come up with the correct patch that works even with i2s audio. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] EPG (Electronic Program Guide) Tools
On Tue, May 26, 2009 at 1:51 PM, Chris Capon ttab...@gmail.com wrote: Hi: I've installed an HVR-1600 card in a Debian system to receive ATSC digital broadcasts here in Canada. Everything works great. scan /usr/share/dvb/atsc/us-ATSC-center-frequencies-8VSB channels.conf finds a complete list of broadcasters. azap -c channels.conf -r channel-name tunes in the stations and displays signal strength info. cp /dev/dvb/adapter0/dvr0 xx.mpg captures the output stream which can be played by mplayer. What I'm missing is information about the Electronic Program Guide (EPG). There doesn't seem to be much info on linuxtv.org on how to read it. Where does the EPG come from? Is it incorporated into the output stream through PID's some how or is it read from one of the other devices under adapter0? Are there simple command line tools to read it or do you have to write a custom program to interpret it somehow? Could someone please point me in the right direction to get started? If no tools exist, perhaps links to either api or lib docs/samples? Much appreciated. Chris. Hello Chris, The ATSC EPG is sent via the ATSC PSIP protocol. I do not know of any tools currently available to extract the information. MeTV has a working implementation (with some bugs I have seen), and I was looking at getting it to work in Kaffeine at some point. The spec is freely available here: http://www.atsc.org/standards/a_65cr1_with_amend_1.pdf If you have any questions, feel free to drop me a line. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add QAM64 support for hvr-950q (au8522)
On Tue, May 26, 2009 at 2:35 PM, Tim Mester ttmest...@gmail.com wrote: From my experience it seems that 2 in 0x2005 resets the 8522 demod. All demod register setting appear to be lost after accessing any registers in the 0x2xxx range (you really, just that bit needs to be set on a i2c bus access). I am a little surprised that 0x2000 is not written to the bus to for each modulation mode. Hmmm... I would have to look closer before I could comment intelligently. Resetting all the registers could be a bad idea if there are registers being programmed that are not in the modulation block (initialization parameters such as the IF setting). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] EPG (Electronic Program Guide) Tools
On Tue, May 26, 2009 at 3:18 PM, Jonathan Isom jei...@gmail.com wrote: Dvbstreamer supports atsc epg. That is what i use Well, learn something new every day. I didn't realize dvbstreamer had ATSC support. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix
On Mon, May 25, 2009 at 8:51 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Didn't work. Please submit me again after fixing the trouble. $ ./hgimport http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix Pushing from remote site http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix, tree: dvb-frontend-exit-fix rm: imposível remover `/tmp/newpatches/*': Arquivo ou diretório não encontrado abort: error: timed out Number of patches: 0 Sorry, we had some networking problems over the last couple of days. Everything is back up now, so please try again. Thank you, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add QAM64 support for hvr-950q (au8522)
On Mon, May 25, 2009 at 6:03 PM, Frank Dischner phaedrus...@googlemail.com wrote: While I'm at it, I thought I'd go ahead and make a patch to remove the top bits from the vsb table, but I've got a question about that. I think the first four entries are unnecessary. I'm pretty sure 8090 and 8091 have to do with the 8522's i2c controller and 4092 is a status register. I have no idea what 2005 is, but the new code would change it to A005 and I don't remember seeing either in any of the traces I did (though I never did a vsb trace). Is this correct or am I missing something? If I make a patch, can you or someone else test it for me? (can't get a signal here) Yeah, I noticed the 4092 entry. The 4 means it's a read operation so it almost certainly shouldn't be in the table. I just haven't taken the time to look closer at a Windows trace to see if it was *really* a register read operation that got stuck into the table or whether it was supposed to be a write operation. I haven't reviewed the VSB table yes, so I am not sure about the other entries. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: Temporary success with Pinnacle PCTV 801e (xc5000 chip)
On Sat, May 23, 2009 at 5:15 PM, N Klepeis li...@klepeis.net wrote: Hi, I installed the latest v4l-dvb from CVS with the latest firmware (dvb-fe-xc5000-1.6.114.fw) for the 801e (XC5000 chip). I can scan for channels no problem. But after a first use with either mplayer or mythtv, it then immediately stops working and won't start again until I unplug and then reinsert the device from the USB port. On the first time use everything seems fine and I can watch TV through mplayer for as long as I want. On the 2nd use (restart mplayer), there's an error (FE_GET_INFO error: 19, FD: 3). On the 2nd use with mythtv, mythtv cannot connect to the card at all in mythtvsetup, but on the first time use I can assign channel.conf. I know there have been recent updates to the xc5000 driver. I only started trying this chip this week so I never confirmed that any prior driver version worked. Any thoughts on how to proceed? Below are the full console outputs when using with mplayer and when running dmesg. (This is fedora 10). --Neil Neil, Already tracked down and a PULL has been requested for the patch: http://kernellabs.com/hg/~dheitmueller/dvb-frontend-exit-fix Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Review of the Linux driver for the TerraTec Cinergy HTC USB XS HD stick
On Fri, May 22, 2009 at 10:45 AM, Ad Denissen ad.denis...@hccnet.nl wrote: Hi Markus, I have a TerraTec Cinergy HTC USB XS HD stick and more than 10 years of experience with Linux (drivers). This USB stick works fine under Windows, but I need it under Linux for my MythTV experiments in DVB-C mode. Can I help you in the cleanup of the Linux driver for this device? Kind regards, Ad Denissen Hello Ad, The TerraTec Cinergy HTC USB XS HD makes use of the Micronas drx-k demodulator. There is currently no driver at all for this device in the mainline Linux kernel. As a result, getting the device to work in the mainline kernel is much more than cleanup. Markus's support for the drx-k uses his closed source product, and therefore is not eligible for inclusion in the Linux kernel. You may wish to contact him though if you are interested in a commercial closed source solution. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Review of the Linux driver for the TerraTec Cinergy HTC USB XS HD stick
On Fri, May 22, 2009 at 12:36 PM, Markus Rechberger mrechber...@gmail.com wrote: You still mistake that the important drivers are not implemented in Kernelspace, because of that there will never be a _requirement_ to merge the chipdrivers in order to get it work. For example DVB-C/T, all control commands are sent to the frontend device node all those commands are intercepted at userlevel while still being compatible with legacy applications like kaffeine or dvbscan. regards, Markus It wasn't really my intent to get into the details of your implementation (kernel space versus user space). The important message is that the solution you are providing is a commercial, closed source solution. If that meets his needs, then great. If Ad's goal is to get support into the Linux mainline, then it needs to be both open source and in the kernel. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Fri, May 22, 2009 at 9:48 PM, BOUWSMA Barry freebeer.bouw...@gmail.com wrote: On Thu, 21 May 2009, Devin Heitmueller wrote: em28xx: Don't let device work unless connected to a high speed USB port (grrr, dyndns addresses that are actually dynamically changing) | The em28xx basically just doesn't work at 12 Mbps. The isoc pipe needs | nearly 200 Mbps for analog support, so users would see garbage video, | and on | the DVB/ATSC side scanning is likely to work but if the user tried to | tune it | would certainly appear to have failed. | It's better to fail explicity up front and tell the user to plug into a | USB 2.0 Hi Devin, I've spent the last night trying to wrap my brane around the DVB code and how it reflects on the ability of hardware to perform PID filtering or not, thereby the expected load due to interrupts and filtering in the CPU. If my current machine is being fed a single stream from a lower-bandwidth source (not sure where the filtering to a crummy audio stream is being performed, but even the full bandwidth available from a 1,5MHz-wide chunk of spectrum is well within USB1.1), load is negligible. Multicasting the filtered data back out over a USB1.1 net adapter bumps up the interrupt load somewhat, but `top' idle time remains high. As soon as I toss a dvb-usb device into the mix, which is allegedly capable of doing internal PID filtering but which presently can't, delivering a full transport stream from a 27,5MSym/sec transponder, the interrupt level goes up, in spite of the fact that the content of interest is only a slightly less crummy audio stream of some 1/250 the full transponder datarate. However, as soon as I try to listen through the internal soundcard to one of these streams, the interrupt level goes up by nearly a factor of three, the machine drops to around only 50% idle, despite that there's no significant CPU- crunching application, and the responsiveness drops, with something comparable to stuttering observed frequently when I do something on the console. Also, the CPU temperature hovers around the point where the fan turns on. So, in spite of the individual things I do hardly being any load on the CPU in themselves, apparently the load caused by handling USB interrupts is more than additive. Bring on USB 3.0, I say... I've been spoiled by hardware which does the internal filtering, and barely causes my slower machines to break a sweat, except when I do have to handle a full TS or a higher-bandwidth HDTV stream, which it can still do, and so I decided to look at which of the different devices available today are capable of delivering a filtered TS, whether via USB or PCI -- primarily I only care for audio, at up to 320kbit/sec, that happily fits on the spare USB1.1 ports and normally doesn't cause any bother. Now, with that background, I see that the dvb-usb framework makes the hardware's ability to PID filter quite obvious, as well as the b2c2 flexcop hardware. Not all devices have this ability, apparently, and I still need to go over the code when more awake to make sense of it. Now I do know that at least some of the em28xx hardware does have the ability to selectively filter and deliver only the PIDs of interest at well within USB1 bandwidth for audio, or selected lower-quality DVB-T video. And you made mention of this some months back on the list, when asking if it was worth your time. That's the problem with these composite devices -- they are fine for such things as watching Freeview or listening to that radio, not so much for decent-quality cable (where it exists), no different to the many USB1.1 DVB-T or DVB-C devices, but they are useless for the remaining analogue sources on USB1.1. And they don't fit into the dvb-usb framework. In my dream world, the em28xx devices would determine what they can do (analogue or full transport stream) based on the USB connection, rather than simply refusing to work, provided the hardware is capable of filtering the DVB TS. But, you provide the source, so in theory I should be able to fine-tune it as I wish. (Note that my experience is based on DVB-T SD video, which so far has fit into USB1.1. I know that DVB-S H.264 HD video does not, and I would imagine that if HD ATSC is really using MPEG 2 rather than AVC video compression, it would need even more than the 16Mbit/sec I see from DVB-S, or the 10Mbit/sec expected with DVB-T2 later this year, which also wouldn't fit reliably on USB1.1 if my experience with decent quality SD in MPEG 2 is any guide on my hardware. So even hardware PID filtering is no guarantee of flawless performance, but again, the user can employ it in cases which would work. Caveat emptor. Cave canem. Carpe cavy.) Just some rambling comments there. Ignore me. barry bouwsma Hello Barry, The dvb core does have infrastructure to support hardware pid filtering. I don't know
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
On Thu, May 21, 2009 at 10:26 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes for the following: em28xx: don't create the audio device if no onboard audio processor em28xx: Add support for the K-World 2800d au0828: Don't let device work unless connected to a high speed USB port em28xx: Don't let device work unless connected to a high speed USB port Thank you, Devin Mauro, I tacked one more patch onto the end of this series, if you could please include it as well: tuner-core: fix warning introduced when cleaning up xc5000 init routine Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add QAM64 support for hvr-950q (au8522)
On Fri, May 1, 2009 at 11:17 PM, Frank Dischner phaedrus...@googlemail.com wrote: Here's the updated patch with the requested changes. Frank Hello Frank, Sorry for taking so long to get back to this. I looked at the patch, and in particular, I compared the values programmed for QAM256 against the table you provided for QAM64. The delta is only four registers (210, 211, 323, 502). This isn't terribly surprising. A few questions: Do you have the USB trace you used as the basis for this dump? And did you programatically parse that dump to generate the table, or did you enter it by hand? Could you please email me the underlying dump so I can double check the data? I think the correct approach here would be to have three tables, a table of common registers, and two tables, one for each modulation type. It would program the common registers first, and then pick the correct table to program the rest. If we are concerned about the order that the registers are being programmed in, we can just setup the two tables so they start at the first register which is different (since it is almost at the bottom of the table anyway). That said, do you want to take a crack at the above suggested refactoring and resubmit an updated patch, or would you prefer to have me check in this patch as-is, and then refactor it myself afterward. It's up to you. Cheers, Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/misc-fixes
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/misc-fixes for the following: em28xx: don't create the audio device if no onboard audio processor em28xx: Add support for the K-World 2800d au0828: Don't let device work unless connected to a high speed USB port em28xx: Don't let device work unless connected to a high speed USB port Thank you, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RE : Hauppauge Nova-TD-500 vs. T-500
On Wed, May 20, 2009 at 8:51 AM, Thierry Lelegard thierry.leleg...@tv-numeric.com wrote: I have a few more informations. 1) Sorry for those who don't like top posting, but the initial description is really too long for good readability of answers. 2) Since the TD-500 contains two aerial inputs instead of one for the T-500, I plugged in two antenna cables. Then, after some tests, I realized that this was a source of trouble: - Two antenna cables = lots of errors (mostly garbage sometimes, depending on the frequency). - Top input only = still many errors but much better on both tuners. - Bottom input only = got nothing on both tuners. So, from now on, I use only one antenna cable, in the top aerial input. Maybe this could be clarified somewhere (unless it is already but I missed it). 3) There are still many uncorrectable errors (TS packets with transport error indicator set) in the input. The amount of uncorrectable errors is approximately 0.1% (depending on the frequency), while I do not have any with the T-500 using the same antenna. These errors occurs in groups of +/- 50 consecutive packets with TEI set. Sometimes, in the middle of packets with errors, one packet has TEI clear but it is still erroneous (invalid PID in this context for instance). Note: I forgot to mention in the initial post that I set the following option: options dvb_usb_dib0700 force_lna_activation=1 4) There is apparently a minor but annoying problem in the driver concerning the ioctl FE_GET_INFO. Its usage requires opening the frontend device in O_RDWR mode with the TD-500. Comparison of T-500 vs. TD-500. a) After boot, before the first tuning, if we open the frontend in O_RDONLY more, the ioctl FE_GET_INFO succeeds with the TD-500 and the T-500. b) While another process uses the frontend for packet reception, the ioctl FE_GET_INFO succeeds with the TD-500 and the T-500, with frontend in O_RDONLY mode. c) After the frontend has been used for packet reception but no other process uses it any longer, the ioctl FE_GET_INFO fails with errno no such device with TD-500 frontend in O_RDONLY mode. However, the ioctl FE_GET_INFO succeeds with TD-500 frontend in O_RDWR mode. With the T-500, the ioctl FE_GET_INFO succeeds in O_RDONLY mode. Using O_RDWR mode for a simple ioctl FE_GET_INFO is a problem since it fails with device busy when another process is using it in O_RDWR mode for tuning and reception, which is normal. I see here two inconsistencies and one annoying feature: - Inconsistent behaviour of ioctl FE_GET_INFO in O_RDONLY mode before and after the first tuning. - Incorrect error no such device because /dev/dvb/adapter0/frontend0 is still there and useable in O_RDWR mode. - Obligation to use O_RDWR mode for reading the characteristics of a device. -Thierry -Message d'origine- De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Thierry Lelegard Envoyé : lundi 18 mai 2009 16:33 À : linux-media@vger.kernel.org Objet : Hauppauge Nova-TD-500 vs. T-500 Hello, Like many others, I have some problems with the Hauppauge Nova-TD-500. I have been running a Fedora system with one Hauppauge Nova-T-500 (-T-, with one input connector, not -TD-) quite successfully for 2 years. I just built another Fedora system and ordered two T-500 but I actually received two TD-500 (the one with two input connectors). So, I now have another Fedora box with two Hauppauge Nova-TD-500 and it does not work quite well. The two systems (the first one with one T-500 and the second one with two TD-500) are running the same O/S version, same drivers, same firmware: - Fedora 10, up-to-date as of 2009-05-17 - Kernel 2.6.27.21-170.2.56.fc10.i686 - Latest V4L-DVB mercurial tree, same date - Firmware dvb-usb-dib0700-1.20.fw You will find below some outputs of dmesg, lspci, etc for the two systems. I use custom signal monitoring applications, no TV watching apps. The same application is used in both systems, same antenna input (roof antenna and wall socket, not the small antenna that comes with the cards). The application continuously reads the complete transport stream for analysis. From time to time, it tunes to some frequency, then another, etc. With the two TD-500, the 4 adapters are created under /dev/dvb. Using them works more or less. As far as I tested now, I do not have any reported error, no error message. But the input is not good: many packets are corrupted. This does not happen all the time. Sometimes, the input is reasonably correct (a few packets seems incorrect) and sometimes it is a mess (most packets are incorrect, the result of the analysis report many non-existing PIDs, weird content, etc). I guess that most of you will say most probably an application pb... But the same application is working fine with: 1) Linux + Hauppauge Nova-T-500 2) Linux +
Re: RE : Hauppauge Nova-TD-500 vs. T-500
On Wed, May 20, 2009 at 9:40 AM, Thierry Lelegard thierry.leleg...@tv-numeric.com wrote: Hi Devin, Your fix works great. Thanks, -Thierry Thierry, Thanks for taking the time to test the change. Since the last change I made to dvb_frontend exposed the issue, I want to do some more testing before I issue a PULL request. I will try to do it when I get home from work tonight. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
xc5000 users: new firmware required!
The new xc5000 code was merged this morning, which requires users to update their firmware. If you updated to the latest v4l-dvb and your card stopped working, please download the updated firmware from this location, and install into the same directory as your previous version (typically /lib/firmware). http://www.kernellabs.com/firmware/xc5000/ Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fixed (Was:Re: saa7134/2.6.26 regression, noisy output)
On Mon, May 18, 2009 at 10:45 PM, hermann pitton hermann-pit...@arcor.de wrote: Guys, please. It looks like this still can go on for some while. I don't have the time and have zero income from all of this. Does the new entity, kernellabs.com, Devin, Mike and Steven for now, do confirm that this bug is assigned to them? (PCTV and Hauppauge) Or do you prefer to have it further drifting over the lists and call Hartmut and me for it? Cheers, Hermann Hello Hermann, I believe it makes sense for me to clarify this point: Kernel Labs is not affiliated with Hauppauge or PCTV in any way. We have not received any money from either company for Linux support for their products. One of Kernel Lab's long-term goals is indeed to find a way to provide some form of commercial support for devices such as this. It is probably fair to say that the three of us tend to focus on products by those vendors because of easy access to sample hardware, not because of any commercial arrangement. That said, Kernel Labs is about as responsible for fixing the problem as you are. ;-) Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/em28xx-isoc-fix
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/em28xx-isoc-fix for the following: em28xx: properly set packet size based on the device's eeprom configuration Thank you, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/xc5000-improvements-beta3
Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/xc5000-improvements-beta3 for the following: cx88: remove xc5000 reset for Pinnacle 800i xc5000: add copyright line au0828: send command to power down tuner when done with analog xc5000: poll at 5ms interval for register write command completion xc5000: add support for DVB-T tuning xc5000: switch to new xc5000 firmware 1.6.114 with redistribution rights dib0700: reduce xc5000 sleep time for Pinnacle 801e to 10ms tuner-xc2028: show the proper module description for no_poweroff option xc5000: don't load firmware until a tuning request is made xc5000: add no_poweroff module option xc5000: cleanup firmware loading messages xc5000: start using the newer finerfreq tuning command xc5000: add build version to debug info au0828: reduce reset time for xc5000 to 10ms xc5000: Properly support power down for newer firmware xc5000: switch to new version of Xceive firmware xc5000: do not sleep after digital tuning xc5000: restore sleep routine xc5000: check xc5000_readreg return value for XC_RESULT_SUCCESS xc5000: cleanup i2c write routines xc5000: cleanup i2c read routines xc5000: handle tuner reset failures properly dvb_frontend: fix race condition resulting in dropped tuning commands cx88: Fix race condition between cx8800 startup and hald -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://kernellabs.com/hg/~dheitmueller/xc5000-improvements-beta3
On Thu, May 14, 2009 at 9:28 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hello Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/xc5000-improvements-beta3 for the following: Mauro, I just renamed the tree, it can be found here now: http://kernellabs.com/hg/~dheitmueller/xc5000/ -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/au0828-oldkernel-compilefix
Mauro, Please pull from http://kernellabs.com/hg/~dheitmueller/au0828-oldkernel-compilefix for the following fix (an error detected with Han's daily build tool): au0828: get rid of debug printk that was causing compile failures Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://endr...@linuxtv.org/hg/~endriss/v4l-dvb
On Wed, May 13, 2009 at 2:52 AM, Trent Piepho xy...@speakeasy.org wrote: On Wed, 13 May 2009, Oliver Endriss wrote: 02/05: dvb-ttpci: Check transport error indicator flag http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=8a742338523d Are you sure this is a good idea? The cx88 driver doesn't do this. -- 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 I agree with Trent on this one - dropping the packet at the hardware level is a bad idea. If the demodulator is incapable of setting the TEI bit (which most do) and you are forced to rely on the TSERR line, then you should be marking the TEI bit and passing the packet on. Dropping the packet at the hardware level is likely to cause confusion for app developers (why am I only getting 60% of the expected packets?) Like I said above though, in most cases I've seen the demod does all the work and there is no need to act on the TSERR line at all. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
On Wed, May 13, 2009 at 2:13 AM, kenny wang smartke...@gmail.com wrote: Hi, Devin I found another problem for my WinTV-HVR-950Q, but I am not sure if it's caused by the device driver: my tvtime sometimes (not often) lost all channels and shows a blue window. Switching channel doesn't take the channel back. I have to close tvtime and open it again, then it works normally. Don't know if it's tvtime's problem. Don't remember if the previous version has the same problem (probably does). And I don't know how to debug it or where to view any log of it. Thanks. Hello Kenny, Does the blue screen occur when you switch channels? Or does it occur when you are currently watching a channel? It's possible there is a problem where the tuning command gets screwed up. Can you give me an idea how often it occurs? One time a minute? One time an hour? One time a day? And if you could please send me a dump of dmesg the next time it happens that would help too. I suspect this is not related to the xc5000 changes. It's probably a glitch in the original 950q analog work that just hasn't been noticed yet. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://endr...@linuxtv.org/hg/~endriss/v4l-dvb
On Wed, May 13, 2009 at 12:29 PM, Oliver Endriss o.endr...@gmx.de wrote: What are you talking about? This patch does not have any impact on the reception path (from tuner to application). It just discards bogus data which might crash the av7110 or cause chirping sound during replay. Like I said above though, in most cases I've seen the demod does all the work and there is no need to act on the TSERR line at all. See above. Oliver Oh, this is a decoder, not a bridge. Nevermind. My bad. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
On Wed, May 13, 2009 at 3:04 PM, Timothy D. Lenz tl...@vorgon.com wrote: So when this goes main, next time we update from v4l we need the new firmware right? Yes. Now that we have the licensing straightened out, I'll also be working on getting it bundled into the distros so that users don't have to download the firmware themselves. They will get a true plug and play experience. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
On Wed, May 13, 2009 at 6:26 PM, Vanessa Ezekowitz Devin, does this license/bundle arrangement also cover the firmware for xc3028-based devices? Unfortunately, it does not. Once I get the xc5000 stuff in though, I am planning on approaching them about getting firmware licensing under the same terms for xc3028, xc3028L, and xc4000. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Not only TV LV5H hybrid tv card
On Tue, May 12, 2009 at 1:46 PM, Martin Kragelund martin.kragel...@gmail.com wrote: Hi, I have just bought the Not only TV (LV5H) tv-card which should be equipped with the em28xx chip - I'm trying to get it to work in ubuntu (8.10) but it doesn't work completely. I've attached the output from dmesg below. I'm a bit new to linux and don't know how to use the insmod command as suggested in the dmesg output Best Regards, Martin My queue of em28xx devices I'm adding support for is already three or four deep. Ask again in a couple of weeks and I will see what I can do to get this one working. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
On Tue, May 12, 2009 at 4:50 PM, Britney Fransen britney.fran...@gmail.com wrote: I finally had some time to do some more testing with the beta2 tree and I think most of the issues I had were user error. Not exactly sure what I did wrong before but I am not seeing the reception issues or any regressions on the digital side anymore. I think why I thought I was seeing QAM64 was because I was using the wrong tuner. With the beta2 tree my 950q is now adapter1, before it was always adapter2. That could be part of what I thought was the reception regression as well. Thanks, Britney Hello Britney, Thank you for taking the time to isolate/debug the situation. The changes should have no effect on the order of adapter1/adapter2. Could have just been a coincidence or the order in which you plugged in the devices compared to what they usually are at boot time. Glad to see that there are no longer any issues. Once I get one outstanding Pinnacle 800i fix in, I will issue a PULL request and this will go into the mainline. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/4] zoran: fix /|| error
On Tue, May 12, 2009 at 4:39 PM, a...@linux-foundation.org wrote: From: Roel Kluin roel.kl...@gmail.com Fix /|| typo. `default_norm' can be 0 (PAL), 1 (NTSC) or 2 (SECAM), the condition tested was impossible. Signed-off-by: Roel Kluin roel.kl...@gmail.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Andrew Morton a...@linux-foundation.org --- Hello, Was the patch actually tested against the hardware in question? While I agree that it looks ok, it can result in the default logic being inverted in some cases, which could expose other bugs and result in a regression. I just want to be confident that this patch was tested by somebody with the hardware and it isn't going into the codebase because it obviously cannot be right. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
On Thu, May 7, 2009 at 7:21 AM, John R. jo...@wowway.com wrote: After some off-list pointers by Devin, I tracked this down to user error. I thought I was compiling tip for xc5000-improvements-beta but was not. This is now working and composite input video works well on my 950Q. I notice no difference from previous version (wouldn't really expect to based on changes). Thanks, John Glad to hear it's working for you. If you're using composite, then you will not see the benefits of the tuning performance, but you *will* see the power management benefits. This means the tuner chip won't be enabled when you're not watching TV, which will result in not causing as much drain on your battery (if you have a laptop) and the device will be much cooler. I am still looking for strategies in the code so that the tuner is not enabled when capturing on composite or s-video (which will reduce power consumption further), but the code changes are non-trivial. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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
