Re: Driver crash on kernel 2.6.32.7. Interaction between cx8800 (DVB-S) and USB HVR Hauppauge 950q
On Tue, Feb 9, 2010 at 9:14 PM, Andy Walls awa...@radix.net wrote: Both Ooops below are related to userspace loading of firmware for the HVR-950Q. Very strange. The xc5000 function doesn't appear to really do anything unusual. It calls request_firmware(), pushes the code into the chip, and then call release_firmware() [see xc5000.c:xc5000_fwupload() ] One thing that does jump out at me which could be problematic is the function will call release_firmware() even if request_firmware() fails. I doubt that is the correct behavior. And combined with the fact that his dmesg shows the error run_program: '/lib/udev/firmware.sh' abnormal exit makes me wonder if the subsequent to release_firmware() despite the error condition is what is causing the problem. The other thing that is a bit unusual about the xc5000 in this particular case is the time to load the firmware is exceptionally long (around 7 seconds) due to a hardware bug in the au0828 which requires us to run the i2c bus at a very slow rate. Hence, it's possible that the unusually long time between request_firmware() and release_firmware() has exposed some sort of race in the firmware loading core. It would be useful if we could get the full dmesg output so we can get some more context leading up to the oops. Also, it would be helpful if the user could enable the debug=1 in the xc5000 modprobe options. One more question: is the user doing any suspend/resume operations? For example, is this a laptop in which he is closing the lid and this is the first attempt to use the device after resume? 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: Driver crash on kernel 2.6.32.7. Interaction between cx8800 (DVB-S) and USB HVR Hauppauge 950q
On Tue, Feb 9, 2010 at 10:05 PM, Richard Lemieux rlem...@cooptel.qc.ca wrote: Andy, This is a great answer! Thanks very much. When I get into this situation again I will know what to look for. A possible reason why I got into this problem in the first place is that I tried many combinations of parameters with mplayer and azap in order to learn how to use the USB tuner in both the ATSC and the NTSC mode. I will look back in the terminal history to see if I can find anything. I think the key to figuring out the bug at this point is you finding a sequence where you can reliably reproduce the oops. If we have that, then I can start giving you some code to try which we can see if it addresses the problem. For example, I would start by giving you a fix which results in us not calling the firmware release if the request_firmware() call failed, but it wouldn't be much help if you could not definitively tell me if the problem is fixed. 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: Any saa711x users out there?
Hi Andy, Thanks for taking the time to do some testing in your environment. On Sun, Feb 7, 2010 at 7:10 PM, Andy Walls awa...@radix.net wrote: My observations: 1. With the amplifier on and anti-alias filter off things looked fine. 2. With the amplifier on and anti-alias filter on things looked fine. 3. With the amplifier off and anti-alias filter off things looked fine. 4. With the amplifier off and anti-alias filter on the screen washed brighter/whiter. I guess the anti-alias filter peaks the luma a little or attenuates the color a little. The amplifier and AGC is probably essential when using the anti-alias filter. This all looks like good news, suggesting that under most conditions people won't notice the difference (except in the signal conditions I saw, in which case they will see a rather significant positive improvement). And since we don't let users independently control the AA filter nor the amplifier, we can be confident that there won't be a case when the amplifier is on but the AA filter is off. My vote is to just push the one line change then flipping on the AA filter in the saa7115_init_misc array of registers (essentially the patch below): http://kernellabs.com/hg/~dheitmueller/em28xx-test/rev/42272c1dd883 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] dvb-core: fix initialization of feeds list in demux filter (Was: Videotext application crashes the kernel due to DVB-demux patch)
Hello Mr. Shack, On Mon, Feb 8, 2010 at 8:43 AM, Chicken Shack chicken.sh...@gmx.de wrote: I vote for Andy Walls, Devin Heitmueller. There are a couple of capable candidates here who can really do that job with a better output for the whole Linux community. There is ABSOLUTELY NO necessity to continue with Mauro Carvalho Chehab. I want to take this opportunity to thank you for your nomination and vote. It means so much to me to see this nomination coming from such a dedicated contributor to the project, given your years of service and hundreds of patches to the LinuxTV project. sarcasm mode off I've quietly sat back and watched this thread over the last few days. I've watched your abusive and condescending attitude toward the volunteers who have spent their limited time trying to help resolve the issue you reported. You seem to have forgotten that you are dealing with a group of volunteers, and that they have absolutely *no* obligation whatsoever to help you in making your application work. As a user, I can appreciate your frustration: your application used to work and now it doesn't. But *demanding* that developers stop what they are doing to fix your problem is not particularly productive. Unless you are cutting them a check, they have no obligation to do what you want. Was there a regression? Yup. Shit happens. Let's focus on what needs to be done to fix it. While you interpreted the extended thread of discussion of various options as counter-productive, this is actually how development works. Somebody reports a problem. Developers discuss the various potential approaches available to deal with the problem. Other developers point out why those approaches aren't appropriate or could cause other issues. When you are dumb, you surround yourself with smart people. When you are smart, you surround yourself with smart people who disagree with you. In this case, while not doubting the reported problem was valid, the notion of rolling back functionality that made it into a stable kernel in order to address the problem is something that isn't desirable. The best case is when a fix can be made while preserving compatibility with both usage patterns. When that isn't possible, then hard decisions need to be made. And as someone who has both fixed bugs in the DVB core as well as having introduced them, I can appreciate how hard it can be to understand that piece of code. It's an inherently complicated problem, involving multiple threads of execution and concurrency, as well as a large number of applications that use the API in different ways. With regards to your concerns about Mauro being the maintainer, what can I say? Does he make mistakes? Sure. Does he sometimes do things I disagree with? Yup. Would I want his job? Absolutely not. It's a thankless job and people only notice what you do when you make a mistake. He has to evaluate patches not just in terms of how they effect whatever tuner the developer submitted them for, but also for all the other products that use the same code. When people submit patches that effect application behavior, he has put forth his best effort to ensure that it doesn't break other applications. This is a nontrivial exercise, and we should be thankful that Mauro has been willing to do it for as long as he has (most maintainers of large codebases experience burn out after a relatively short period of time). One of the things that is so empowering about open source is the ability to fix your own problems if it matters enough to you. You have the full source code to all the components, and if some issue is critical to you then you have everything you need to fix your own problems. You are only limited by your own commitment to learn how to program. Now I'm going to go back to working on my driver 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: Driver crash on kernel 2.6.32.7. Interaction between cx8800 (DVB-S) and USB HVR Hauppauge 950q
On Mon, Feb 8, 2010 at 11:43 PM, Richard Lemieux rlem...@cooptel.qc.ca wrote: Hi, I got some driver crashes after upgrading to kernel 2.6.32.7. It seems that activating either TBS8920 (DVB-S) and HVR950Q (ATSC) after the other one has run (and is no longer in use by an application) triggers a driver crash. Hello Richard, Have you tried any other kernel version? For example, do you know that it works properly in 2.6.32.6? Can you bisect and see when the problem was introduced? 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: Any saa711x users out there?
On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls awa...@radix.net wrote: With all that said, if you have a baseband Luma or Chroma signal with strong spurious high frequency components (crappy source, or you're overdriving the front end and getting intermods), then keep the anti-alias filter turned on as the assumption of a bandlimited input signal is violated in this case. In this case, I'm seeing it with both the analog signal generator (which one might consider a fairly pristine source), as well coming off the s-video output of a DirectTV box (in which case the signal is being generated only a few feet away from the saa7113). In the SAA7113 the anti-alias filter introduces a delay of 50 ns. At 13.5 Mpixels/sec, or 74.1 ns/pixel, that's less than 1 pixel time of delay. Just turn it on in and leave it on in the SAA7113 to handle the unexpected input signal case. This would be my vote (assuming we try it with the other parts and confirm no regressions are introduced). My only concern is the way the code is currently written, the saa7113 initialization block actually does enable it by default, and then some code for the saa7115 tramples the register, turning it off (see saa7115_init_misc at saa7115.c:600). I think the decision we have to make is which of the following paths to take: 1. Enable it in the saa7115_init_misc, thereby enabling it for the 7113, 7114, and 7115. 2. Exclude the saa7115_init_misc block from being run at all against the 7113 3. Let the saa7115_init_misc block get run, and then flip the bit back for the 7113. My thinking at this point is that the AA filter should probably be on by default regardless of the chip, in which case we would just need to make the one line change to enable it in the saa7115_init_misc block. 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: Any saa711x users out there?
Hey Andy, On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls awa...@radix.net wrote: Hmmm. The AGC (or static gain level?) of the amplifier in the SAA7113 before the anti-alias filter may be set too high causing the clipping (intermods) there. It may be worth looking at the gain setting for that amp. It's possible. One thing I did as a test though was I did a capture of the i2c traffic under Windows (using the same reference video source), and then compared the register programming (via some scripts I whipped up). There were some other registers that were different, but the only one that made *any* visible difference in the output was the AA flag. The visible effects of the anti-alais filter could possibly be: 1. Less range of color, if high freqs of the color get attenuated. (Most people likely will not perceive this as most people are not that sensitive to small color variations.) 2. Loss of rapid variations in Luma - softer edges between light and dark areas on a scan line - if higher freqs of the Luma get attenuated. but given that the anti-alais filter is essentially flat out to about 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I doubt anyone would ever notice it is on with NTSC. To give you a better idea of what I'm talking about, look at this image: http://imagebin.org/83458 The above image was taken with the generator via the s-video input (ruling out the possibility that it's any sort of product of intermodulation). For the sake of comparison, here's the exact same signal source against an a similar em28xx design but with the tvp5150. http://imagebin.org/83459 Since you have a signal generator, you should run experiments with PAL-D and SECAM-D with a grid containing vertical lines since those both have a 6.0 MHz video bandwidth. SECAM also has FM color, so you might see the greatest affect of an antialias filter on color on the Cyan color bar in SECAM-D. Believe it or not, I'm actually having trouble with the generator right now with anything but NTSC. I'm going back and forth with Promax on repair options. So I cannot do any PAL or SECAM testing right now. On a separate note, I really should look at extending the v4l2 capture-example to a version that let's me do a direct capture of the YUYV frame and convert the output into a zero-loss RGB format. It's too easy to be mislead by things the applications are doing like deinterlacing, rescaling, blending, and compression of the screenshot when saving to a file. 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: Any saa711x users out there?
On Tue, Feb 2, 2010 at 7:29 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The better is to allow enabling/disabling the anti-alias via ctrl. Whatever default is chosen, the driver may adjust the control default at the board initialization, or even blocking the control when the other mode of operation is broken. I have here a few devices with saa7113 and saa7114. I think I have also one device with saa7111, but I need to check. If I'm right, it will take some time for me to prepare the saa7111 environment. The saa7113/7114 devices are easier to setup, as they are usb. I actually am not very familiar with how custom controls work for v4l devices in terms of board specific configuration, as I'm more familiar with the way that you can provide a config struct during dvb_attach() for DVB devices. I've obviously seen how they can be set from userland, but have never dug into the specific as to how a bridge would set the parameters. I actually have a test tree here which includes the change (as well as a couple of unrelated em28xx fixes I'm working on). http://www.kernellabs.com/hg/~dheitmueller/em28xx-test The change in that tree just flips on the Anti-alias filter bit in the saa7115_misc_init struct, so it ends up being applied for 7113/7114/7115. However, I'm wondering if it makes sense to just have it on by default for all three boards (which is a *much* simpler change than adding a custom control and making sure it gets set properly by the bridge in all the various cases such as surviving a powerdown/powerup of the chip). BTW, the tree above just forces the bit on for all three boards - I'm not proposing that should be the final fix, but it is enough to allow people to evaluate the effects of the change. I've got a PVR-350 board with a saa7115 which I will do some testing on. If I see the artifacts on that board without the change, that bolsters the argument that the current default may just be wrong in general. Mauro, the hg logs suggest that you added the saa7115 support (and in fact appear to have introduced the issue in question). Do you remember what board you were using when you added the support? Also, how did you arrive at the defaults that you used? Were they based on some sort of i2c bus trace, or did you just set them by reading the datasheet? 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 13/15] - xc2028 bugfix for firmware 3.6 - Zarlink use without shift in DTV8 or DTV78
On Wed, Feb 3, 2010 at 3:36 PM, Stefan Ringel stefan.rin...@arcor.de wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1114,7 +1122,11 @@ static int xc2028_set_params(struct dvb_frontend *fe,
/* All S-code tables need a 200kHz shift */
if (priv-ctrl.demod) {
- demod = priv-ctrl.demod + 200;
+ if ((priv-ctrl.fname == xc3028L-v36.fw) (priv-ctrl.demod
== XC3028_FE_ZARLINK456) ((type DTV78) | (type DTV8)) ) {
+ demod = priv-ctrl.demod;
+ } else {
+ demod = priv-ctrl.demod + 200;
+ }
/*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
@@ -1123,8 +1135,8 @@ static int xc2028_set_params(struct dvb_frontend *fe,
* use this firmware after initialization, but a tune to a UHF
* channel should then cause DTV78 to be used.
*/
- if (type DTV7)
- demod += 500;
+ if (type DTV7)
+ demod += 500;
}
Independent of the validity of this patch, you should not be
submitting patches that have a mix of whitespace changes and actual
changes. In the above case (the if type DTV7 part), it looks like
these shouldn't have been included at all since it makes no functional
change.
It sounds like a nit-pick, but the reality is that its inclusion had
me staring at it for 30 seconds trying to figure out whether there was
an *actual* difference there or if it was purely whitespace.
return generic_set_freq(fe, p-frequency,
@@ -1240,6 +1252,10 @@ static const struct dvb_tuner_ops
xc2028_dvb_tuner_ops = {
.get_rf_strength = xc2028_signal,
.set_params = xc2028_set_params,
.sleep = xc2028_sleep,
+#if 0
+ int (*get_bandwidth)(struct dvb_frontend *fe, u32 *bandwidth);
+ int (*get_status)(struct dvb_frontend *fe, u32 *status);
+#endif
};
Likewise, you should not be including unrelated changes in patches -
the above #if 0 section not only is never compiled in to the code
(presumably it is debug code), but it has nothing to do with the fix
this patch is claiming to address.
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 15/15] - tm6000 hack with different demodulator parameter
On Wed, Feb 3, 2010 at 3:40 PM, Stefan Ringel stefan.rin...@arcor.de wrote: signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- a/drivers/staging/tm6000/hack.c +++ b/drivers/staging/tm6000/hack.c snip This patch shouldn't be merged at all. You should figure out the correct zl10353_config that is required, and hold off on submission until you have the correct fix. 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 14/15] - zl10353
On Wed, Feb 3, 2010 at 3:38 PM, Stefan Ringel stefan.rin...@arcor.de wrote: signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- a/drivers/media/dvb/frontends/zl10353.h +++ b/drivers/media/dvb/frontends/zl10353.h @@ -45,6 +45,8 @@ struct zl10353_config /* clock control registers (0x51-0x54) */ u8 clock_ctl_1; /* default: 0x46 */ u8 pll_0; /* default: 0x15 */ + + int tm6000:1; }; Why is this being submitted as its own patch? It is code that is not used by *anything*. If you really did require a new field in the zl10353 config, that field should be added in the same patch as whatever requires 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: [PATCH 12/15] - tm6000 bugfix tuner reset time and tuner param
On Wed, Feb 3, 2010 at 3:31 PM, Stefan Ringel stefan.rin...@arcor.de wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -221,12 +239,13 @@ struct usb_device_id tm6000_id_table [] = {
{ USB_DEVICE(0x2040, 0x6600), .driver_info =
TM6010_BOARD_HAUPPAUGE_900H },
{ USB_DEVICE(0x6000, 0xdec0), .driver_info =
TM6010_BOARD_BEHOLD_WANDER },
{ USB_DEVICE(0x6000, 0xdec1), .driver_info =
TM6010_BOARD_BEHOLD_VOYAGER },
{ USB_DEVICE(0x0ccd, 0x0086), .driver_info =
TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
{ },
};
/* Tuner callback to provide the proper gpio changes needed for xc2028 */
-static int tm6000_tuner_callback(void *ptr, int component, int command,
int arg)
+int tm6000_tuner_callback(void *ptr, int component, int command, int arg)
{
Why was the static removed from this declaration? What could possibly
be calling this from outside the module? And if there were something
that needed it, the declaration would have to be moved to a header
file so it could be included elsewhere (which should be in this same
patch).
Just to be clear, the fact that I am going through these patches
should not be taken personally - I'm just trying to give you some
advice on what you need to do to ensure the patches can be accepted
upstream and be reviewed with minimal cost to the other developers.
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/15] - tm6000.h
On Wed, Feb 3, 2010 at 3:50 PM, Stefan Ringel stefan.rin...@arcor.de wrote:
Am 03.02.2010 21:25, schrieb Mauro Carvalho Chehab:
This one is a very obscure patch. What are you doing this patch and why?
Stefan Ringel wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -90,12 +97,14 @@ enum tm6000_core_state {
DEV_MISCONFIGURED = 0x04,
};
+#if 1
/* io methods */
enum tm6000_io_method {
IO_NONE,
IO_READ,
IO_MMAP,
};
+#endif
? different between git and hg ? not mine
Stefan,
The patches *you submitted* included this #if 1. Regardless of
whether it's differences between git and hg or some other weird merge
bug, you are responsible for the patches you submit. You should be
reviewing each patch before sending it, and if it contains things you
do not understand why they are there, then you need to resolve those
inconsistencies before submitting the patch.
Reviewing each patch individually before sending also helps avoid
avoid things like submitting patches which make arbitrary/unnecessary
whitespace changes.
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
Any saa711x users out there?
Hello all, I am doing some quality improvements for a couple of the em28xx/saa7113 designs, and I found a pretty serious problem which appears to have been there for some time. In fact, the regression was introduced when the saa7115 support was added in 2005 (hg revision 2750). This change resulted in the anti-alias filtering being disabled by default for the saa7113 (the saa7115_init_misc block clears bit 7 of register 0x02). Without this change, vertical lines appear in the chroma on a fixed interval. The big issue is that the driver is shared with other saa7113 products, as well as products that have the saa7111, saa7114, and saa7115. So I have to figure out whether to just force on the AA filter for the saa7113, or whether it should be enabled for the others, or whether I can even turn it on for saa7113 in general or need to hack something in there to only do it for the two or three products I am testing with. So here's where I could use some help: If you have a product that uses one of the above chips, please speak up. I will be setting up a test tree where people can try out the change and see if it makes their situation better, worse, or no change. 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: dmesg output with Pinnacle PCTV USB Stick
On Mon, Feb 1, 2010 at 2:49 PM, Arnaud Boy psyka...@gmail.com wrote: Hi! I've a card PINNACLE PCTV HYBRID PRO (2) with the PCI ID 0x2304:0x0226. This is work on analog mode but the em28xx module don't register dvb interface. I think the card could work if we uncomment the commented part in the section [EM2882_BOARD_PINNACLE_HYBRID_PRO] from the /linux/drivers/media/video/em28xx/em28xx-cards.c file and we add his reference card at the /linux/drivers/media/video/em28xx/em28xx-dvb.c You can(must?) explain me why we couldn't have this card work with your driver. The 2304:0226 is the PCTV 330e. The DVB side is not currently supported do to issues with the drx-d driver. Search the linux-media archives for 330e for the history of 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: [PATCH] - tm6000 DVB support
On Mon, Feb 1, 2010 at 3:35 PM, Stefan Ringel stefan.rin...@arcor.de wrote: add Terratec Cinergy Hybrid XE bugfix i2c transfer add frontend callback add init for tm6010 add digital-init for tm6010 add callback for analog/digital switch bugfix usb transfer in DVB-mode signed-off-by: Stefan Ringel stefan.rin...@arcor.de Hi Stefan, It's good to see you're making progress. However, this is going to need *alot* of work before it will be able to be accepted upstream. You should start by breaking it down into a patch series, so that the incremental changes can be reviewed. That will allow you to explain in the patch descriptions why all the individual changes you have made are required. However, I will try to put some of my thoughts down based on the quick glance I took at the patch. Why did you define a new callback for changing the tuner mode? We have successfully provided infrastructure on other bridges to toggle GPIOs when changing modes. For example, the em28xx has fields in the board profile that allow you to toggle GPIOs when going back and forth between digital and analog mode. You've got a bunch of changes in the xc3028 tuner that will *definitely* need close inspection and would need to be validated on a variety of products using the xc3028 before they could be accepted upstream. While you have done what you felt was necessary to make it work for your board, this cannot be at the cost of possible regressions to other products that are already supported. You really should look into fixing whatever is screwed up in the tm6000 i2c implementation so that the read support works, rather than relying on nothing ever having to perform a read operation. What function does the tm6000 member in the zl10353 config do? It doesn't seem to be used anywhere. There are a bunch of codingstyle issues which will need to be fixed. My foremost concerns are obviously the things that touch other drivers, since your work could cause regressions/breakage for other boards, which is actually much worse than your board not being supported. -- 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] - tm6000 DVB support
On Mon, Feb 1, 2010 at 4:23 PM, Stefan Ringel stefan.rin...@arcor.de wrote: You should start by breaking it down into a patch series, so that the incremental changes can be reviewed. That will allow you to explain in the patch descriptions why all the individual changes you have made are required. how can I generate it? You can use quilt to break it up into a patch series, or create a local hg clone of v4l-dvb. Why did you define a new callback for changing the tuner mode? We have successfully provided infrastructure on other bridges to toggle GPIOs when changing modes. For example, the em28xx has fields in the board profile that allow you to toggle GPIOs when going back and forth between digital and analog mode. I don't know, how you mean it. I'm amateur programmer. Look at how the .dvb_gpio and .gpio fields are used in the board profiles in em28xx-cards.c. We toggle the GPIOs when switching the from analog to digital mode, without the tuner having to do any sort of callback. What function does the tm6000 member in the zl10353 config do? It doesn't seem to be used anywhere. I'll switch it next week to demodulator module. Are you saying the zl10353 isn't working right now in your patch? I'm a bit confused. If it doesn't work, then your patch title is a bit misleading since it suggests that your patch provides DVB support for the tm6000. If it does work, then the tm6000 member shouldn't be needed at all in the zl10353 config. 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: Make failed - standard ubuntu 9.10
On Fri, Jan 29, 2010 at 11:02 AM, David Henig dhhe...@googlemail.com wrote: Thanks, I appear to have the headers and no longer have to do the symlink, but still getting the same error - any help gratefully received, or do I need to get a vanilla kernel? Open up the file v4l/.config and change the line for firedtv from =m to =n. Then run make. This is a known packaging bug in Ubuntu's kernel headers. 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: cx18 fix patches
Hi Andy, On Thu, Jan 28, 2010 at 9:24 PM, Andy Walls awa...@radix.net wrote: Devin, I found interesting system interactions. On my dual core x86_64 Fedora 12 machine loading an HVR-1600 cold (no firmware has been loaded yet), the pulseaudio daemon opens up a CX23418 ALSA node almost immediately after it appears and has these effects: 1. Pulseaudio tries to perform some sort of op that starts a capture on the PCM stream before the APU and CPU firmware has finished loading. This results in error messages in the log and probably an undesirable driver state, if there was never any firmware loaded prior - such as at power up. I'm a little surprised by that, since the cx18-alsa module is only initialized after the rest of the cx18 driver is loaded. 2. Pulseaudio grabs the ALSA control node for the CX23418 and won't let go. If I kill the Pulseaudio process that has the node open, it just respawns and grabs the control node again. This prevents unloading the cx18-alsa and cx18 module. As far as I know, this is one of those dumb Pulseaudio things. Doesn't it do this with all PCI cards that provide ALSA? 3. If Pulseaudio also keeps the PCM analog stream going, then TV image settings are fixed to the values at the time Pulseaudio started the stream. I don't think it does, but I'm not sure yet. I know that Pulseaudio binds to the device, but as far as I know it does not actually open the PCM device for streaming. My off the cuff ideas for fixes are: 1. Integrate cx18-alsa functions into the driver and no longer have it as a module, to better coordinate firmware loading with the ALSA nodes. (The modular architecture appears to have been a bad choice on my part.) I'm not against merging the two into a single module, although it's not clear to me that it will help with the issues you are seeing. 2. Add a module option to disable setting up the cx18-alsa device nodes. I can see some value in such an option in general for debugging purposes, although I don't think it provides a whole lot of value for regular users who would not normally have it enabled. I'll try to work on these this Friday and Saturday. I will be out of town this weekend, but if you send me email I will try to respond as promptly as possible. 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 fix patches
On Fri, Jan 29, 2010 at 1:40 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: I doubt it would solve. IMO, having it modular is good, since you may not need cx18 alsa on all devices. Modularity is good, but we really need to rethink about the way we are loading these modules (this applies to dvb as well). For example, on em28xx, the dvb module is often getting loaded while at the same that hald is connecting to the v4l2 device (resulting in i2c errors while attempting to talk to tvp5150). A simple initialization lock would seem like a good idea, except that doesn't really work because the em28xx submodules get loaded asynchronously. And the problem isn't specific to em28xx by any means. I've hit comparable bugs in cx88. If we didn't load the modules asynchronously, then at least we would be able to hold the lock throughout the entire device initialization (ensuring that nobody can connect to the v4l2 device while the dvb and alsa drivers are initializing). Sure, it in theory adds a second or two to the module load (depending on the device), but we would have a much simpler model that would be less prone to race conditions. We would also lose the ability to modprobe the dvb module after-the-fact (and expect it to bind to existing devices), but I don't really think that would be a big deal since everything is auto-detected anyway. In fact, it might actually be a good thing given the number of times I've had to explain to people that you cannot do modprobe em28xx-dvb on an unsupported device and expect it to magically start working. I didn't mean to hijack the thread, but I'm just trying to point out that this is a pretty widespread problem, and not specific to cx18. 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 fix patches
On Fri, Jan 29, 2010 at 2:59 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The asynchronous load were added not to improve the boot load time, but to avoid some troubles that happens when the load is synchronous. I don't remember what were the exact trouble, but I suspect that it was something related to i2c. The result was that, sometimes, the driver used to enter into a deadlock state (something like driver A waits for driver B to load, but, as driver B needs functions provided by driver A, both are put into sleep). It would be good if you could locate some specifics in terms of what prompted this. Also, reducing the driver load time is a good thing. The asynchronous load is very interesting for devices where the firmware load takes a very long time. I do not believe that loading the module synchronously will have any impact on the actual load time, since other modules can be loading in parallel to the initialization of the em28xx device (regardless of whether it is a single module, or three modules loading synchronously or asynchronously). Also, for xc3028 in particular, we could defer firmware loading until first use like we do with xc5000 - doing the firmware load at driver init isn't very useful anyway since we load the firmware and then immediately and put the device to sleep. Maybe one alternative would be to register the interfaces asynchronously also, as a deferred task that is started only after the driver enters into a sane state. Potentially. I feel this should really only be done though in response to an actual problem/bug. Otherwise it adds additional complexity with no real benefit. As the problem is common, the better is to provide a global way to avoid device open while the initialization is not complete, at the v4l core. I would be in favor of this, although I am not sure how practical it is given the diversity in the way different bridges are implemented. Also, we would need to take into account how this would work with DVB, since many of the races we run into are applications attempting to use both the v4l and dvb interfaces of a hybrid device. 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: dmesg output with Pinnacle PCTV USB Stick
On Wed, Jan 27, 2010 at 4:00 PM, Sebastian Spiess sebastian.spi...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, below is my dmesh output for my Pinnacle PCTV Hybrid Pro hope it helps [ 8899.390876] em28xx: New device USB 2870 Device @ 480 Mbps (eb1a:2870, interface 0, class 0) Are you absolutely sure this is a PCTV Hybrid Pro? What is the exact model number? Does it have the A/V cable for composite/svideo input? Based on the USB ID, I would have assumed this was a model 70e, which is a digital only device. It's on my TODO list, but it's a really low priority given how old it is. I actually did spend some time working on it, but ran into problems and without the hardware concluded it wasn't worth the time. 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: Problems with cx18
On Mon, Jan 25, 2010 at 11:45 AM, Theodore Kilgore kilg...@banach.math.auburn.edu wrote: On Mon, 25 Jan 2010, Mauro Carvalho Chehab wrote: Hi Devin/Andy/Jean, snip The sq905c has a warning. snip drivers/media/video/gspca/sq905c.c: In function ?sd_config?: drivers/media/video/gspca/sq905c.c:207: warning: unused variable ?i? snip Please fix. Cheers, Mauro. This one has been fixed, already. A more recent version of sq905c.c is in the pipeline somewhere. Theodore Kilgore Not intending to hijack this thread, but maybe it would be a good idea for Hans's nightly rig to do a build with module support disabled on at least one platform. I'm not saying we should do it on all platforms, but if we at least run it on x86 then we would spot this class of issue earlier. 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: Drivers for Eyetv hybrid
On Mon, Jan 25, 2010 at 3:05 PM, Morten Friesgaard friesga...@gmail.com wrote: Sound like a lot of work, and it would be easier just to buy a functional tuner :) Guess I'm busy enough. However, I did manage to find some more info, for someone to use someday :) /Morten Model: EU 2008 USB Contoller: Empia EM2884 Stereo A/V Decoder: Micronas AVF 49x08 Hybrid Channel Decoder: Micronas DRX-K DRX3926K:A1 0.9.0 Correct, this is an em2884/drx-k/xc5000 design. The em2884 work is pretty straightforward, and the xc5000 driver should work as-is. The big issue is the drx-k driver, for which there is no currently driver 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: Drivers for Eyetv hybrid
On Fri, Jan 22, 2010 at 11:18 AM, Morten Friesgaard friesga...@gmail.com wrote: Actually I don't understand why this em28xx driver is the only one being patched, guess that reduces backward compability!? :-P There are many drivers actively being developed. What I'm trying to say is that the new version of the EyeTV Hybrid is not an em28xx based hardware design. Well, I haven't given up, but no one has given me any pointers but /dev/null If this em28xx module would be startable with the usb id 0fd9:0018, I could tryout the old driver. If you say the hardware design is completely different, I guess it should still be possible to mount the usb device and fetch anything from the device (e.g. tvtime -d /dev/usbdev). The driver would be a matter of controlling the device to tune to the correct channel etc. No, that is not how USB drivers work. You have to know how to program the various chips on the device (the bridge, demodulator, decoder, tuner), as well as knowing how to decode the packets coming back from the device. If you want to get an understanding as to how complex the drivers are then feel free to look at some of them in the v4l-dvb source code. You can get a better understanding as to how these devices are designed here: KernelLabs Blog: How Tuners Work... http://www.kernellabs.com/blog/?p=1045 When new hardware is introduced, how do you guys break down the task and implement a driver? (how much can be borrow from the mac os x drivers?) It largely depends on the device. Usually you start by cracking it open and seeing what chips it contains, and from there you can see which components currently have a driver and which do not. Whether the various components are already supported usually drives whether a whole new driver is required or just a board profile in an existing driver. And whether datasheets are available publicly dictates how easy/hard it is to write a driver (the datasheets are usually *not* available for modern devices, or only available under NDA). 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://jusst.de/hg/stv090x
On Fri, Jan 22, 2010 at 12:48 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: if (stv090x_i2c_gate_ctrl(fe, 1) 0) goto err; tuner access if (stv090x_i2c_gate_ctrl(fe, 0) 0) goto err; Ok. It is very unusual to have a lock internally like the above, since the code becomes poorly documented. That's how a tuner is accessed for any dvb device. Yes, but that's not a function is expect to behave. In general, functions handle the lock/unlock inside it, returning the mutex unlocked. I'm confused - isn't this how pretty much *every* frontend does it's locking? The i2c_gate_ctrl() callback is a standard component in the DVB API. How is what Manu is doing different than any of the other DVB drivers? While I agree that the name i2c_gate_ctrl is not what I would have chosen, as far as I can tell this is how every DVB frontend does 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: PULL http://jusst.de/hg/stv090x
On Fri, Jan 22, 2010 at 1:23 PM, Manu Abraham abraham.m...@gmail.com wrote: The point there is that it is a dual demod which implements a FSM for it's tuner flow control and hence. The demodulators in the tree are generally single/standalone and don't need such a FSM to handle that. Even if it's a dual frontend, most of them just do locking for the register access, while here it is not register access locking, while it is controlling state, similar to Finite State Machine (FSM) Ok, I see what is going on now. I didn't notice before that the gate enable was keeping the state-internal-tuner_lock mutex set even after the call returned. My only concern here then is that I've seen cases where the i2c_gate_ctrl() function is called in a non-symmetric fashion (where the enable/disable calls are not necessarily properly balanced), depending on the driver. While I am relatively confident that you have balanced the instances where it is called within your driver, I would be concerned about how it could possibly be called from other places such as from the tuner driver or the dvb frontend core. Today, there is no real problem if a particular call path attempts to enable the gate if it is already open (or disable if it is already closed). With your proposed change, you will result in a deadlock. Also, you might want to consider replacing the calls themselves with fe-ops.i2c_gate_ctrl() as opposed to calling the internal function directly, since that will allow the frontend ioctl override framework to continue to work 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: PULL http://jusst.de/hg/stv090x
On Fri, Jan 22, 2010 at 2:11 PM, Manu Abraham abraham.m...@gmail.com wrote: I think you understood incorrectly. Generally most demodulators have an option to detect the I2C stop bit, thereby automatically disabling the gate, while some don't. In those cases, you don't even need a i2c_gate_control(disable) It is that safe. Now, even if the gate happens to be open for some reason, it won't have a large downside, just that the i2c transactions might seep into the tuner silicon as RF noise. Yes, I was aware of this (although I might dispute whether *most* demodulators really operate this way). Can you explain your logic a bit more in detail, please ? If you meant to imply the action on a failure case, it does unlock in all possible cases as you can see... http://jusst.de/hg/stv090x/rev/3a8f35abc0f2 I am not talking about the case where the tuning fails. I mean that not only is the i2c_gate_ctrl function used internally by stv090x.c, but it is also exposed via the dvb_frontend_ops struct. Depending on what tuner chip your frontend is being used with, I have seen cases where the tuner driver itself takes responsibility for opening/closing the gate. So you effectively end up with: frontend driver calls i2c_gate_ctrl(enable) frontend driver tells tuner driver to tune tuner driver calls i2c_gate_ctrl(enable) --- Would cause deadlock in your driver tuner driver calls i2c_gate_ctrl(disable) tuner driver returns to caller frontend driver calls i2c_gate_ctrl(disable) With other devices, this call is typically silently succeeds (and doesn't cause any harm). In your case though, it would end up with a deadlock because your particular i2c_gate_ctrl() function leaves the state-internal-tuner_lock in a locked state. Now you may not run into this issue because today your frontend is only used with a tuner that doesn't do this. However it is something to watch out for in the future. Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various points, so you would need to ensure that none of those occur before calling into your driver as there could potentially be a deadlock there too. 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://jusst.de/hg/stv090x
On Fri, Jan 22, 2010 at 3:22 PM, Manu Abraham abraham.m...@gmail.com wrote: On Fri, Jan 22, 2010 at 11:40 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Also, the dvb_frontend.c makes calls to i2c_gate_ctrl() at various points, so you would need to ensure that none of those occur before calling into your driver as there could potentially be a deadlock there too. Ok, thanks for the pointer. The gate control is never called externally in reality. I will wait a little while for this patch to be applied. It removes the exported function and thereby an unnecessary dereference. http://jusst.de/hg/stv090x/rev/b3d28f5b2b53 If it never needs to be called externally, then removing it from the dvb_frontend_ops does eliminate the risk entirely. The case I frequently see it called from dvb_frontend.c is for powering down the tuner when the dvb frontend thread shuts down. 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: PULL http://jusst.de/hg/stv090x
On Fri, Jan 22, 2010 at 3:59 PM, Manu Abraham abraham.m...@gmail.com wrote: No, rather on frontend shutdown, demodulator sleep() is called instead. demodulator sleep() shuts down the tuner, AFAIR. This is the original and correct behaviour for dvb frontend. Both the tuner and frontend are issued sleep calls. See dvb_frontend.c line 680. 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/hvr-1600-alsa-3
On Fri, Jan 22, 2010 at 4:32 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: There is one remaining checkpatch warning: WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable #45: FILE: drivers/media/video/cx18/cx18-driver.c:52: +EXPORT_SYMBOL(cx18_ext_init); Please send later a patch fixing it. I wonder how the heck I managed to miss that. Sorry, will do. 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: First -git merges
On Fri, Jan 22, 2010 at 4:55 PM, Mauro Carvalho Chehab mauroche...@gmail.com wrote: Ah, I forgot to mention: if you're interested on seeing the commits, you need to subscribe linuxtv-comm...@linuxtv.org. In addition to the -hg commits that were available there since the beginning of the -hg trees, you'll be receiving also the -git commits. The -git commits are short: one message per git push. The message will contain a summary of all patches added by the git push. I'm actually on linuxtv-commits, but I didn't get any of the notifications. Am I missing something? 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: First -git merges
On Fri, Jan 22, 2010 at 5:03 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: I'm actually on linuxtv-commits, but I didn't get any of the notifications. Am I missing something? Nevermind. I didn't see your note about the first few having been missed. 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: Drivers for Eyetv hybrid
On Wed, Jan 20, 2010 at 12:26 PM, Morten Friesgaard friesga...@gmail.com wrote: Hello. I installed mythbuntu 9.10 this week on some old hardware, I had a Hauppauge 500MCE PVR in and made it work fairly easy. I'm used to gentoo However, I want to record HD signal, so I plugged in a Eyetv hybrid and followed this guide http://ubuntuforums.org/showthread.php?t=1015387 I extracted the driver, put it in into /lib/firmware, modprobed em28xx, rebooted. When I plug in the device, it is not recognised. I tried both usb ports. The ID is 0fd9:0018, which is somewhat different from similar hardware e.g. Hauppauge wintv-hvr-950 (ID 2040:6513 http://www.linuxtv.org/wiki/index.ph..._WinTV-HVR-950 ) It's a totally different hardware design, nothing like the older version of the EyeTV Hybrid (which was just a clone of the HVR-950). It is unsupported currently (and nobody is working on it to my knowledge). 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: [ANNOUNCE] git tree repositories
Hello Mauro, I find it somewhat unfortunate that this is labeled ANNOUNCE instead of RFC. It shows how little you care about soliciting the opinions of the other developers. Rather than making a proposal for how the process can be improved and soliciting feedback, you have chosen to decide for all of us what the best approach is and how all of us will develop in the future. I know you'll continue to receive alot of thank you and great job comments from some of the developers who have been pushing for this, so I'll be the bad guy and point out the downsides to what you are proposing. First off, I would like to note that I have absolutely no problem with git. I think it's a great tool and I use it for other projects. If the question today was which source control software to use, I have no doubt I would choose git over mercurial. I've used a variety of different source control systems both open source and commercial, and git is a really good tool. That said, my real problem is with the change requiring all the active developers to be developing on the latest Linux kernel. Before I renew my arguments, I will openly acknowledge that your approach does make numerous things easier. I have little doubt that it will make merging easier for you personally, as well as addresses issues with patches that have architecture specific changes (or other changes that are outside of the current v4l-dvb tree). So let's talk about why this is bad I want to focus my development on v4l-dvb. That said, I want a stable codebase on which I can write v4l-dvb drivers, without having to worry about whether or not my wireless driver is screwed up this week, or whether the ALSA guys broke my audio support for the fifth time in two years. I don't want to wonder whether the crash I just experienced is because they've replaced the scheduler yet again and they're still shaking the bugs out. I don't want to be at the mercy of whatever ABI changes they're doing this week which break my Nvidia card (and while I recognize as open source developers we care very little about closed source drivers, we shouldn't really find it surprising that many developers who are rendering HD video might be using Nvidia cards). Like most smart developers, I want to have a *controlled* environment where I can be confident that if a problem arises that it's *my* changes at fault. Any time that I spend trying to figure out why my PC doesn't work is time that I'm not debugging v4l-dvb drivers. And *THAT* is why it's critical that the mainline not be treated as alpha quality like you suggested last week. For example, when you check in alpha code that causes an OOPS whenever any tuner with IR support is plugged in, I waste several hours debugging the regression you introduced instead of doing my own work. Further, we're also changing from a system where we build a relatively small tree of modules to one where we're going to be building/installing entire kernels. Even on my relatively recent hardware, this is process that takes upwards to an hour (and yes, I do have ccache). Even a make modules_install can several minutes. So now I'm going from being able to make make install make unload twenty times an hour to a *MUCH* slower process. We're giving up the ability to have a fast debug-compile-test cycle for developers in exchange for easier merging of the final result. This seems like a poor optimization choice for those of us who spend all day compiling, debugging, and testing. Personally, I spend about 98% of my time actively debugging code, and about 2% of my time dealing with merge issues. So I *really* care about things like how long it takes to compile and install the tree. I hope other developers will offer their opinions on this approach, since it's all of us who will pay the price in time as a result of this change. If all the developers who are writing the code think it's a good idea to be half as efficient in order to make the merging easier for one person, then so be it. The point I'm trying to make is that we need to be having a discussion about what we are optimizing for, and what are the costs to other developers. This is why I'm perhaps a bit pissed to see an announcement declaring how development will be done in the future as opposed to a discussion of what we could be doing and what are the trade-offs. 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] mxl5005s: bad checks of state-Mode
On Tue, Jan 19, 2010 at 9:20 PM, Roel Kluin roel.kl...@gmail.com wrote:
Regardless of the state-Mode in both cases the same value was
written.
If state-Mode wasn't set, it is always 0.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
drivers/media/common/tuners/mxl5005s.c | 7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
Or were the ones and zeroes in these MXL_ControlWrite in the wrong place?
diff --git a/drivers/media/common/tuners/mxl5005s.c
b/drivers/media/common/tuners/mxl5005s.c
index 605e28b..3967412 100644
--- a/drivers/media/common/tuners/mxl5005s.c
+++ b/drivers/media/common/tuners/mxl5005s.c
@@ -1815,9 +1815,8 @@ static u16 MXL_BlockInit(struct dvb_frontend *fe)
/* Charge Pump Control Dig Ana */
status += MXL_ControlWrite(fe, RFSYN_CHP_GAIN, state-Mode ? 5 : 8);
- status += MXL_ControlWrite(fe,
- RFSYN_EN_CHP_HIGAIN, state-Mode ? 1 : 1);
- status += MXL_ControlWrite(fe, EN_CHP_LIN_B, state-Mode ? 0 : 0);
+ status += MXL_ControlWrite(fe, RFSYN_EN_CHP_HIGAIN, 1);
+ status += MXL_ControlWrite(fe, EN_CHP_LIN_B, 0);
/* AGC TOP Control */
if (state-AGC_Mode == 0) /* Dual AGC */ {
@@ -2161,7 +2160,7 @@ static u16 MXL_IFSynthInit(struct dvb_frontend *fe)
}
}
- if (state-Mode || (state-Mode == 0 state-IF_Mode == 0)) {
+ if (state-Mode || state-IF_Mode == 0) {
if (state-IF_LO == 5700UL) {
status += MXL_ControlWrite(fe, IF_DIVVAL, 0x10);
status += MXL_ControlWrite(fe, IF_VCO_BIAS, 0x08);
Roel,
Thanks for pointing this out.
This patch should not be applied.
While I agree with Roel's assessment that the logic is incorrect,
removing the conditional logic and forcing the register writes to the
given value is almost certainly the incorrect fix. I will have to
look at the datasheet and see what the logic is actually supposed to
be.
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 driver - xc3028 tuner - readreg error
On Mon, Jan 18, 2010 at 10:01 AM, Valerio Bontempi valerio.bonte...@gmail.com wrote: Hi all, I am still having problem using v4l-dvb drivers with Terratec Cinergy T USB XS. As reported in first mail, I am using the last version of v4l-dvb drivers with few lines adjustment in order to make this driver to enable dvb for my dvb only device (this because official v4l-dvb driver actually doesn't support my device at all) I have cleaned my distro (openSuse 11.2 x86-64) about all the v4l modules provided by distro's repositories, and I compiled modified v4l-dvb source. So acutally I am using a cleaned version of v4l-dvb. But the [ 1483.314420] zl10353_read_register: readreg error (reg=127, ret==-19) [ 1483.315166] mt352_read_register: readreg error (reg=127, ret==-19) error isn't solved yet. Could it be related to the firmware I am using? No, this has nothing to do with firmware. It is probably an issue where the gpio configuration is wrong and the demod is being held in reset (hence it won't respond to i2c commands). The 0ccd:0043 is on my todo list of devices to work on (they sent me a sample board), although it's not the highest priority on my list given how old it 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: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
On Mon, Jan 18, 2010 at 10:31 AM, Stefan Ringel stefan.rin...@arcor.de wrote: I have a question. How are loaded the base firmware into xc3028, in once or in a split ? It's importent for TM6010, the USB-Analyzer said that it load it in once and then send a quitting reqeuest. In most drivers, the xc3028 firmware gets broken down and sent in 64 byte chunks. The size of the chunks is controlled by the max_len field in the xc2028_ctrl structure. 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: Info
On Mon, Jan 18, 2010 at 11:03 AM, Adriano Gigante adrig...@yahoo.it wrote: Hi Devin, The 0ccd:0043 is on my todo list of devices to work on (they sent me a sample board), although it's not the highest priority on my list given how old it is. Did they sent you also a 0ccd:0072 card (Terratec Cinergy Hybrid T USB XS FM)? Adri Terratec sent me two boards: 0ccd:0072 and 0ccd:0043. I've actually been working with a user on the #linuxtv irc channel who is in the process of getting the 0ccd:0072 board to work (username Prahal). He's making great progress, but if he gets stuck I will find some cycles to work through whatever problem he finds. 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] Asking
On Mon, Jan 18, 2010 at 11:11 AM, Ismo Kuhmonen ismo...@gmail.com wrote: Hi Why my Pinnacle DVB-T 73€ USB not working? Are you running the current v4l-dvb tree? Support for the 73e was introduced into the v4l-dvb tree on September 2nd, so the changes probably haven't gotten into whatever distribution you are using yet. See http://linuxtv.org/repo for instructions on installing the latest v4l-dvb 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: Info
Hello Markus, On Mon, Jan 18, 2010 at 11:29 AM, Markus Rechberger mrechber...@gmail.com wrote: Just fyi there's a hardware bug with the 0072/terratec hybrid xs fm (cx25843 - xc5000): http://img91.imageshack.us/i/0004qf8.png/ http://img104.imageshack.us/i/0009cp4.png/ nothing that can be fixed with the driver. Interesting. If it cannot be fixed with the driver, how does the Windows driver work then? Is this some sort of premature hardware failure that occurs (after which point it is irreversible)? Thanks for taking the time to point this out though, since I could totally imagine banging my head against the wall for quite a while once I saw this. 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-1600-alsa-3
Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-3 for the following: cx18-alsa: Fix the rates definition and move some buffer freeing code. cx18: address possible passing of NULL to snd_card_free cx18-alsa: codingstyle cleanup cx18-alsa: codingstyle cleanup cx18: codingstyle fixes cx18-alsa: codingstyle fixes cx18-alsa: fix codingstyle issue cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files This tree is the same as hvr-1600-alsa-2 except I rebased it off of the v4l-dvb tip, fixing the merge conflict with Andy's cx18-stream changes. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/xc3028-regression
Hello Mauro, Please PULL from http://kernellabs.com/hg/~dheitmueller/xc3028-regression for the following: xc3028: fix regression in firmware loading time This is a fix for a regression you introduced into the tuner-xc2028 driver in rev 12824. 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: PCTV (ex Pinnacle) 74e pico USB stick DVB-T: no frontend registered
On Sun, Jan 17, 2010 at 5:18 AM, Patrick Boettcher pboettc...@kernellabs.com wrote: The 74e is not a dib0700-based device, my assumption at that time was wrong. For the 74e afaik, there is no LinuxTV driver right now. (IIRC it is a Abilis based design) Patrick is correct in that the 74e is an Abilis design. I have been working with PCTV for a couple of months, who has worked with Abilis to get a GPL driver out there. The firmware redistribution rights have finally been straightened out last Friday, so keep an eye on the KernelLabs.com blog for an announcement in the near future. 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: Kworld 315U and SAA7113?
On Sun, Jan 17, 2010 at 2:05 AM, Franklin Meng fmeng2...@yahoo.com wrote: I retested my device and tried several different GPIO sequences but so far every time I change between the Analog and digital interface, the SAA7113 needs to be reinitialized. I tried leaving both the digital and analog interfaces enabled by setting the GPIO to 7c but then the LG demod does not initialize. Either way it looks like I will have to reinitialize the device after switching between interfaces. Other than that do you want me to remove the suspend GPIO? Since I don't have the equipment to measure the power, I don't know for a fact if the device really has been put in a suspend state or not. Hello Franklin, Just to be clear, I'm not proposing that you remove the suspend logic. I was suggesting that you should be breaking the change into three separate patches, so that if a problem arises we can isolate whether it is a result of the power management changes. Having a separate patch is especially valuable because you are touching other drivers which are shared by other products. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Fri, Jan 15, 2010 at 3:00 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. What you call trunk, it not, really a trunk, but a tree where all patches got merged. I've been pointing it several times, but people doesn't seem to listen: that tree is were we'll expect problems to happen, since it is just an alpha staging before submitting things to linux-next, where all patches got merged. The bad thing is that people use it as if they were stable, when it weren't meant to be stable at all. This is your *opinion* that you are stating. I think many (if not most) would disagree with you, in that the v4l-dvb tree should not be treated as alpha quality. It should be generally stable, and things should not be merged into it until they are of releasable quality. Every other developer operates this way *except you*. Every other developer does his work in a separate tree, and that tree is merged once the code is stable. You are the only one who is directly checking things into the trunk that are alpha quality. Many people rely on installing the v4l-dvb tree as a path to get new device support without having to wait for a full kernel to be released and for their distribution to incorporate that kernel. Your failure to work on a branch until code is stable like every other developer contributing to this project is damaging the project's reputation. As a project, we should be embarrassed when our trunk doesn't compile on every kernel version except one. And we should be embarrassed when for nearly a month it is in a state where every board that has IR support causes an OOPS on insertion. That's why I decided to deprecate it. On the next few days, I intend to stop adding patches at -hg tree, passing its maintainance to another person. Douglas already offered to do it for us. The idea is that I'll apply patches directly into my git trees. And then, the hg maintainer will backport the patches into -hg. This also means that patch backports will need to be sent in separate, as those patches won't fit into -git. I'm finishing the details and I'll post an official announce about that soon. Rather than making any announcement, I would strongly encourage you to consider actually soliciting the feedback on your proposed approach from all of the developers who are actually contributing the code to the project. There are many developers who have very strong feelings on how this project should operate, and would likely take considerable exception to any unilateral decision being thrust upon them that has serious implications to how developers will be expected to work in this project. Let's not forget that this is a community of volunteer developers working towards a common cause, and not a dictatorship. 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: Order of dvb devices
On Fri, Jan 15, 2010 at 6:00 PM, Oliver Endriss o.endr...@gmx.de wrote: I believe your assumption is incorrect. I believe the enumeration order is not deterministic even for multiple instances of the same driver. It is not uncommon to hear mythtv users complain that I have two PVR-150 cards installed in my PC and the order sometimes get reversed on reboot. Afaik the indeterministic behaviour is caused by udev, not by the kernel. We never had these problems before udev was introduced. I suppose it's possible that udev does not process the events in the order in which they are received. Admittedly I have not done any real analysis as to how that part of the kernel works. 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: Order of dvb devices
On Thu, Jan 14, 2010 at 10:35 AM, Andreas Besse be...@motama.com wrote: if a system contains multiple DVB cards of the same type, how is the order of devices determined by the driver/kernel? I use 2 Technotrend S2-3200 cards in a system and observerd that if I load the driver driver budget_ci manually as follows: modprobe budget_ci adapter_nr=0,1 the device with the lower pci ID :08:00.0 is assigned to adapter0 and the device with the higher pci ID :08:01.0 is assigned to adapter1: udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter0/frontend0) [...] looking at parent device '/devices/pci:00/:00:1e.0/:08:00.0': KERNELS==:08:00.0 SUBSYSTEMS==pci udevinfo -a -p $(udevinfo -q path -n /dev/dvb/adapter1/frontend0) [...] looking at parent device '/devices/pci:00/:00:1e.0/:08:01.0': KERNELS==:08:01.0 SUBSYSTEMS==pci Is it true for all DVB drives that the device with the lower PCI id gets the lower adapter name? No, you cannot really make this assumption. In fact, there are users who see behavior where uses have two of the same card and the cards get flipped around randomly just by rebooting. The ordering is based on the timing of the device driver loading, so it is not deterministic. I believe you can use udev rules though to force a particular driver to get a specific adapter number (although admittedly I do not know the specifics of how it is done, and am not confident it *can* be done if both cards are the same vendor/model). 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: Order of dvb devices
On Thu, Jan 14, 2010 at 11:01 AM, Andreas Besse be...@motama.com wrote: yes if there are different drivers I already observed the behaviour that the ordering gets flipped after reboot. But if I assume, that there is only *one* driver that is loaded (e.g. budget_av) for all dvb cards in the system, how is the ordering of these devices determined? How does the driver search for available dvb cards? I believe your assumption is incorrect. I believe the enumeration order is not deterministic even for multiple instances of the same driver. It is not uncommon to hear mythtv users complain that I have two PVR-150 cards installed in my PC and the order sometimes get reversed on 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: Kworld 315U and SAA7113?
On Thu, Jan 14, 2010 at 1:54 PM, Franklin Meng fmeng2...@yahoo.com wrote: Unfortunately, I do not know the difference. I thought it might be to do something to the tuner but I am not quite sure. If I remember correctly, the traces that I obtained also showed a difference between the analog modes. I do know that if I leave the bit on it does not cause any adverse affects (other than maybe more power is being drawn).. If there is no difference, it might make sense to just pick one. If you could measure the power draw though, you might gain some insight regarding the difference. I might try leaving the GPIO pin high.. I had lots of issues switching between analog and digital modes so changing this bit may cause one or the other to not work. For example if I leave both pins for the SAA/EM202 and the demod high, the analog doesn't seem to work correctly. I'm guessing that there probably isn't enough power to keep both devices operational. I'll try it out some more to see what happens. You would obviously need to retest. The cases where having the digital GPIO do an actual reset were exposed when performing multiple tuning attempts without closing the DVB device in between attempts. As far as I can tell, the Kworld 315U is the only board that uses this combination of parts.. Thomson tuner, LG demod, and SAA7113. I don't think any other device has used the SAA7113 together with a digital demod. Most products seem to only have the SAA711X on an analog only board. Since I don't have any other USB adapters with the SAA chip I was unable to do any further testing on the SAA code changes. I'm more worried about it interfering with other devices that use some other bridge, regardless of whether that device has a demodulator. Implementing power management on any chip is likely to expose bugs in neighboring components like the bridge. Did you actually do any power analysis to confirm that the suspend functionality is working properly? Humm.. I did not actually do this. Though, maybe I can figure this out by seeing how much power draw is on the USB bus. I don't recall if there is a way to figure this out or not from within Linux. I do remember Windows having such a feature.. I probably need to do a comparison between both OS's to make sure I get things are correct.. Is there a way to get information on how much power draw is happening on the USB bus in Linux? I don't trust the operating system when it comes to that sort of thing. I cut up an old USB cable and put an ammeter in-line. Has helped alot in finding all sorts of power management bugs both in drivers and in the v4l-dvb core. 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: Kworld 315U and SAA7113?
On Thu, Jan 14, 2010 at 5:00 PM, CityK ci...@rogers.com wrote: Franklin Meng wrote: As far as I can tell, the Kworld 315U is the only board that uses this combination of parts.. Thomson tuner, LG demod, and SAA7113. I don't think any other device has used the SAA7113 together with a digital demod. Most products seem to only have the SAA711X on an analog only board. Since I don't have any other USB adapters with the SAA chip I was unable to do any further testing on the SAA code changes. IIRC, a couple of the Sasem/OnAir devices use a saa7113 together with a digital demod. I seem to also recall something else, though maybe I'm mistaken. I'm actually not really concerned about it's interaction with a demod. I'm more worried about other products that have saa711[345] that use a bridge other than em28xx. The introduction of power management could always expose bugs in those bridges (I had this problem in several different cases where I had to fix problems in other drivers because of the introduction of power management). 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: VL4-DVB compilation issue not covered by Daily Automated
On Wed, Jan 13, 2010 at 3:32 AM, xof x...@skynet.be wrote: Are you sure? (it is an Ubuntu-only issue) I can see several #include asm/asm.h in the v4l tree that compile fine on Ubuntu but only linux/drivers/media/dvb/firewire/firedtv-1394.c contains #include asm.h and doesn't compile. Unfortunately the asm.h asm/asm.h is not the only issue with firedtv-1394.c (on Ubuntu/Karmic Koala?). The /drivers/ieee1394/*.h seem to be in the linux-sources tree and not in the linux-headers one (?) Everywhere I look, I read don't bother, just disable firedtv-1394.c until they fix it. I think perhaps you meant to write dma.h and not asm.h. All of the missing includes in the error log (including dma.h) are for files that are found in the iee1394 source directory, which are not provided in the Ubuntu linux-headers package. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Wed, Jan 13, 2010 at 9:00 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Michael Krufky wrote: The same tree is also available using http instead of https: http://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 This should work for you without issue. Ok. Applied, thanks! Sorry about that. I typically cut/paste the link from my browser (and we support both http and https for the HG repo). I will be sure that future PULL requests are http only. Also, I haven't had a chance to rebase this tree against the tip yet, as I burned too much time over the weekend tracking down the regression you introduced into the with the ir-sysfs rework. Did that one line patch get merged yet? It's pretty embarrassing to have a situation for nearly a month where the mainline v4l-dvb causes an OOPS just because they happen to have IR support. In my case, I couldn't even get my PC to boot until I pulled the card from the machine. I've tried to tactfully point this out in the past, but PLEASE STOP USING THE TRUNK AS YOUR PERSONAL DEVELOPMENT SANDBOX. These changes should have gone into a branch, and you should have solicited testers for that branch before any of this stuff went into the mainline. I know you're the maintainer so the rules don't apply to you, but the reality is that when talking about new development (not fixing merge conflicts), you should really be adhering to the same rules that all the other developers use. These rules are there for a reason - to provide an opportunity to catch regressions in new code before they hit the mainline. I know that you have made quite clear that you disagree that you should have to use branches for new development/refactoring. My only hope is that by pointing out every time one of your actions in the trunk causes a nasty regression, perhaps you will rethink your approach. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kworld 315U and SAA7113?
On Sat, Jan 9, 2010 at 2:30 PM, Franklin Meng fmeng2...@yahoo.com wrote: I tweaked the GPIO's a bit more for the Kworld 315U and switching between analog and digital signals is more reliable now. Attached is an updated diff. Hello Franklin, This is pretty good stuff. A few questions/comments about your patch: The code has different GPIO configurations for the two analog modes. This is a bit unusual for an em28xx design. Do you know what the difference is in terms of what GPIO7 controls? The digital GPIO block strobes GPO3 to reset the lgdt3303. While I generally believe that it's good to explicitly strobe the reset low, this could cause problems with em28xx devices. This is because the em28xx calls the digital GPIO whenever starting streaming. Hence, you could end up with the chip being reset without the demod driver's init() routine being called, resulting in the chip's register state not being in sync with the driver's state info. In fact, we have this issue with one of the Terratec boards where the zl10353 driver state gets out of sync with the hardware (I still need to submit a patch upstream for that case). Your code at this point should probably only ensure the 3303 is not in reset (by setting the GPIO pin high). It's not surprising that you would uncover an issue with the suspend logic. Despite the fact that the em28xx driver provides a suspend method it is not actually used today in any of the board profiles. The saa7115 stuff looks pretty reasonable at first glance, although I am a bit worried about the possibility that it could cause a regression in other products that use that decoder. Did you actually do any power analysis to confirm that the suspend functionality is working properly? I agree with Mauro though that this should be split into multiple patches. In fact, I would seriously consider three patches instead of two - the first patch adds the basic functionality to get the board working, the second adds the saa7115 code, and the third adds the suspend GPIO changes. This will make it easier for others who have problems to isolate whether any problems are a basic issue with the board not working or whether it is related to the suspend and power management changes. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: VL4-DVB compilation issue not covered by Daily Automated
On Tue, Jan 12, 2010 at 4:26 PM, Hagen von Eitzen ha...@von-eitzen.de wrote: Dear all, as suggested by http://www.linuxtv.org/wiki/index.php/Bug_Report I report several warnings and errors not yet covered in latest http://www.xs4all.nl/~hverkuil/logs/Monday.log I get when compiling. (The purpose of my experiments was trying to find out something about 0ccd:00a5 TerraTec Electronic GmbH) Regards Hagen This is an Ubuntu-specific issue (they improperly packaged their kernel headers), which will not be covered by the daily build system (which exercises various kernels but not across different Linux distribution versions). Devin -- 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/dib0700_ir
Hello Mauro, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/dib0700_ir for the following: dib0700: rework IR logic for firmware 1.20 You had mentioned that you intended to do some porting of the dib0700 to use your new backend, so please do me a favor and merge this *before* you start your work. 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://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sun, Jan 10, 2010 at 7:33 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi Devin, Unfortunately, I got some merge conflicts with cx18 code from Andy, due to the buffer handling changes. Could you please rebase your tree against tip, solving those conflicts? Sure, I'll try to do that tonight. I should probably retest anyway to make sure that the buffer changes don't introduce any regressions in the audio code (not that I have any reason to suspect it will). You didn't forget about the em28xx PAL VBI tree, right? I'm just mentioning it because the PULL has been pending for several weeks and came long before the PULL for the HVR-1600 ALSA changes. 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: Regression - OOPS when connecting devices with IR support
On Sun, Jan 10, 2010 at 2:49 AM, Francesco Lavra francescola...@interfree.it wrote: Yes, the IR core is broken, a patch has been submitted by myself some time ago (http://patchwork.kernel.org/patch/70126/), but hasn't made it to v4l-dvb yet. Thanks for the heads up. I actually didn't see that patch, so I appreciate you pointing it out (since it will allow me to continue my development). 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: cx23885 oops during loading, WinTV-HVR-1850 card -- SOLVED
On Fri, Jan 8, 2010 at 8:55 PM, Ralph Siemsen ral...@netwinder.org wrote: Now the driver loads, and I follow it up with modprobe tuner. Unfortunately, no luck yet using tvtime, it just reports: videoinput: No inputs available on video4linux2 device '/dev/video0'. But I suspect that is a different issue! The cx23885 driver doesn't work with tvtime, due to bugs in the v4l controls in the driver. Michael Krufky has some patches but they need some more work before they can go in the mainline. Even if they were committed though, there is currently no support for raw audio, so tvtime would not be a good application to use for this device. 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: DTV2000 H Plus issues
On Thu, Jan 7, 2010 at 2:49 PM, istva...@mailbox.hu istva...@mailbox.hu wrote: On 01/05/2010 02:25 AM, Raena Lea-Shannon wrote: Thanks. Will try again later. By the way, for those who would like to test it, here is a patch based on Devin Heitmueller's XC4000 driver and Mirek Slugen's older patch, that adds support for this card: http://www.sharemation.com/IstvanV/v4l/dtv2000h+.patch It can be applied to this version of the v4l-dvb code: http://linuxtv.org/hg/v4l-dvb/archive/75c97b2d1a2a.tar.bz2 This is experimental code, so use it at your own risk. The analogue parts (TV and FM radio) basically work, although there are some minor issues to be fixed. Digital TV is not tested yet, but is theoretically implemented; reports on whether it actually works are welcome. The XC4000 driver also requires a firmware file: http://www.sharemation.com/IstvanV/v4l/dvb-fe-xc4000-1.4.1.fw -- 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 Istan_v, Could you please do me a favor and rename your firmware file, both in the patch and the file you are redistributing (perhaps as dvb-fe-xc4000-1.4.1-istanv.fw)? I worry that by redistributing a file with the exact same name as the official release, people are going to get confused and it will make it harder for me to debug problems given my assumptions about what firmware image they are using is incorrect. 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: Call for Testers - dib0700 IR improvements
On Wed, Jan 6, 2010 at 5:00 AM, Harald Gustafsson hgu1...@gmail.com wrote: Hi, Thanks for working on improving the Nova T 500 performance, it is much appreciated, and let me know if you need further help with debugging it. I tried your dib0700-ir tree. My problems with the Nova T 500 and the 1.20 firmware have been warm reboots. Before your patch a warm reboot would give I2C errors in dmesg log with the 1.20 FW, hence I have only used my machine with cold boots since my upgrade this xmas. With the 1.10 FW and Ubuntu 7.04 + v4l tip sometime in 2008 the system have run without much problems including frequent warm reboots for 2 years. Sorry to say this patch does not solve the problem to have a working IR after a warm reboot see dmesg logs below. I have not seen any problems with high load before, so can't give any info on that matter more than it is certainly low now. The I2C errors I saw before your patch come shortly after a warm reboot (see last dmesg log included), but have not had any problems after cold boots for the past week the system have been recording. Hi Harald, Thanks for taking the time to test and provide feedback. Just to be clear, this patch does *not* address the warm reboot problem. I am continuing to work that issue, but there should be no expectation that this patch allows the device to survive a warm reboot. It should address concerns people were seeing where the system load would be between 0.50 and 1.0 just by having the device connected, and *may* help in cases where you start to see mt2060 errors after several hours of operation. 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: New device request and tvp5150 distortion issues when capturing from vcr
On Tue, Jan 5, 2010 at 3:40 AM, Michael Rüttgers i...@michael-ruettgers.de wrote: Hello, a year ago I bought a device named Hama Video Editor, which was not (and is not yet) supported by the em28xx driver. So I played around with the card parameter and got the device basically working with card=38. Basically working means, that I had a distortion when capturing old VHS-Tapes from my old vcr. The problem can be seen here: http://www.michael-ruettgers.de/em28xx/test.avi A few weeks ago I started tracking down the reason for this issue with the help of Devin. Wondering, that the device works perfectly in Windows, I compared the i2c commands, that programmed the register of the tvp5150 in Windows. Finally I got the device working properly, setting the TV/VCR option in the register Operation Mode Controls Register at address 02h manually to Automatic mode determined by the internal detection circuit. (default): 000109: OUT: 00 ms 107025 ms 40 02 00 00 b8 00 02 00 02 00 After programming this register, the distortion issue disappeared. So my conclusion was, that the TV/VCR detection mode is forced to TV-mode in the em28xx, which could have been verified by a look into the debug output using the parameter reg_debug=1: OUT: 40 02 00 00 b8 00 02 00 02 30 Bit 4, 5 are used for setting the TV/VCR mode: Description in the Spec: TV/VCR mode 00 = Automatic mode determined by the internal detection circuit. (default) 01 = Reserved 10 = VCR (nonstandard video) mode 11 = TV (standard video) mode With automatic detection enabled, unstable or nonstandard syncs on the input video forces the detector into the VCR mode. This turns off the comb filters and turns on the chroma trap filter. Thus far the tvp5150 distortion issues when capturing from vcr. Mauro, I have been working with Michael on this issue and I did some research into the history of this issue, and it seems like you introduced code in rev 2900 which turns off the auto mode and forces the tvp5150 into TV mode if using a composite input: http://linuxtv.org/hg/v4l-dvb/rev/e6c585a76c77 Could you provide any information on the rationale for this decision? I would think that having it in auto mode would be the appropriate default (which is what the Windows driver does), and then you would force it to either TV or VCR mode only if absolutely necessary. The comb filter only gets disabled if the auto mode actually concludes the device should be in VCR mode. Hence, there shouldn't be any downside to having it in auto mode unless you have some reason to believe the detection code is faulty or error-prone. We can add a modprobe option to allow the user to force it into one mode or the other, if someone finds a case where the detection logic has issues. But forcing it into one particular mode by default doesn't seem like the right approach. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Mauro, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: Fix the rates definition and move some buffer freeing code. cx18: address possible passing of NULL to snd_card_free cx18-alsa: codingstyle cleanup cx18-alsa: codingstyle cleanup cx18: codingstyle fixes cx18-alsa: codingstyle fixes cx18-alsa: fix codingstyle issue cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files This includes the codingstyle fixes Mauro reported as well as the changes Takashi Iwai suggested for the ALSA config and buffer handling. 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: PROBLEM: DVB-T scan not working after ioctl
On Tue, Jan 5, 2010 at 12:50 PM, Franz Fürbaß franz.fuerb...@chello.at wrote: Hello, [1] . Can't scan for DVB-T channels with Hauppauge HVR 4000 HD. [2] Got a scan problem with the Hauppauge HVR 4000 HD card. If I try to scan for channels with the DVB-T frontend (/dev/dvb/adapter0/frontend1) no lock is generated after this sequence: -open() -ioctl( fd, FE_GET_INFO, fe_info ) -close() -open() -ioctl( fd, FE_GET_INFO, fe_info ) Could be some sort of timing bug where the frontend kernel thread is suspending the device. Just as a test, try putting an msleep(5000); between the first close and the second open(), and see if the problem still occurs. 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: PROBLEM: DVB-T scan not working after ioctl
On Tue, Jan 5, 2010 at 6:37 PM, Franz Fürbaß franz.fuerb...@chello.at wrote: Ok, seems to work. I put an usleep(500); between close and open. I will try to apply this to MythTV and w_scan as well. You can certainly try that with w_scan and MythTV to see if it improves your situation. However, I want to be clear that I just wanted you to do it for testing purposes to see if it helps, and it likely suggests a bug in the kernel that will need to be fixed. 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: PCTV 340e support
Hello All, If there are any users who have been waiting for the PCTV 340e to be supported, there is now a tree available for testing: http://kernellabs.com/hg/~dheitmueller/pctv-340e-2 Comments welcome. More info can be found here: http://www.kernellabs.com/blog/?p=1247 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Tue, Dec 22, 2009 at 5:34 AM, Mauro Carvalho Chehab Provided that you've fixed the points that Takashi rised about the alsa part, I'm fine. Please send a separate pull request c/c him , in order to allow him to send his ack. Ok. With the holidays upon us and my being out of town, I will try to do this Sunday night. 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: em28xx driver - xc3028 tuner - readreg error
On Tue, Dec 22, 2009 at 10:11 AM, Valerio Bontempi
valerio.bonte...@gmail.com wrote:
Before the update, v4l-dvb driver worked fine, and now it doesn't work
even if I remove the updated packages.
Checking for kernel modules conflict, I found only the modules
installed by v4l-dvb sources.
#find /lib/modules/`uname -r` -name 'em28xx*' | xargs -i ls -l {}
totale 236
-rw-r--r-- 1 root root 21464 22 dic 16:03
/lib/modules/2.6.31.5-0.1-desktop/kernel/drivers/media/video/em28xx/em28xx-alsa.ko
-rw-r--r-- 1 root root 26176 22 dic 16:03
/lib/modules/2.6.31.5-0.1-desktop/kernel/drivers/media/video/em28xx/em28xx-dvb.ko
-rw-r--r-- 1 root root 184936 22 dic 16:03
/lib/modules/2.6.31.5-0.1-desktop/kernel/drivers/media/video/em28xx/em28xx.ko
My guess is that these files were provided by your distro through a
kernel update (and in 2.6.31 this board is known to have problems
which have been fixed in the latest v4l-dvb tree).
I would suggest the following going into your v4l-dvb tree and doing
the following:
make distclean make make install reboot
And see if the problem clears up.
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 PCTV Hybrid (2) dvb woes
On Sun, Dec 20, 2009 at 6:40 PM, Pedro Ribeiro ped...@gmail.com wrote: Damn, I suspected that. Anyway, I'm having trouble viewing analog TV. I can scan and watch channels fine, but there is no audio, and I don't know how to configure it. If you could help me, I would really appreciate it Should I use the em28xx soundcard for output or my own internal soundcard? tvtime only uses ALSA, but my internal soundcard as OSS mixer emulation (the em28xx has not). However, I cannot control the volume in tvtime Alsa says that the em28xx soundcard has no mixer controls. Hello Pedro, Tvtime doesn't support reading on ALSA devices - this is an issue not specific to the em28xx, but effects pretty much every modern tuner - tvtime was written during a time when capture cards had a line out cable that you would connect to speakers. I've written about the topic at length on the kernellabs.com blog if you want more info. Note that the em28xx provides a PCM *input* device. To get audio, you will typically read on the em28xx PCM device and output to your sound card. To make it work in tvtime, run tvtime, open a separate window, and try the following: arecord -D hw:1,0 -c 2 -r 48000 -f S16_LE | aplay - (assuming that the em28xx board is detected as 1,0 if you run arecord -l) Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 21, 2009 at 12:21 PM, Takashi Iwai ti...@suse.de wrote: Just a very quick look through the files, here are some comments: - snd_card_free() can't be called with NULL, but the error path in snd_cx18_init() may reach that (when snd_card_create() returns an error). - Specifying both SNDRV_PCM_RATE_CONTINOUS and _KNOT to snd_pcm_hw_info.rates doesn't make sense. In your case, if it's only 48kHz, SNDRV_PCM_RATE_48000 there instead. - vfree() should be called in hw_free callback rather than close callback. And, there are already global vmalloc-buffer helper functions in the latest ALSA tree for 2.6.34... - It'd be nice if you give TLV information for the mixer dB mapping. Hello Takashi, Thanks for taking the time to provide feedback. I will make these changes and add them to the tree. Out of curiosity, is there any sort of tool/code which exercises the driver to verify the advertised capabilities. Part of the problem here is that it is not really easy to find example applications which use all the features, which I suspect is one of the big headaches that the PulseAudio people are suffering from in that they are finding bugs in ALSA drivers because they are the first ones to actually attempt to use some of these capabilities. For me the card works, but then some user complains that their PulseAudio is broken because I didn't setup the config structures properly or only half-implemented some capability used by PulseAudio but not arecord/aplay. 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 PVR-150 Vertical sync issue?
On Mon, Dec 21, 2009 at 3:09 PM, Robert Longfield robert.longfi...@gmail.com wrote: Well it gets even better. So on the weekend I was able to steal a few minutes to properly trouble shoot the issue now that I know it was in the mythbuntu box. As a long shot I pulled out the Promise Tech Ultra133 TX2 / ATA card I am using for the backup drive. With this card removed the sync issue went away, when I put the card back in the issue returned. Now this card was in the slot right next to the PVR-150 card. I moved the controller card as far away as I could get from the PVR-150 and the sync issue was gone. So it would appear that the Promise Tech card was causing some EM interference with the PVR-150 card. I will keep an eye on this to make sure that this was indeed the issue. Does it seem reasonable that this card would kick out interference like this? Having worked at a lab that did EMI compliance testing, I can definitely tell some stories of cases far stranger than that. But yeah, if the card works in a different slot, then it's unlikely any sort of PCI bus congestion issue but rather an EMI problem. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 21, 2009 at 10:24 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: In the case of this patch series, the complains are not related to 80 cols: snip In this case, there was a mix of 80-column issues, as well as some other issues. I did fix the issues other than the 80-column issues through patches added to the tree last night (and in fact I did fix all the 80 column issues in my actual changes - but did not fix 80 column issues that happened to appear in the diff but were pre-existing). Please let me know if you have any other issues. 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 PCTV Hybrid (2) dvb woes
On Sun, Dec 20, 2009 at 12:07 PM, Pedro Ribeiro ped...@gmail.com wrote: Hello all, I'm having trouble setting up DVB for my Pinnacle PCTV Hybrid Stick (2), AKA 330e. You can check the linux-media archives for more info, but I can tell you that the 330e is not currently supported for DVB mode (analog only). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Mon, 14 Dec 2009 11:10:50 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. Yep. Btw, there are a few CodingStyle issues. Please send later a patch fixing it. I'll be reviewing the patch series. Cheers, Mauro Sorry about the delay on this. I took a pass over the files and cleaned up the bulk of the codingstyle issues. The remaining issues on the cx18-driver.c were pre-existing and the change is not obvious (probably needs input from the maintainer). There is still one warning about an #if 0 case in cx18-alsa-main.c, but this is being left there because it is a hook into the mixer routines, which are currently not supported (there is a cx18-alsa-mixer.c file but none of the controls are implemented yet). I added the patches to the original hvr-1600-alsa-2 tree, since the tree has not been merged yet. 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] https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2/
Hello Mauro, Please PULL from https://www.kernellabs.com/hg/~dheitmueller/em28xx-pal-vbi-2 for the following: em28xx: add PAL support for VBI This basically just goes back and fixes up the VBI support so that it is no longer NTSC specific (fixing constants and properly setting up the VBI region based on the standard). Validated against a Teletext stream in New Zealand (as well as regression tested against an NTSC source). Thanks again go out to EyeMagnet Limited for sponsoring this work. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sun, Dec 20, 2009 at 10:28 PM, Andy Walls awa...@radix.net wrote: Hmmm on the current v4l-dvb tree, the command $ v4l/scripts/checkpatch.pl --no-tree --strict \ -f linux/drivers/media/video/cx18/cx18-driver.c yields warnings about pre-existing 80 column lines and LINUX_VERSION_CODE checks. Was there something else? No, that's what I'm talking about. I figured if you wanted to split the CX18_ERR messages to fit on 80 columns, that is really at your discretion, not mine. I can certainly do it, of course, but I personally believe it's one of those cases where it is better to not split them. 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: Adaptec VideOh! DVD Media Center
On Fri, Dec 18, 2009 at 9:05 AM, Paulo Assis pj.as...@gmail.com wrote: Hi, I'm currently porting the GPL linux-avc2210k driver ( http://www.freelists.org/archive/linux-avc2210k/ ) to V4L2. The current version has it's own API that makes it incompatible with any software except for specific user space apps (avcctrl, avctune) bundled with the driver. Since development seems to have halted for some time now, I had no other choice than get my hands dirty :( For the most part this task seems quite straight forward it's mostly a matter of changing ioctls to V4L2 and add some missing support, there are however a few points that I need some advice on: For the box to function it needs a firmware upload. Currently this is managed by a udev script that in turn calls an application (multiload) that provides for the upload. What I would like to know is, if this the best way to handle it? The problem with this process is that it will always require installing and configuring additional software (multiload and udev script), besides the firmware. Is there any simpler/standard way of handling these firmware uploads ? Regards, Paulo Hi Paulo, I would start by looking at the request_firmware() function, which is used by a variety of other v4l cards. 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye 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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Em Mon, 14 Dec 2009 11:10:50 -0500 Devin Heitmueller dheitmuel...@kernellabs.com escreveu: On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: I can't pull. Your site is not responding. Hmm... it seems a temporary failure. It is working now. That is strange (works fine from here). You reported a similar issue trying to pull one of Michael Krufky's trees last week. I will have to keep an eye on it. Yep. Btw, there are a few CodingStyle issues. Please send later a patch fixing it. No problem. I will take care of these tonight (some of them are unrelated to my changes but happened to appear in the diff so they got flagged). Also, I am tempted to set the cx18 alsa driver to only work for kernels 2.6.25, so that I don't need any of the PCM lock changes, which are totally unvalidated and not needed by the customer. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
On Sat, Dec 12, 2009 at 5:34 PM, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi Devin, It is better to submit the RFC patches to alsa ML for they to take a look. Cheers, Mauro Is there something specific you want the ALSA people to review? There are no changes to the ALSA core and this is a pretty simple/straightforward PCM capture device modelled after the existing cx88/saa7134/em28xx-alsa drivers. The driver is complete, tested by both KernelLabs and the customer. As far as I know, we generally haven't bothered the ALSA people with devices in the /media tree in the past unless there was some specific issue. If there is something here out of the ordinary here that you felt the ALSA people would be able to offer some insight on, I would be more than happy to send it to them. 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] au8522: modify the attributes of local filter coefficients
2009/12/13 Németh Márton nm...@freemail.hu:
From: Márton Németh nm...@freemail.hu
Make the local filter coefficients static and const. This will eliminate the
following sparse warnings (see make C=1):
* au8522_decoder.c:71:31: warning: symbol 'filter_coef' was not declared.
Should it be static?
* au8522_decoder.c:113:31: warning: symbol 'lpfilter_coef' was not declared.
Should it be static?
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r e2f13778b5dc linux/drivers/media/dvb/frontends/au8522_decoder.c
--- a/linux/drivers/media/dvb/frontends/au8522_decoder.c Sat Dec 12
17:25:43 2009 +0100
+++ b/linux/drivers/media/dvb/frontends/au8522_decoder.c Sun Dec 13
21:16:25 2009 +0100
@@ -68,7 +68,7 @@
The values are as follows from left to right
0=ATV RF 1=ATV RF13 2=CVBS 3=S-Video 4=PAL 5=CVBS13 6=SVideo13
*/
-struct au8522_register_config filter_coef[] = {
+static const struct au8522_register_config filter_coef[] = {
{AU8522_FILTER_COEF_R410, {0x25, 0x00, 0x25, 0x25, 0x00, 0x00, 0x00} },
{AU8522_FILTER_COEF_R411, {0x20, 0x00, 0x20, 0x20, 0x00, 0x00, 0x00} },
{AU8522_FILTER_COEF_R412, {0x03, 0x00, 0x03, 0x03, 0x00, 0x00, 0x00} },
@@ -110,7 +110,7 @@
0=SIF 1=ATVRF/ATVRF13
Note: the ATVRF/ATVRF13 mode has never been tested
*/
-struct au8522_register_config lpfilter_coef[] = {
+static const struct au8522_register_config lpfilter_coef[] = {
{0x060b, {0x21, 0x0b} },
{0x060c, {0xad, 0xad} },
{0x060d, {0x70, 0xf0} },
--
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
Acked-by: Devin Heitmueller dheitmuel...@kernellabs.com
--
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/hvr-1600-alsa-2
Hello Mauro, Please pull from http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the following: cx18-alsa: fix memory leak in error condition cx18-alsa: remove a couple of warnings cx18-alsa: name alsa device after the actual card cx18: cleanup cx18-alsa debug logging cx18: rework cx18-alsa module loading to support automatic loading cx18-alsa: remove unneeded debug line cx18: export more symbols required by cx18-alsa cx18: add cx18-alsa module to Makefile cx18: overhaul ALSA PCM device handling so it works cx18: export a couple of symbols so they can be shared with cx18-alsa cx18: make it so cx18-alsa-main.c compiles cx18: rename cx18-alsa.c cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss cx18-alsa: Initial non-working cx18-alsa files I would also like to take this opportunity to thank ONELAN Limited for their sponsoring of this work, as well as to Andy Walls for providing some initial code and guidance on how to best integrate the ALSA support with the rest of the cx18 driver. 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: Firmware for dib0700
On Thu, Dec 10, 2009 at 1:28 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi David, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git master For dib0700 firmware. Mauro, I had David pull in this firmware months ago (so it could be included in time for the release of Ubuntu Karmic): http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=commit;h=f20b0674534a444ae74239843cac19f72c64912b Am I missing something? 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: Firmware for dib0700
On Thu, Dec 10, 2009 at 2:21 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Devin Hmm... sorry, it seems I missed your pull request. I'll need to re-check my git update script here... I should have been able to notice it. Because of the timeliness for Karmic (they actually moved it from their linux-firmware to their linux-firmware-nonfree package a couple of weeks before their release), I dealt with David directly rather than submitting it as a patch to the linux-media 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: [PATCH] sound/usb: Relax urb data alignment restriciton for HVR-950Q only
Hello John, On Thu, Dec 10, 2009 at 8:38 PM, John S Gruber johnsgru...@gmail.com wrote: I think you found something in the specification I haven't found. What did you see that indicated how to deal with equipment misbehaving in this way? I'm referring to section 2.3.2.3 of Universal Serial Bus Device Class Definition for Audio Data Formats I found the following list of USB ID's. Just double checking, but is the 850 enough like the 950 line for me to include it? case 72000: /* WinTV-HVR950q (Retail, IR, ATSC/QAM */ case 72001: /* WinTV-HVR950q (Retail, IR, ATSC/QAM and analog video */ case 72211: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and analog video */ case 72221: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and analog video */ case 72231: /* WinTV-HVR950q (OEM, IR, ATSC/QAM and analog video */ case 72241: /* WinTV-HVR950q (OEM, No IR, ATSC/QAM and analog video */ case 72251: /* WinTV-HVR950q (Retail, IR, ATSC/QAM and analog video */ -- case 72301: /* WinTV-HVR850 (Retail, IR, ATSC and analog video */ case 72500: /* WinTV-HVR950q (OEM, No IR, ATSC/QAM */ Yes, the HVR-850 should be included in the list. I'd add that being the beginner at making kernel changes your review is particularly helpful to me (and to my confidence). You are likely to receive a more thorough/critical review when you send to the alsa-devel mailing list, as they have considerably more expertise in this area than I do. 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 from source on 2.6.31.5 opensuse kernel - not working
On Wed, Dec 9, 2009 at 12:14 PM, Valerio Bontempi Hi Paulo, no luck with your suggestion, I have no errors compiling and installing the drivers but after rebooting it is not working at all. Modprobe em28xx produces the same error already sent in the previous mail You're seeing an error when you modprobe? What is the error? Your dmesg did not show any errors, just that the driver didn't load. 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 from source on 2.6.31.5 opensuse kernel - not working
On Wed, Dec 9, 2009 at 12:49 PM, Valerio Bontempi Hi Devin attached you find the output.log requested Thanks a lot Ah, there is your problem. You have updates installed, presumably by your distro. /lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/video/em28xx /lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/video/em28xx/em28xx-alsa.ko /lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/video/em28xx/em28xx-dvb.ko /lib/modules/2.6.31.5-0.1-desktop/updates/kernel/drivers/media/video/em28xx/em28xx.ko Those modules are conflicting with the base modules you replaced when you installed the latest 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
Re: v4l-dvb from source on 2.6.31.5 opensuse kernel - not working
On Wed, Dec 9, 2009 at 1:21 PM, Valerio Bontempi I don't know how it is happened, because I followed the normal way to compile v4l-dvb, so it seems a very strange behaviour... however, how can I solve, cleaning out all the in-kernel modules and all the modules I need to remove? Well, the problem wasn't that you compiled v4l-dvb. It's that you had these third party em28xx modules installed (which rely on v4l-dvb). And a recompile of v4l-dvb breaks compatibility for those third party modules. Without knowing how you installed the third party em28xx stuff, I cannot really advise you on the best way to remove them. If it were me, I would probably just move all of those files to some temporary directory and reboot (which would allow me to restore them if I screwed something up). However, I wouldn't want to be held responsible for a user screwing up his machine. 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] WinTV HVR-900 USB (B3C0)
On Tue, Dec 8, 2009 at 12:35 PM, Rob Beard r...@esdelle.co.uk wrote: Hi folks, I've borrowed a WinTV HVR-900 USB stick from a friend of mine to see if I can get any reception in my area before forking out for one however I've run in to a couple of problems and wondered if anyone had used one of these sticks? The device appears to support both analogue and DVB-T (Freeview) TV however when I plug the device in it only appears to enable the analogue side of things (it comes up as /dev/video1 as I have a webcam on my laptop). I've downloaded and installed the firmware in /lib/firmware as per the instructions on the LinuxDVB web site and it appears to pick it up and I've even tried compiling the v4l-dvb drivers too which didn't appear to make any difference. Just to check it wasn't me going mad, I tried the dvb-utils scan utility and also Kaffene, both of which doesn't work (and I can't find a /dev/dvb directory either). If it helps, the output from /var/log/messages is here: http://pastebin.com/m34f1048f I just wondered if anyone else had one of these sticks actually working under Ubuntu 9.10? (I'm running kernel 2.6.31-16-generic-pae). The DVB-T portion of that particular board is unsupported (I have some code in the works but there are issues with the firmware redistribution rights). 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] sound/usb: Relax urb data alignment restriciton for HVR-950Q only
On Fri, Dec 4, 2009 at 6:26 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Fri, Dec 4, 2009 at 5:15 PM, John S Gruber johnsgru...@gmail.com wrote: Addressing audio quality problem. In sound/usb/usbaudio.c, for the Hauppage HVR-950Q only, change retire_capture_urb to copy the entire byte stream while still counting entire audio frames. urbs unaligned on channel sample boundaries are still truncated to the next lowest stride (audio slot) size to try to retain channel alignment in cases of data loss over usb. With the HVR950Q the left and right channel samples can be split between two different urbs. Throwing away extra channel samples causes a sound quality problem for stereo streams as the left and right channels are swapped repeatedly. snip Hello John, Thanks for taking the time to dig into this. I will try to review your patch this weekend (in conjunction with the spec). It's worth noting that there are actually nine different USB IDs that would need this change (see au0828-cards.c), so it might be nice to see if we can figure out a way for the au0828 driver to tell the usbaudio driver about the quirk without relying on embedding USB ids in the usbaudio driver. Hi John, After reviewing the patch as well as the spec, your change looks pretty reasonable (aside from the fact that you need the other USB IDs). It seems pretty clear that the au0828 violates the spec, but the spec does indicate how to handle that case, which is what your code addresses. All that said, the driver in question is managed by the ALSA project. I would suggest posting a message with your patch on the alsa-devel mailing list, so that it can be merged (and in fairness, those guys are much better suited to review your patch). On a separate note, I've been doing some testing with the device in a low-latency application, and I think I've spotted a separate bug in the usbaudio driver that causes the audio capture to stall. I'll be sending some email myself to alsa-devel as soon as I can test a patch. 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: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
On Fri, Dec 4, 2009 at 9:31 AM, John S Gruber johnsgru...@gmail.com wrote: I produced the dump of URB sizes you requested by adding that printk() line. The results are at http://pastebin.com/f26f29133 Hi John, This is good info (especially since you have kernel timestamps enabled). Did you have a specific reference to the USB audio spec which said the packet size has to be on an integer boundary? I took a look at the spec last night and didn't see anything to that end. Do you have a proposed patch to usbaudio.c which works for you? If so, feel free to send it along and I will review and provide comments. If the spec does not require the packets to be on an integer boundary, perhaps the driver just improperly assumes they will be (and they were for whatever developer wrote the original 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: [PATCH] sound/usb: Relax urb data alignment restriciton for HVR-950Q only
On Fri, Dec 4, 2009 at 5:15 PM, John S Gruber johnsgru...@gmail.com wrote: Addressing audio quality problem. In sound/usb/usbaudio.c, for the Hauppage HVR-950Q only, change retire_capture_urb to copy the entire byte stream while still counting entire audio frames. urbs unaligned on channel sample boundaries are still truncated to the next lowest stride (audio slot) size to try to retain channel alignment in cases of data loss over usb. With the HVR950Q the left and right channel samples can be split between two different urbs. Throwing away extra channel samples causes a sound quality problem for stereo streams as the left and right channels are swapped repeatedly. snip Hello John, Thanks for taking the time to dig into this. I will try to review your patch this weekend (in conjunction with the spec). It's worth noting that there are actually nine different USB IDs that would need this change (see au0828-cards.c), so it might be nice to see if we can figure out a way for the au0828 driver to tell the usbaudio driver about the quirk without relying on embedding USB ids in the usbaudio driver. 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: af9015: tuner id:179 not supported, please report!
On Thu, Dec 3, 2009 at 4:47 PM, Bert Massop bert.mas...@gmail.com wrote: Hi Jan, The datasheet for the TDA18218 can be obtained from NXP: http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf That's all the information I have at the moment, maybe Mike has some other information (like the Application Note mentioned in the datasheet, that claims to contain information on writing drivers, but cannot be found anywhere). Best regards, Bert Took a quick look at that datasheet. I would guess between that datasheet and a usbsnoop, there is probably enough there to write a driver that basically works for your particular hardware if you know what you are doing. The register map is abbreviated, but probably good enough... 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: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
On Thu, Dec 3, 2009 at 11:00 PM, John S Gruber johnsgru...@gmail.com wrote: I have problems with my audio that I've tracked down to the transfer of audio from the au0828 in my hvr-950Q. I spotted the following comment about green screen detection and I wonder if it might be related. drivers/media/video/au0828/au0828-video.c: /* Workaround for a bug in the au0828 hardware design that sometimes results in the colorspace being inverted */ The problem is that sound/usb/usbaudio.c assumes that each urb data field contains an integer number of audio frames (aka audio slots), in this case a integer number of left channel-right channel pairs. About 12 times a second for my device a urb doesn't. This causes a flutter noise with non-quiet audio that contains a difference between the channels. I found this by using audacity to look at wave forms and a usb trace to see the problematic urb's. I've confirmed by relaxing the constraint in sound/usb/usbaudio.c with a patch and can confirm that it clears up the audio. Is the code comment at the top related to my problem? More importantly, is there the possibility of setting up the transfer differently so that audio slots aren't split between urbs? From what I have read in the spec I believe the split of the audio slots between urb's is non- conformant. Therefore I think it would be a mistake to change the default behaviour of usbaudio.c since, as it is now,usbaudio.c won't swap channels in the case of dropped urbs. It would be optimal if the hvr-950q could be set up to conform by not splitting audio slots. I think the problem also occurs for video when blue will turn to pink for a flash until the top of frame resyncs things up--because of the corresponding swap of UY with VY. This seems to be related to how busy my system is and what usb slot I'm using on my laptop. Again I could see in a usb trace the urb's with data_lengths such that UY would be split from the corresponding VY. The video transfer is a straight byte copy so ordinarily this isn't a problem but would be if an abnormally sized urb were dropped and the device and host were to get out of sync regarding V and U. I also have caught an occasional odd number of bytes transferred in traces, which requires the drop of incomplete samples in usbaudio.c. I wonder if this is related to the green screen problem on video from the top comment. The easiest way to reproduce the audio problem is to use the composite video input but only hook up either the left or the right audio. With earphonesyou can hear the audio rapidly go from ear to ear. Thanks for those on the list for their hard work on getting devices such as this to work. I'd appreciate any answers, comments, corrections, or information. Hi John, I have actually actively debugging the au0828 audio this evening. The comment you referred to (which I wrote) has to do with the delivery of the UYVY data from the demodulator to the au0828 bridge, which can cause the start of the stream to be off-by-one (the pink/green you see is the colorspace inverted when the decoder loses sync). It is unrelated to audio. I'm working an issue now where the audio keeps dropping out. If you want to show me the code change you did to usbaudio.c, it might give me a better understand the issue. 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: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video
On Thu, Dec 3, 2009 at 11:21 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Dec 3, 2009 at 11:00 PM, John S Gruber johnsgru...@gmail.com wrote: I have problems with my audio that I've tracked down to the transfer of audio from the au0828 in my hvr-950Q. I spotted the following comment about green screen detection and I wonder if it might be related. drivers/media/video/au0828/au0828-video.c: /* Workaround for a bug in the au0828 hardware design that sometimes results in the colorspace being inverted */ The problem is that sound/usb/usbaudio.c assumes that each urb data field contains an integer number of audio frames (aka audio slots), in this case a integer number of left channel-right channel pairs. About 12 times a second for my device a urb doesn't. This causes a flutter noise with non-quiet audio that contains a difference between the channels. I found this by using audacity to look at wave forms and a usb trace to see the problematic urb's. I've confirmed by relaxing the constraint in sound/usb/usbaudio.c with a patch and can confirm that it clears up the audio. Is the code comment at the top related to my problem? More importantly, is there the possibility of setting up the transfer differently so that audio slots aren't split between urbs? From what I have read in the spec I believe the split of the audio slots between urb's is non- conformant. Therefore I think it would be a mistake to change the default behaviour of usbaudio.c since, as it is now,usbaudio.c won't swap channels in the case of dropped urbs. It would be optimal if the hvr-950q could be set up to conform by not splitting audio slots. I think the problem also occurs for video when blue will turn to pink for a flash until the top of frame resyncs things up--because of the corresponding swap of UY with VY. This seems to be related to how busy my system is and what usb slot I'm using on my laptop. Again I could see in a usb trace the urb's with data_lengths such that UY would be split from the corresponding VY. The video transfer is a straight byte copy so ordinarily this isn't a problem but would be if an abnormally sized urb were dropped and the device and host were to get out of sync regarding V and U. I also have caught an occasional odd number of bytes transferred in traces, which requires the drop of incomplete samples in usbaudio.c. I wonder if this is related to the green screen problem on video from the top comment. The easiest way to reproduce the audio problem is to use the composite video input but only hook up either the left or the right audio. With earphonesyou can hear the audio rapidly go from ear to ear. Thanks for those on the list for their hard work on getting devices such as this to work. I'd appreciate any answers, comments, corrections, or information. Hi John, I have actually actively debugging the au0828 audio this evening. The comment you referred to (which I wrote) has to do with the delivery of the UYVY data from the demodulator to the au0828 bridge, which can cause the start of the stream to be off-by-one (the pink/green you see is the colorspace inverted when the decoder loses sync). It is unrelated to audio. I'm working an issue now where the audio keeps dropping out. If you want to show me the code change you did to usbaudio.c, it might give me a better understand the issue. I am definitely seeing what you are saying with regards to the channel flipping back and forth. Do you know what size URBs are being delivered? If you've got a hacked up version of usbaudio.c, how about adding a printk() line which dumps out the URB size and send me a dump? 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: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression
On Tue, Dec 1, 2009 at 4:18 AM, Vincent McIntyre vincent.mcint...@gmail.com wrote: Hi Rob I missed your followup and tested the 'revert.diff' patch, attached for reference. I have been slow replying because I've been scratching my head over the results. I used 'signaltest.pl' to test[1], which uses tzap under the hood. Perhaps this is not the best choice, but I wanted something that I thought would allow objective comparisons. That's trickier than I thought... Unfortunately I only discovered last night how easy 'vlc ./channels.conf' makes doing quick visual checks. I didn't have enough time to re-patch and test again. My test procedure was: - get a baseline with tzap and signaltest.pl - patch, make, install. cold boot. - test with tzap and signaltest.pl - revert patch, for the moment. I tested two kernels, and both cards. I tested all the tuners but I'll spare you that for now. * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip) I got rather different baseline results. All channels had significantly higher BER than I'd noticed before. After patching, snr on some channels seemed a little higher and BER was lower. On ch9, I think snr was up and BER improved a little. here are the signaltest summary tables: without patch. usb device (dvb0) usbid db78:0fe9 Frequency Signal Ber Unc = 17750 76.0 % 322.6 672.4 Seven 191625000 76.0 % 320.2 1783.3 Nine 21950 76.8 % 329.8 2948.2 Ten 22650 76.9 % 296.6 4885.0 ABC 57150 77.0 % 542.0 7529.4 SBS 57850 77.1 % 539.5 10669.7 D44 with patch. usb device (dvb0) usbid db78:0fe9 Frequency Signal Ber Unc = 17750 76.6 % 2.3 0.0 191625000 77.0 % 235.5 83.3 21950 76.9 % 288.0 501.8 22650 76.9 % 295.1 1416.4 57150 77.0 % 523.4 3980.0 57850 77.1 % 549.9 7409.4 without patch. pcie device (dvb1) pciid db78:18ac Frequency Signal Ber Unc = 17750 71.2 % 3.1 0.0 191625000 21.7 % 645.4 246.4 21950 73.6 % 1.9 1632.0 22650 73.5 % 2.8 1632.0 57150 73.9 % 13.6 2134.6 57850 72.7 % 58.2 6393.4 with patch. pcie device (dvb1) pciid db78:18ac Frequency Signal Ber Unc = 17750 73.2 % 4.0 0.0 191625000 74.0 % 37.0 0.0 21950 73.9 % 0.0 0.0 22650 73.0 % 4.6 0.0 57150 74.2 % 76.7 193.6 57850 72.8 % 213.8 4480.3 * 2.6.31-14-generic + v4l (19c0469c02c3+ tip) Hard to say if I'm seeing an improvement. before patching - adapter0 usbid db78:0fe9 Frequency Signal Ber Unc = 17750 75.5 % 293.7 1926.4 191625000 75.9 % 363.2 2993.3 21950 76.7 % 304.5 4225.8 22650 76.9 % 223.8 6153.3 57150 77.0 % 491.7 8726.0 57850 77.1 % 558.9 11787.1 adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..) Frequency Signal Ber Unc = 17750 75.9 % 327.9 13893.6 191625000 76.0 % 392.8 14939.0 21950 76.7 % 252.0 16052.0 22650 76.8 % 254.0 18063.1 57150 76.9 % 533.2 20644.1 57850 76.9 % 464.1 23836.8 after patching - adapter0 usbid db78:0fe9 Frequency Signal Ber Unc = 17750 76.3 % 2.5 0.0 191625000 76.8 % 227.6 119.0 21950 76.8 % 262.6 604.5 22650 76.8 % 282.7 1545.4 57150 77.0 % 486.8 3541.7 57850 77.1 % 521.5 6537.7
Re: [RFC v2] Another approach to IR
On Tue, Dec 1, 2009 at 12:03 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Just taking an example from the dibcom0700 driver (as the same driver supports several different RC5 and NEC codes at the same time), the kernel table has several keycodes added there, all working at the same time. Providing that the scancodes won't overlap, you can map two different scancodes (from different IR's) to return the same keycode (table is not complete - I just got a few common keycodes): Mauro, Just to be clear, the dib0700 does not actually support receiving RC5 or NEC codes at the same time. You have to tell the chip which mode to operate in, via a REQUEST_SET_RC to the firmware (see dib0700_core.c:405). The em28xx works the same way (you have to tell it what type of IR format to receive). The fact that the driver currently uses the same lookup table for both types of remote controls however, was perhaps not the best design choice. It really should be separated out, and merged with the regular ir-functions.c. I just never got around to 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: PULL request - http://kernellabs.com/hg/~pboettcher/v4l-dvb/
On Mon, Nov 30, 2009 at 12:28 PM, Patrick Boettcher - Add support for PCTV 74e (Pinnacle) + fix USB vendor IDs Patrick, You added the USB ID for the 74e? Is that the result of actually trying it with the hardware? As far as I know, the 74e is not a Dibcom design. 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: Reprise of YUV frame alignment improvements
On Tue, Nov 24, 2009 at 6:39 PM, Andy Walls awa...@radix.net wrote: BTW, I did a quick skim of your cx18-alsa stuff. I noticed two things: 1. A memory leak in an error path: http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2/rev/cb267593943f#l85 2. Technically open_id should probably be changed to an atomic type and atomic_inc() used: http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2/rev/cb267593943f#l80 Under normal use it will likely never matter though, but perhaps someone could use it as a possible exploit. I'll try and give the code a good review and test sometime this weekend. I just wanted to let you know about those minor bugs before I forgot. Thanks for taking the time to review. I will make both of those changes early next 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: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson ja...@wilsonet.com wrote: Took me a minute to figure out exactly what you were talking about. You're referring to the current in-kernel decoding done on an ad-hoc basis for assorted remotes bundled with capture devices, correct? Admittedly, unifying those and the lirc driven devices hasn't really been on my radar. This is one of the key use cases I would be very concerned with. For many users who have bought tuner products, the bundled remotes work out-of-the-box, regardless of whether lircd is installed. I have no objection so much as to saying well, you have to install the lircd service now, but there needs to be a way for the driver to automatically tell lirc what the default remote control should be, to avoid a regression in functionality. We cannot go from a mode where it worked automatically to a mode where now inexperienced users now have to deal with the guts of getting lircd properly configured. If such an interface were available, I would see to it that at least all the devices I have added RC support for will continue to work (converting the in-kernel RC profiles to lirc RC profiles as needed and doing the associations with the driver). The other key thing I don't think we have given much thought to is the fact that in many tuners, the hardware does RC decoding and just returns NEC/RC5/RC6 codes. And in many of those cases, the hardware has to be configured to know what format to receive. We probably need some kernel API such that the hardware can tell lirc what formats are supported, and another API call to tell the hardware which mode to operate in. This is why I think we really should put together a list of use cases, so that we can see how any given proposal addresses those use cases. I offered to do such, but nobody seemed really interested in this. 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
