Re: Support for RC-6 in em28xx driver?
2012/1/5 Simon Søndergaard john7...@gmail.com: 2012/1/5 Devin Heitmueller dheitmuel...@kernellabs.com: 2012/1/5 Simon Søndergaard john7...@gmail.com: Hi, I recently purchased a PCTV 290e USB Stick (em28174) it comes with a remote almost as small as the stick itself... I've been able to get both stick and remote to work. I also own an MCE media center remote from HP (this make http://www.ebay.com/itm/Original-Win7-PC-MCE-Media-Center-HP-Remote-Controller-/170594956920) that sends RC-6 codes. While it do have a windows logo I still think it is vastly superior to the one that shipped with the stick :-) If I understand it correctly em28174 is a derivative of em2874? In em28xx-input.c it is stated that: em2874 supports more protocols. For now, let's just announce the two protocols that were already tested I've been searching high and low for a datasheet for em28(1)74, but have been unable to find it online. Do anyone know if one of the protocols supported is RC-6? and if so how do I get a copy of the datasheet? The 2874 supports NEC, RC-5, and RC-6/6A. I did the original support (based on the docs provided under NDA) but ironically enough I didn't have an RC6 remote kicking around so I didn't do the support for it. IR receivers for MCE devices are dirt cheap ( $20), and if you're doing a media center then it's likely the PCTV 290e probably isn't in line-of-site for a remote anyway. The 290e will be in line of sight. Perhaps the info is already there, not sure why I overlooked it in the first place: EM2874_IR_RC6_MODE_0 0x08 EM2874_IR_RC6_MODE_6A 0x0b Ah, so I guess I did put at least some of the info into the driver. Also, for RC6 make sure bits 0-1 are 00 and for RC6A they need to be set based on the number of bytes expected to be received (2 bytes=00, 3bytes=01, 4bytes=10). The received data gets stored in 0x52-0x55 (I don't remember if the driver actually looks are 0x54/55 currently since they aren't used for NEC or RC5).. RC5 and RC6 use same carrier frequency? so do I need another value for EM28XX_R0F_XCLK? You shouldn't need to touch the XCLK register. Good luck! 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: Support for RC-6 in em28xx driver?
On Thu, Jan 5, 2012 at 5:48 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Yes, it can. Like almost every IR receiver provided by the linux media subsystem, the 290e is configured with the keymap of the pinnacle remote *by default*. There are userland tools (e.g. ir-keytable) which allow you to load keymaps in for other remotes. I should clarify my previous statement by saying that the support for other remotes is constrained by what the hardware supports. If the IR receiver hardware only supports RC5 and NEC, then you can't use an RC6 remote with it. But to your point, I actually used my Hauppauge remote when I originally wrote the em2874 IR support (and only at the end reconfigured it to use the PCTV remote). 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: em2874 bulk endpoint support
On Thu, Jan 5, 2012 at 6:16 PM, Dmitriy Fitisov dmit...@radier.ca wrote: Hello everyone, I know, Devin Heitmueller was about to add support for em2874 bulk endpoint. Is that still in plans? The project that I was slated to do this work for got cancelled, and the only device I know of that requires bulk support is an obscure K-world product. It just didn't make any sense to waste the time for one unpopular stick. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Working on Avermedia Duet A188 (saa716x and lgdt3304)
On Tue, Jan 3, 2012 at 1:05 PM, Tim richard...@hotmail.com wrote: Currently I I am trying to attach the lgdt3304 at i2c address 0x0e on bus A then try to attach the tda1827hdc2.. but the lgdt3304 never attaches Just a suggestion: These sorts of problems are usually either you're trying to talk to the device on the wrong i2c bus, or the chip is being held in reset by a GPIO. Also possible that it's bound to a different i2c address (most demods let you pick between a couple of addresses based on a pullup resistor on a particular pin. 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_isoc_dvb_max_packetsize for EM2884 (Terratec Cinergy HTC Stick)
On Sun, Dec 25, 2011 at 9:11 AM, Hans Petter Selasky hsela...@c2i.net wrote: These numbers should not be hardcoded, but extracted from the USB endpoint descriptor! --HPS Hans is correct. I only hard-coded it at 564 as a quick hack when I was bootstrapping the em2784 support. The code really should be cleaned up to base it off of the endpoint descriptors. Patches certainly welcome as this is indeed a known 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: Add tuner_type to zl10353 config and use it for reporting signal directly from tuner.
2011/12/21 Miroslav Slugeň thunder@gmail.com: XC4000 based cards are not using AGC control in normal way, so it is not possible to get signal level from AGC registres of zl10353 demodulator, instead of this i send previous patch to implement signal level directly in xc4000 tuner and now sending patch for zl10353 to implement this future for digital mode. Signal reporting is very accurate and was well tested on 3 different Leadtek XC4000 cards. For what it's worth, something seems very wrong with this patch. All the docs I've ever seen for the Xceive components were pretty clear that the signal level registers are for analog only. And even in te case of Xceive it's a bit unusual, since most analog tuner designs don't have an onboard analog demodulator. If this patch really works then I guess I don't have anything against it. I just strongly believe that it's the wrong fix and there is probably some other problem this is obscuring. 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: cx231xx kernel oops
On Mon, Dec 12, 2011 at 10:58 AM, Yan Seiner y...@seiner.com wrote: Also, just to be clear, the USB Live 2 doesn't have any onboard hardware compression. It has comparable requirements related to USB bus utilization as any other USB framegrabber. The only possible advantage you might get is that it does have an onboard scaler, so if you're willing to compromise on quality you can change the capture resolution to a lower value such as 320x240. Also, bear in mind that the cx231xx driver may not be properly tuned to reduce the alternate it uses dependent on resolution. To my knowledge that functionality has not been thoroughly tested (as it's an unpopular use case). OK, thanks. I was hoping this was a hardware framegrabber; the info on the website is so ambiguous as to be nearly useless. I think you're just confused about the terminology. The term framegrabber inherently means that it's delivering raw video (as opposed to having onboard compression and providing MPEG or some other compressed format). All framegrabbers are hardware framegrabbers. There were some *really* old devices that delivered the frames with JPEG or proprietary compression so that they fit within USB 1.1, but those designs are almost entirely gone given the hardware cost and the lack of need since almost everything nowadays is USB 2.0. You may wish to look at the HVR-1950, which is well supported under Linux and does deliver MPEG video. It's obviously more expensive that the USB Live 2 and it has a tuner which you probably don't need, but it does avoid the issue if you have USB bus constraints. 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: HVR-930C DVB-T mode report
On Mon, Dec 12, 2011 at 3:16 PM, Eddi De Pieri e...@depieri.net wrote: Hi to all, with latest git, w_scan partially working only if adding -t2 or t3. It seems that scan quality of w_scan is lower if compared to dvb_app scan Hi Eddi, A really useful test would be to run the exact same scan twice in a row and see if you get consistent results (in terms of the number of frequencies are found and which ones). It would be worthwhile to know if there's a consistent problem locking to certain frequencies, or whether you get a lock for any given frequency is random. Run the scan with the exact same parameters again and see if you get the same results. Such information will drive whether the developers need to investigate why certain frequencies always fail to lock, or whether there is a more general problem with tuning that results in lock failure regardless of frequency. 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: dvb_frontend: fix delayed thread exit
Hello Mauro, On Sat, Dec 10, 2011 at 5:28 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Devin, You're over-reacting. This patch were a reply from Andreas to a thread, and not a separate patch submission. Patches like are generally handled as RFC, especially since it doesn't contain a description. Any email that starts with WTF, Devin, you again? will probably not get a very polite response. I agree there's been some overreaction, but it hasn't been on my part. He took the time to split it onto a new thread, add the subject line PATCH, as well as adding an SOB. Even if his intent was only to get it reviewed, why should I waste half an hour of my time analyzing his patch to try to figure out his intent if he isn't willing to simply document it? You have a history of blindly accepting such patches without review. My only intent was to flag this patch to ensure that this didn't happen here. I've spent way more time than I should have to fixing obscure race conditions in dvb core. If the author of a patch cannot take the time to document his findings to provide context then the patch should be rejected without review until he does so. And why isn't this broken into a patch series? Even after you analyzed the patch you still don't understand what the changes do and why there are being made. Your explanation for why he added the mb() call was because Probably Andreas added it because he noticed some race condition. What is the race condition? Did he find multiple race conditions? Is this patch multiple fixes for a race condition and some other crap at the same time? If a developer wants a patch reviewed (as Andreas suggested was the case here after-the-fact), then here's my feedback: break this into a series of small incremental patches which *in detail* describe the problem that was found and how each patch addresses the issue. Once we have that, the maintainer can do a more in-depth analysis of whether the patch should be accepted. Code whose function cannot be explicitly justified but simply 'looks better' should not be mixed in with real functional 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
Re: [PATCH] [media] drxk: Switch the delivery system on FE_SET_PROPERTY
On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Could someone explain reason for that? I dunno, but I think this needs to be fixed, at least when the frontend is opened with O_NONBLOCK. Are you doing the drx-k firmware load on dvb_init()? That could easily take 4 seconds. 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: dvb_frontend: fix delayed thread exit
On Fri, Dec 9, 2011 at 8:37 PM, Andreas Oberritter o...@linuxtv.org wrote:
On 10.12.2011 00:43, Mauro Carvalho Chehab wrote:
On 09-12-2011 21:37, Mauro Carvalho Chehab wrote:
On 09-12-2011 20:33, Devin Heitmueller wrote:
On Fri, Dec 9, 2011 at 5:11 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Could someone explain reason for that?
I dunno, but I think this needs to be fixed, at least when the frontend
is opened with O_NONBLOCK.
Are you doing the drx-k firmware load on dvb_init()? That could
easily take 4 seconds.
No. The firmware were opened previously.
Maybe the delay is due to this part of dvb_frontend.c:
static int dvb_mfe_wait_time = 5;
...
int mferetry = (dvb_mfe_wait_time 1);
mutex_unlock (adapter-mfe_lock);
while (mferetry-- (mfedev-users != -1 ||
mfepriv-thread != NULL)) {
if(msleep_interruptible(500)) {
if(signal_pending(current))
return -EINTR;
}
}
I haven't looked at the mfe code, but in case it's waiting for the
frontend thread to exit, there's a problem that causes the thread
not to exit immediately. Here's a patch that's been sitting in my
queue for a while:
---
Signed-off-by: Andreas Oberritter o...@linuxtv.org
diff --git a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
index 7784d74..6823c2b 100644
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2011-09-07
12:32:24.0 +0200
+++ a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 2011-09-13
15:55:48.865742791 +0200
@@ -514,7 +514,7 @@
return 1;
if (fepriv-dvbdev-writers == 1)
- if (time_after(jiffies, fepriv-release_jiffies +
+ if (time_after_eq(jiffies, fepriv-release_jiffies +
dvb_shutdown_timeout * HZ))
return 1;
@@ -2070,12 +2070,15 @@
dprintk (%s\n, __func__);
- if ((file-f_flags O_ACCMODE) != O_RDONLY)
+ if ((file-f_flags O_ACCMODE) != O_RDONLY) {
fepriv-release_jiffies = jiffies;
+ mb();
+ }
ret = dvb_generic_release (inode, file);
if (dvbdev-users == -1) {
+ wake_up(fepriv-wait_queue);
if (fepriv-exit != DVB_FE_NO_EXIT) {
fops_put(file-f_op);
file-f_op = NULL;
This patch needs to have a much better explanation of exactly what it
does and what problem it solves. We have a history of race conditions
in dvb_frontend.c, and it's patches like this with virtually no
details just makes it worse.
I'm not arguing the actual merits of the code change - it *may* be
correct. But without the appropriate background there is no real way
of knowing...
Mauro, this patch should be NACK'd and resubmitted with a detailed
explanation of the current behavior, what the problem is, and how the
code changes proposed solve that 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: [PATCH] DVB: dvb_frontend: fix delayed thread exit
Hello Andreas, On Fri, Dec 9, 2011 at 9:06 PM, Andreas Oberritter o...@linuxtv.org wrote: WTF, Devin, you again? I haven't asked anyone to upstream it. Feel free to analyze the code and resubmit it. 1. It's marked with a subject line that starts with [PATCH] 2. It has your SIgned-Off-By line. 3. it was sent to the mailing list. 4. It doesn't have any keywords like RFC or proposed. If you don't intend for it to go upstream then don't do all of the above. I'm not sure if your WTF, Devin, you again? is some indication that I'm annoying you. The last patch you submitted that touches the threading in dvb_frontend.c had a host of problems and was clearly not well researched (i.e. DVB: dvb_frontend: convert semaphore to mutex). As in this case, there is no background indicating that this patch has been fully thought out and due diligence has been done. Maybe you have thoroughly researched the change, taken the time to fully understand its effects, and tested it with a variety of boards and scenarios. Without a good patch description, there is no way to know. I apologize if you're inconvenienced if I'm making an active effort to prevent poorly documented changes from getting merged (which often result in regressions). Oh wait, I'm not sorry at all. Nevermind. 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 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
On Tue, Dec 6, 2011 at 8:43 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: The driver who binds everything is the bridge driver. In your case, it is the au0828 driver. What you're experiencing seems to be some race issue inside it, and not at xc5000. On a quick look on it, I'm noticing that there's no lock at au0828_usb_probe(). Also, it uses a separate lock for analog and for digital: mutex_init(dev-mutex); mutex_init(dev-dvb.lock); Probably, the right thing to do would be to use just one lock for both rising it at usb_probe, lowering it just before return 0. This will avoid any open operations while the device is not fully initialized. Btw, newer udev's open the analog part of the driver just after V4L register, in order to get the device capabilities. This is known to cause race conditions, if the locking schema is not working properly. Just to be clear, we're now talking about a completely different race condition that has nothing to do with the subject at hand, and this discussion should probably be moved to a new thread. That said, yes, there is definitely a race (if not two) in there to be tracked down. I know of a couple of users who upgraded to more recent kernels and started experiencing breakage on module load where there was none before. This could obviously be dumb luck in that perhaps the timing changed slightly, or it could be some change in the core code which created a new race. I haven't had the time/energy to dig into the issue (compounded by the fact that these sorts of issues are notoriously difficult to debug when it cannot be reproduced locally by the developer). The notion that this is something that has been there for over a year is something I only learned of in the last couple of days. All the complaints I had seen thus far were from existing users who were perfectly happy until they upgraded their kernel a couple of months ago and then started seeing the 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: [PATCH 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
On Tue, Dec 6, 2011 at 10:28 AM, Mark Lord ker...@teksavvy.com wrote: It's always exhibited races for me here. I have long since worked around the issue(s), so my own systems currently behave. But with the newer HVR-950Q revision (B4F0), the issue is far more prevalent than before. I'll ask around and see if I can find out what they changed in the B4F0 revision. 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 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
On Sun, Nov 20, 2011 at 9:56 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
diff --git a/drivers/media/common/tuners/xc5000.c
b/drivers/media/common/tuners/xc5000.c
index ecd1f95..048f489 100644
--- a/drivers/media/common/tuners/xc5000.c
+++ b/drivers/media/common/tuners/xc5000.c
@@ -1004,6 +1004,8 @@ static int xc_load_fw_and_init_tuner(struct
dvb_frontend *fe)
struct xc5000_priv *priv = fe-tuner_priv;
int ret = 0;
+ mutex_lock(xc5000_list_mutex);
+
if (xc5000_is_firmware_loaded(fe) != XC_RESULT_SUCCESS) {
ret = xc5000_fwupload(fe);
if (ret != XC_RESULT_SUCCESS)
@@ -1023,6 +1025,8 @@ static int xc_load_fw_and_init_tuner(struct
dvb_frontend *fe)
/* Default to CABLE mode */
ret |= xc_write_reg(priv, XREG_SIGNALSOURCE, XC_RF_MODE_CABLE);
+ mutex_unlock(xc5000_list_mutex);
+
return ret;
}
What's up with this change? Is this a bugfix for some race condition?
Why is it jammed into a patch for some particular product?
It seems like a change such as this could significantly change the
timing of tuner initialization if you have multiple xc5000 based
products that might have a slow i2c bus. Was that intentional?
This patch should be NACK'd and resubmitted as it's own bugfix where
it's implications can be fully understood in the context of all the
other products that use xc5000.
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 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
On Mon, Dec 5, 2011 at 1:35 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: What's up with this change? Is this a bugfix for some race condition? Why is it jammed into a patch for some particular product? It seems like a change such as this could significantly change the timing of tuner initialization if you have multiple xc5000 based products that might have a slow i2c bus. Was that intentional? This patch should be NACK'd and resubmitted as it's own bugfix where it's implications can be fully understood in the context of all the other products that use xc5000. It is too late for nacking the patch, as there are several other patches were already applied on the top of it, and we don't rebase the linux-media.git tree. Assuming that this is due to some bug that Eddi picked during xc5000 init, what it can be done now is to write a patch that would replace this xc5000-global mutex lock into a some other per-device locking schema. At this point we have zero idea why it's there *at all*. Eddi, can you comment on what prompted this change? This patch should not have been accepted in the first place. It's an undocumented change on a different driver than is advertised in the subject line. Did you review the patch prior to merging? This change can result in a performance regression for all other devices using xc5000, and it's not yet clear why it's there in the first place. If its use cannot be explained then it should be rolled back. If this breaks 930c, then the whole device support series should be rolled back until somebody can figure out what is going on. It's crap like this that is the reason that every other week I get complaints from some user that one of the drivers I wrote support for worked fine for months/years until they upgraded to the latest kernel. 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 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
On Mon, Dec 5, 2011 at 1:46 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Dec 5, 2011 at 1:35 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: What's up with this change? Is this a bugfix for some race condition? Why is it jammed into a patch for some particular product? It seems like a change such as this could significantly change the timing of tuner initialization if you have multiple xc5000 based products that might have a slow i2c bus. Was that intentional? This patch should be NACK'd and resubmitted as it's own bugfix where it's implications can be fully understood in the context of all the other products that use xc5000. It is too late for nacking the patch, as there are several other patches were already applied on the top of it, and we don't rebase the linux-media.git tree. Assuming that this is due to some bug that Eddi picked during xc5000 init, what it can be done now is to write a patch that would replace this xc5000-global mutex lock into a some other per-device locking schema. At this point we have zero idea why it's there *at all*. Eddi, can you comment on what prompted this change? This patch should not have been accepted in the first place. It's an undocumented change on a different driver than is advertised in the subject line. Did you review the patch prior to merging? This change can result in a performance regression for all other devices using xc5000, and it's not yet clear why it's there in the first place. If its use cannot be explained then it should be rolled back. If this breaks 930c, then the whole device support series should be rolled back until somebody can figure out what is going on. It's crap like this that is the reason that every other week I get complaints from some user that one of the drivers I wrote support for worked fine for months/years until they upgraded to the latest kernel. Speaking of which, Mark Lord just tried out this change (he has an 800i and 950q - both xc5000 based), and now his DVB stack fails to load. And yes, he already has the fix to the mutex_unlock() regression which Dan Carpenter found six days ago and which this patch 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: [PATCH 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
On Mon, Dec 5, 2011 at 6:32 PM, Eddi De Pieri e...@depieri.net wrote: Sorry, I think I applied follow patch on my tree while I developed the driver trying to fix tuner initialization. http://patchwork.linuxtv.org/patch/6617/ I forgot to remove from my tree after I see that don't solve anything. Ok, great. At least that explains why it's there (since I couldn't figure out how on Earth the patch made sense otherwise). Eddi, could you please submit a patch removing the offending code? 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: [RFC] vtunerc: virtual DVB device - is it ok to NACK driver because of worrying about possible misusage?
On Sat, Dec 3, 2011 at 12:42 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Sat, 3 Dec 2011 09:21:23 -0800 VDR User user@gmail.com wrote: On Sat, Dec 3, 2011 at 8:13 AM, Andreas Oberritter o...@linuxtv.org wrote: You could certainly build a library to reach a different goal. The goal of vtuner is to access remote tuners with any existing program implementing the DVB API. So you could finally use VDR as a server/client setup using vtuner, right? With full OSD, timer, etc? Yes, I'm aware that streamdev exists. It was horrible when I tried it last (a long time ago) and I understand it's gotten better. But it's not a suitable replacement for a real server/client setup. It sounds like using vtuner, this would finally be possible and since Klaus has no intention of ever modernizing VDR into server/client (that I'm aware of), it's also the only suitable option as well. I would expect it to still suck. One of the problems you have with trying to pretend things are not networked is that you fake asynchronous events synchronously, you can't properly cover error cases and as a result you get things like ioctls that hang for two minutes or fail in bogus and bizarre ways. If you loop via userspace you've also got to deal with deadlocks and all sorts of horrible cornercases like the user space daemon dying. There is a reason properly working client/server code looks different - it's not a trivial transformation and faking it kernel side won't be any better than faking it in user space - it may well even be a worse fake. Alan This whole notion of creating fake kernel devices to represent networked tuners feels like a hack. If applications want to access networked tuners, adding support for RTP/RTSP or incorporating libhdhomerun (LGPL) is a fairly straightforward exercise. In fact, many applications already have incorporated support for one of these two approaches. The fact that app maintainers have been unwilling/uninterested to do such doesn't feel like it should be an excuse for hacking this functionality into the kernel. 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: Hauppauge HVR-930C problems
On Fri, Dec 2, 2011 at 2:41 PM, Fredrik Lingvall fredrik.lingv...@gmail.com wrote: The HVR 930C device has three connectors/inputs: an antenna input, an S-video, and a composite video, respectively, The provider I have here in Norway (Get) has both analog tv and digital (DVB-C) so can I get analog tv using the antenna input or is analog only on the S-video/composite inputs? And, how do I select which analog input that is used? The analog support for that device isn't currently supported (due to a lack of a Linux driver for the analog demodulator). The digital should work fine though (and if not, bring it to Mauro's attention since he has been actively working 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: LinuxTV ported to Windows
2011/11/30 Abylay Ospan aos...@netup.ru: Hello, We have ported linuxtv's cx23885+CAM en50221+Diseq to Windows OS (Vista, XP, win7 tested). Results available under GPL and can be checkout from git repository: https://github.com/netup/netup-dvb-s2-ci-dual Binary builds (ready to install) available in build directory. Currently NetUP Dual DVB-S2 CI card supported ( http://www.netup.tv/en-EN/dual_dvb-s2-ci_card.php ). Driver based on Microsoft BDA standard, but some features (DiSEqC, CI) supported by custom API, for more details see netup_bda_api.h file. Any comments, suggestions are welcome. -- Abylai Ospanaos...@netup.ru NetUP Inc. Am I the only one who thinks this is a legally ambigious grey area? Seems like this could be a violation of the GPL as the driver code in question links against a proprietary kernel. I don't want to start a flame war, but I don't see how this is legal. And you could definitely question whether it goes against the intentions of the original authors to see their GPL driver code being used in non-free operating systems. 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: LinuxTV ported to Windows
On Wed, Nov 30, 2011 at 1:02 PM, Andreas Oberritter o...@linuxtv.org wrote: Am I the only one who thinks this is a legally ambigious grey area? Seems like this could be a violation of the GPL as the driver code in question links against a proprietary kernel. Devin, please! Are you implying that the windows kernel becomes a derived work of the driver, or that it's generally impossible to publish windows drivers under the terms of the GPL? The simple answer is that I don't know. I'm not a lawyer (and as far as I know, neither are you). Nor have I researched the topic to significant lengths. That said though, whether it was the intention of either copyright holder it's entirely possible that the two software licenses are simply incompatible. For example, while both the Apache group and the FSF never really intended to prevent each others' software from being linked against each other, the net effect is still that you cannot redistribute such software together since the Apache license is incompatible with the GPL. I don't want to start a flame war, but I don't see how this is legal. And you could definitely question whether it goes against the intentions of the original authors to see their GPL driver code being used in non-free operating systems. The GPL doesn't cover such intentions. This isn't necessarily true. Anybody who has written a library and released it under the GPL instead of the LGPL has made a conscious decision that the library is only to be used by software that is GPL compatible. By their actions they have inherently forbidden it's use by non-free software. You could certainly make the same argument about a driver -- that they authors intent was to ensure that it only be linked against other free software. All this said, I don't really have a position one way or the other (I'm not a copyright holder on the drivers in question). But this issue doesn't seem as obvious as you would make it sound. 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: LinuxTV ported to Windows
On Wed, Nov 30, 2011 at 2:58 PM, Andreas Oberritter o...@linuxtv.org wrote: The point I'm trying to make: Someone made a presumably nice open source port to a new platform and the first thing you're doing is to play the GPL-has-been-violated-card, even though you're admitting that you don't know whether any right is being violated or not. Please don't do that. It's not very encouraging to someone who just announced free software. To be clear, at no point did I say the GPL has been violated. I am *asking* if others think this represents a GPL violation since at first glance it appears that this software very well might. I don't really have a problem with GPL drivers running on Windows. But if I were the original author of one of the drivers Abylay has ported, I might think differently. 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: Hauppauge HVR-900 HD
On Fri, Nov 25, 2011 at 3:54 PM, Fredrik Lingvall fredrik.lingv...@gmail.com wrote: Hi All, I have a Hauppauge HVR-900 HD with ID 2040:b138. Is this device supported, and if so, which driver and firmware do I need? Hi Frank, It's not currently supported under Linux as it uses a demodulator that there is currently no driver for. As far as I know, nobody's working on it. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scan returns channels with no VID
On Thu, Nov 17, 2011 at 4:55 PM, Brian J. Murrell br...@interlinx.bc.ca wrote: Hi. Using dvb-apps 1.1.1+rev1355-1ubuntu1 on Ubuntu, I'm scanning my qam channels with scan on both an Hauppage HVR-950q and HVR-1600 and the resulting output contains channels which I know are both audio and video yet the VID field of the output is 0. i.e. 120:58500:QAM_256:0:5842:11 121:58500:QAM_256:0:5846:77 122:58500:QAM_256:0:5848:936 123:58500:QAM_256:0:5850:958 These are all viewable channels. Any ideas why the VID is empty? At the same time, other channels have a VID but are not actually viewable/tunable: 108:55500:QAM_256:3691:3692:726 109:55500:QAM_256:3695:3696:728 110:55500:QAM_256:3693:3694:727 Any ideas? I'm not sure about the ones that don't have a VID, but the ones that have a VID which aren't viewable are probably because they're encrypted. The /usr/bin/scan tool will return channels in the list regardless of whether they can actually be viewed without a Cablecard. 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: HVR-4000 may be broken in kernel mods (again) ?
On Sat, Nov 12, 2011 at 5:33 AM, jonathanjstev...@gmail.com jonathanjstev...@gmail.com wrote: Description of problem: Support for Hauupauge HVR-4000 appears to be broken (again) in kernel mods. This is a bit of a tale of woe, but this hardware is supposed to have been sorted in stock kernel roundabout 3.0. Stock F16 kernel cannot scan or tune in mythtv, kaffeine, w_scan, or dvbscan. Compiled/Installed latest video-media build still no joy. I used another USB DVB (nova-t) to scan, and using the results obtained from w_scan on this managed to get tzap to FE LOCK. However this only worked with tzap - no other app can get a lock. Have tested with i2c reset patch enabled and not, and also with strobing patch enabled and not (cs88-dvb.c). Also with mythtv kludge (delaying on FE close in dvbutils.cpp). All make no difference. So sad :( Version-Release number of selected component (if applicable): Linux mythtvtuner.home 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1 21:10:48 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Install F16 and try to make use of HVR-4000. Steps to Reproduce: 1. Install F16 on a machine with HVR-4000 2. Try to use it 3. Cry Actual results: Can't scan or tune. Expected results: Can scan and tune and be happy. Additional info: Should mention this machine is also running Xen. If necessary I have a spare machine I can put a HVR-4000 into and can compile whatever you want to try to fix this. Pretty sure this is a problem upstream in video-media, but will report here to try and get some help! Willing to put in the hours this side to get to the bottom of this, sorry I don't have the programming skills to attack it myself. All the problems historically that the HVR-4000 has had in v4l were supposed to be fixed in 3.0... Let me know what additional info you might want? Jonathan Hi Jonathan, It was actually broken for months (including 3.0), and not fixed until 3.1. I'm assuming you're having problems with dvb-s and dvb-t? Please clarify exactly which standards aren't working for you? Also, take Xen out of the picture. Validate it isn't working in a regular system. Virtualization is definitely a source of problems and should be ruled out. Any suspicious output in dmesg? 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: HVR-4000 may be broken in kernel mods (again) ?
On Sat, Nov 12, 2011 at 8:14 AM, Lars Schotte gu...@guttok.net wrote: i am alos curious what he means by try to use it. i mean did he try to use it with tzap, or szap, or w_scan, or what? because i dont even know about mythtv, i only use dvbutils, mplayer, xine and vdr. I agree with Lars on this. It would be useful if the user could describe in more detail his testing methodology. Also, is there some previous kernel in which he knew it was working properly? Has he *ever* seen it work in his environment? Do we know definitively that this really a regression or has the user never seen the board work? Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HVR-4000 may be broken in kernel mods (again) ?
If you're running Xen, then as far as I'm concerned you're on a *totally* unsupported path. If it happened to have worked in some previous version, it was dumb luck. As for you issue when not using Xen, you're probably just missing the Kaffeine libraries required for video playback (a common problem). Did you try the Nova-T on that box to confirm playback works 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: [PATCH 00/25] Add PCTV-80e Support to v4l
On Thu, Nov 10, 2011 at 6:31 PM, Patrick Dickey pdickeyb...@gmail.com wrote: These are the files required to support the Pinnacle PCTV-80e USB Tuner in video-4-linux. The files were originally downloaded from http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-80e and modified to fix compilation errors and also to move the driver files from the drx39xy subdirectory to the frontends directory. snip Hi Patrick, It's great to see someone taking the time to work to get this upstream. A few comments though: None of these patches appear to have an Signed-off-by line. Since I'm the one vouching for the Micronas code being legitimately allowed to be submitted (in conformance with the Developer's Certificate of Origin), I am the one who needs to be the top signed-off-by (in fact, by arbitrarily breaking my tree into 25 patches, you effectively stripped off my authorship). Further, while it's commendable that you broke this into 25 patches, I think it's perfectly fine that it essentially be the two patches as found in my hg tree (plus the very minor change needed to get the code to compile against 3.x). In fact, I suspect you could probably take my two patches, apply them to the current 3.x tree, fix the two or three conflicts, and have something that is submittable to staging. It's not clear to me why you moved the driver files from frontends/drx39xxj to just frontends. I don't think anybody has ever complained about having a subdirectory if there is a large enough set of files. Did somebody ask you to do that and I didn't see the email? As you indicated, the code hasn't gone through any form of codingstyle cleanup, and as a result needs to go against the staging tree instead of the main tree. You should consult with Mauro on how to approach this problem, because currently you cannot do a demodulator driver against staging because of the dependency on the em28xx bridge which is already in stable (adding Mauro to the cc: to get his opinion). In short, it almost feels like you did *too much* work given you didn't make any material changes to the code itself as it's in my tree. I would suggest just submitting my two patches, and then on top of that you can submit a whole series of patches doing cleanups. And you should definitely review the following page on submitting patches if you haven't already: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches 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 00/25] Add PCTV-80e Support to v4l
On Thu, Nov 10, 2011 at 9:36 PM, Patrick Dickey pdickeyb...@gmail.com wrote: Also, I started to clean up the files tonight. Then I started thinking about what you told me about the as102 drivers, and thought I should submit them as is and then start the cleanup and submit those patches separately. Also that way others could help with some of the cleanup. I have to figure out if there's an easy way to convert all of the DOS Line Endings to the appropriate style, or if I'll have to do that manually (and whether my editor(s) caused this). Definitely you want the cleanup fixes to be in separate patches from the original patch with the driver. This is necessary because it makes it *much* easier to figure out if something got broken as a result of a cleanup patch (which isn't supposed to make any functional change). One reason I did the extra work is because your tree had other files (the cx18 drivers for example) that didn't seem to be needed by the tuner. So, I cleaned them out (partially because I have two cards that use those drivers and didn't want to break those). I can review all of the files to make sure that I didn't miss any. And I can update all of the files from your tree to the most current versions and submit everything again. This shouldn't be the case (the two patches will have no interaction with any driver other than em28xx). I would suggest that instead of treating it as a tree, just suck the two patches off the top and apply them to your current tree one at a time, and fix any conflicts that pop up. http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/raw-rev/c119f08c4dd2 http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/raw-rev/30c6512030ac If you just apply the patches instead of trying to hand-merge the two trees together, you will only get the delta and will likely just have to fix the 4 or five conflicts in em28xx.h and em28xx-cards.c (related to the fact that subsequent boards were added to the driver after my patch). That approach should only take a few minutes, given the conflicts are trivial to resolve. Good luck! 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 00/13] Remaining coding style clean up of AS102 driver
On Mon, Nov 7, 2011 at 2:57 PM, Sylwester Nawrocki snj...@gmail.com wrote: My knowledge about this driver is rather limited, in case of any issues I guess it's best to ask Devin directly. Part of the problem here is that the as102 chip is a fully programmable part, and as a result the firmware may differ on a product-by-product basis. In fact, the engineer at Abilis told me outright that the firmware provided for the PCTV device isn't appropriate for the Elgato board, but it worked good enough for the user. In other words, users are free to try the firmware prepared for PCTV against other devices, but be prepared for it to not be optimized properly for that hardware design (meaning tuning quality issues or perhaps not working at all), and if it destroys your board then don't come crying to me. The only way to know if the same firmware is being used would be to do a USB capture, write a decoder which allows you to extract the firmware being uploaded, and compare it against the PCTV blob. And if it doesn't match, there's no real way of knowing whether the delta is significant. Also worth noting that the only firmware we have the legal right to freely redistribute is the one needed by the PCTV device. Even if somebody extracts another firmware blob from a USB trace, there are no legal rights to redistribute it (meaning a firmware extract script written to work against the Windows driver binary would be required). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WIN-TV DUET HD
On Wed, Nov 2, 2011 at 9:13 AM, Josu Lazkano josu.lazk...@gmail.com wrote: Hello list, I am having lots of problem with DVB-T USB adapters. I want to try this one: http://www.hauppauge.co.uk/site/products/data_duet.html Has anyone use this device? I'm 95% certain this is a brand new hardware design and is currently unsupported under Linux. 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: Hauppauge WIN-TV DUET HD
On Wed, Nov 2, 2011 at 10:11 AM, Michael Krufky mkru...@linuxtv.org wrote: INCORRECT. The WinTV Duet is just a rebranding of the NOVA-TD ... It is, in fact, supported, and quite possibly Hauppauge's coolest DVB-T stick. My mistake. I must have gotten it confused with something else. Despite assertions that it's Hauppauge's coolest stick, the user is claiming that it isn't working. Did they use new USB VID/PIDs that will require a driver change to add support for 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: Hauppauge WIN-TV DUET HD
On Wed, Nov 2, 2011 at 10:45 AM, Josu Lazkano josu.lazk...@gmail.com wrote: Thanks both! Devin, could you add some info on the linuxtv wiki (firmware, installation...)? The wiki is available for edits by anyone, so feel free to update it. That said, it seems that I don't have all the relevant info, so hopefully Michael can provide some insight as to the VID/PID situation for that board (and whether a driver change is required). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WIN-TV DUET HD
On Wed, Nov 2, 2011 at 10:53 AM, Josu Lazkano josu.lazk...@gmail.com wrote: Hello, I have no trouble, I have not buy it yet. I have some DVB-T (most of them with af9015), and I am having lots of I2C problems. I just want to know that it is working as dual tuner. Again, my mistake. I misread Hello list, I am having lots of problem with DVB-T USB adapters as indicating he was having an issue with the device in question. I should really get my coffee before reading email. :-) 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: UVC with continuous video buffers.
On Wed, Nov 2, 2011 at 11:49 AM, javier Martin javier.mar...@vista-silicon.com wrote: Hi, we have a system with a UVC camera connected to USB to acquire video images and a hardware processor which needs continuous memory buffers to process them. I've been looking at the current version of UVC drivers and it seems it allocates buffers using vmalloc_32() call: http://lxr.linux.no/#linux+v3.1/drivers/media/video/uvc/uvc_queue.c#L135 I am interested to extend the driver to support contiguous memory buffers and send it to mainline. What is the right way to achieve this? Can anyone please point me to a video driver example where continuous memory allocation is used? I've actually got a very similar issue and have been looking into it (an em28xx device on OMAP requiring contiguous physical memory for the hardware H.264 encoder). One thing you may definitely want to check out is the patch sent earlier today with subject: [PATCH] media: vb2: vmalloc-based allocator user pointer handling While that patch is intended for videobuf2, you might be able to copy the core logic into videobuf-vmalloc. There are other drivers which use USERPTR provided buffers (which are allocated as contiguous memory from userland [i.e. vfpe_capture accepting buffers from cmemk on the OMAP platform]), but they typically do DMA so it's not really useful as an example where you have a USB based device. If you get it working, by all means send the code to the ML so others can benefit. 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: femon signal strength
On Wed, Oct 26, 2011 at 12:36 AM, James bjloc...@lockie.ca wrote: My signal strength is always above 0 but when I use -H, it is 0%. Does that mean my signal strength is 0%? Maybe femon should report 0.x%. $ femon FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC) status SCVYL | signal 00b9 | snr 00b9 | ber | unc | FE_HAS_LOCK $ femon -H FE: Samsung S5H1409 QAM/8VSB Frontend (ATSC) status SCVYL | signal 0% | snr 0% | ber 0 | unc 0 | FE_HAS_LOCK Is it normal to have 0% signal strength and still get reception? For this demodulator, this is normal. The issue is there is no set standard for the way in which signal level and SNR are reported in the linux DVB API, and as a result there are numerous different formats. The format the s5h1409 demodulator driver delivers it doesn't match the demodulator that the person who wrote femon had available to him/her (the s5h1409 delivers both fields in 0.1dB increments, while whatever demod the femon author had to test with expected signal to be 0-65535 and SNR to be in 1/256 increments). In other words if you have an SNR of 30.0 dB, femon sees 0x012c, which it treats as a percentage of 0x which is 0.00457%, which gets rendered as 0%. Unfortunately, the driver community has never been able to form a consensus on how the data should be reported, so you cannot really argue the s5h1409 driver is doing it wrong (numerous other drivers report in the same manner as the s5h1409). You can read the mailing list archive for the gory history. It really is a fine example of the failure associated with design by committee. 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] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 11:24 AM, Taylor Ralph taylor.ra...@gmail.com wrote: I've attached a patch that correctly sets the max/min/default values for the hdpvr picture controls. The reason the current values didn't cause a problem until now is because any firmware = 0.15 didn't support them. The latest firmware releases properly support picture controls and the values in the patch are derived from the windows driver using SniffUSB2.0. Thanks to Devin Heitmueller for helping me. Regards. -- Taylor Hi Taylor, What worries me here is the assertion that the controls didn't work at all in previous firmware and driver versions. Did you downgrade the firmware and see that the controls had no effect when using v4l2-ctl? Janne, any comment on whether the controls *ever* worked? 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] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 12:23 PM, Janne Grunau ja...@jannau.net wrote: On Thu, Oct 20, 2011 at 11:30:11AM -0400, Devin Heitmueller wrote: On Thu, Oct 20, 2011 at 11:24 AM, Taylor Ralph taylor.ra...@gmail.com wrote: I've attached a patch that correctly sets the max/min/default values for the hdpvr picture controls. The reason the current values didn't cause a problem until now is because any firmware = 0.15 didn't support them. The latest firmware releases properly support picture controls and the values in the patch are derived from the windows driver using SniffUSB2.0. Thanks to Devin Heitmueller for helping me. What worries me here is the assertion that the controls didn't work at all in previous firmware and driver versions. Did you downgrade the firmware and see that the controls had no effect when using v4l2-ctl? Janne, any comment on whether the controls *ever* worked? I've looked at them only at very beginning and if I recall correctly they had no visible effects. The values in the linux driver were taken from sniffing the windows driver. I remember that I've verified the default brightness value since 0x86 looked odd. I'm not sure that I verified all controls. I might have assumed all controls shared the same value range. There were previous reports of the picture controls not working at all. Hi Janne, Thanks for taking the time to chime in. If the controls really were broken all along under Linux, then that's good to know. That said, I'm not confident the changes Taylor proposed should really be run against older firmwares. There probably needs to be a check to have the values in question only applied if firmware = 16. If the controls were broken entirely, then we should probably not advertise them in ENUM_CTRL and S_CTRL should return -EINVAL if running the old firmware (perhaps put a warning in the dmesg output saying the controls are unavailable because the user is not running firmware = 16). My immediate concern is about ensuring we don't cause breakage in older firmware. For example, we don't know if there are some older firmware revisions that *did* work with the driver. The controls might have worked up to firmware revision 10, then been broken from 11-15, then work again in 16 (with the new hue value needed). The safe approach is to only use these new settings if they're running firmware = 16. 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] [media] hdpvr: update picture controls to support firmware versions 0.15
On Thu, Oct 20, 2011 at 1:08 PM, Janne Grunau j...@jannau.net wrote: I think such scenario is unlikely but I don't know it for sure and I don't want to force anyone to test every firmware version. Ignoring them for firmware version 16 should be safe since we assume they had no effect. Returning -EINVAL might break API-ignoring applications written with the HD PVR in mind but I think it's a better approach than silently ignoring those controls. At this point, let's just make it so that the old behavior is unchanged for old firmwares, meaning from both an API standpoint as well as what the values are. At some point if somebody cares enough to go back and fix the support so that the controls actually work with old firmwares, they can take that up as a separate task. In reality, it is likely that nobody will ever do that, as the easy answer is just to upgrade to firmware 16. Taylor, could you please tweak your patch to that effect and resubmit? 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: Staging questions: WAS Re: [PATCH 0/7] Staging submission: PCTV 74e drivers and some cleanup
Hi Patrick, On Wed, Oct 19, 2011 at 8:36 AM, Patrick Dickey pdickeyb...@gmail.com wrote: I'm posting this question under this thread because the subject pertains to the question (in that I'm asking about staging and about the PCTV 80e drivers). You should definitely be looking at the as102 thread that is currently going on this mailing list. Piotr is actually going through the same process as you are (he is working on upstreaming the as102 driver from a kernellabs.com tree). He made some pretty common mistakes (all perfectly understandable), and your reading the thread might help you avoid them (and having to redo your patch series). I started cleaning up the drx39xx* drivers for the PCTV-80e and have them in a github repository. Ultimately I want to send a pull request, so other people can finish the cleaning (as I'm not comfortable with pulling out the #ifdef statements myself). You should definitely ask Mauro how he expects to do a staging driver for a demodulator before you do any further work. The staging tree works well for bridge drivers, but demod drivers such as the drx require code in the bridge driver (the em28xx in this case), so it's not clear how you would do staging for a product where the bridge driver isn't in staging as well. The answer to that question will likely guide you in how to get the driver into staging. If you have specific questions regarding anything you see in the driver, let me know. I don't have much time nowadays but will find the time if you ask concise questions. Good luck. It will be great to finally see this merged upstream. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/14] staging/media/as102: new driver submission (was Re: [PATCH 1/7] Staging submission: PCTV 74e driver (as102)
On Tue, Oct 18, 2011 at 5:10 AM, Piotr Chmura chmoor...@poczta.onet.pl wrote: Thanks for comments for all of you. [PATCH 1-12/14] Following your guidelines i exported all changes from hg one by one. This way we will have all history in kernel tree. I moved driver to staging/media and removed Kconfig/Makefile changes in parent directory in first patch. Hello Piotr, Not that I want to create more work for you, but it would appear that your patches stripped off all the Signed-off-by lines for both myself and Pierrick Hascoet (the developer from the hardware vendor). You have replaced them with cc: lines, which breaks the chain of Developer's Certificate of Origin. When you take somebody else's patches, you need to preserve any existing Signed-off-by lines, adding your own at the bottom of the list. In other words, the first patch should be: Signed-off-by: Pierrick Hascoet pierrick.hasc...@abilis.com Signed-off-by: Devin Heitmueller dheitmuel...@kernellabs.com Signed-off-by: Piotr Chmura chmoor...@poczta.onet.pl instead of: Signed-off-by: Piotr Chmura chmoor...@poczta.onet.pl Cc: Pierrick Hascoet pierrick.hasc...@abilis.com Cc: Devin Heitmueller dheitmuel...@kernellabs.com 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: PVR-2200 error with what I think is tuning
On Tue, Oct 18, 2011 at 6:00 PM, Greg Bowyer gbow...@fastmail.co.uk wrote: Hi there You probably get this a lot, with the latest and greatest drivers from your git repository at Steve Tosh's website I get the following after a few days [198934.085303] tda18271_write_regs: [4-0060|S] ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [198934.085310] tda18271_init: [4-0060|S] error -5 on line 831 [198934.085317] tda18271_tune: [4-0060|S] error -5 on line 909 [198934.085324] tda18271_set_params: [4-0060|S] error -5 on line 994 [198934.085331] saa7164_cmd_send() No free sequences [198934.085336] saa7164_api_i2c_read() error, ret(1) = 0xc [198934.085341] tda10048_readreg: readreg error (ret == -5) [198934.087195] tda10048_readreg: readreg error (ret == -5) [198934.087209] saa7164_cmd_send() No free sequences [198934.087214] saa7164_api_i2c_read() error, ret(1) = 0xc [198934.087220] tda10048_readreg: readreg error (ret == -5) My tuning software is tvheadend (which I would prefer to keep) I started to look at the sourcecode, but I know too little about I2C to make any sense of what might be bugging out Is there anything I can do to avoid this ? Just an FYI: that doesn't actually look like an i2c problem or some other problem with the tuner or demodulator. It looks like the saa7164 itself is wedged. 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 1/7] Staging submission: PCTV 74e driver (as102)
On Sun, Oct 16, 2011 at 4:57 AM, Stefan Richter stef...@s5r6.in-berlin.de wrote: Hi Piotr, thanks for getting this going again. - I have not yet looked through the source but have some small remarks on the patch format. - In your changelogs and in the diffs, somehow the space between real name and e-mail address got lost. - The repetition of the Subject: line as first line in the changelog is unnecessary (and would cause an undesired duplication e.g. when git-am is used, last time I checked). - AFAICT, author of patch 1/7 is not Devin but you. Hence the From: line right above the changelog is wrong. - The reference to the source hg tree is very helpful. However, since the as102 related history in there is very well laid out, it may be beneficial to quote some of this prior history. I suggest, include the changelog of as102: import initial as102 driver, http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/rev/a78bda1e1a0b (but mark it clearly as a quote from the out-of-tree repo), and include a shortlog from this commit inclusive until the head commit inclusive. (Note, the hg author field appears to be wrong; some of the changes apparently need to be attributed to Pierrick Hascoet as author.) This would IMO improve the picture of who contributed what when this goes into mainline git history, even though the hg history needed to be discarded. - A diffstat is always very nice to have in a patch posting. Most tools for patch generation make it easy to add, and it helps the recipients of the patch posting. (Also, a diffstat of all patches combined would be good to have in the introductory PATCH 0/n posting, but not many developers take the time to do so.) Again, thanks for the effort and also thanks to Devin for making it possible. I think collapsing my entire patch series in to a single patch would not be acceptable, as it loses the entire history of what code was originally delivered by Abilis as well as what changes I made. The fact that it's from multiple authors (including a commercial entity contributing the code) makes this worse. I think the tree does need to be rebased, but I don't think the entire patch series would need to be reworked to be on staging from the beginning. You could probably import the first patch (as102: import initial as102 driver), fix the usb_alloc_coherent() so that it compiles (and put a note in it saying you did), apply the rest of the patch series, and then add a final patch that says something like moving to staging as code is not production ready. This would allow the history to be preserved without having to rebase every patch to deal with the files being moved to the staging tree. An alternative would be make a minor tweak to my first patch which removes the driver from the makefile. Then every patch in the patch series wouldn't actually have to compile successfully until the very end when you add it back into the Makefile. This is a luxury you can do when it's a brand new driver. When it's a brand new driver there is a bit more flexibility as long as you don't break git bisect. Both of the approaches described above accomplish that. Mauro, what do you think? 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/7] staging/as102: cleanup - formatting code
On Sun, Oct 16, 2011 at 8:23 AM, Julian Andres Klode j...@jak-linux.org wrote: On Sat, Oct 15, 2011 at 10:54:43PM +0200, Piotr Chmura wrote: staging as102: cleanup - formatting code Cleanup code: change double spaces into single, put tabs instead of spaces where they should be. Signed-off-by: Piotr Chmurachmoor...@poczta.onet.pl Cc: Devin Heitmuellerdheitmuel...@kernellabs.com Cc: Greg HKgre...@suse.de Just a few hints from my side. Most of my comments apply to multiple other parts of the code, but I did not want to quote everything and you should be able to find the other parts I did not mention explicitely as well. I don't have much knowledge of kernel code style, but wanted to point out a few things that seem to be obviously wrong or uncommon, and stuff I wouldn't do. There may be a few false positives and some things missing. [And yes, I actually only wanted to comment on the two-space thing, but I somehow ended up reading the complete patch or the first half of it]. I think that rather than having Piotr rework the whitespace fifty times until everybody is satisfied, let's get a functional patch series into the staging tree and then people can submit whitespace cleanup patches to their hearts content. That said, Piotr, I would not spend effort reworking the existing patch per Julian's request. Fix the issues related to the history that I mentioned in my previous email (which would be required to get it into staging), and then the people who have nothing better to do than obsess about whitespace can submit incremental patches on top of yours which address their concerns. 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/as102 nBox DVB-T dongle
On Fri, Oct 14, 2011 at 8:36 AM, Piotr Chmura chmoor...@poczta.onet.pl wrote: Hi, There's licencing problem with as10x_cmd_cfg.c and as10x_cmd_stream.c files which are not GPL ( (c) Copyright Abilis Systems SARL 2005-2009 All rigths reserved \n www.abilis.com). Dunno if it's only Davin's Heitmueller oversight in changing licencing or a real problem. What about it Davin ? Yeah, those were an oversight on the part of Abilis. I already talked to them about it and got permission to fix the text. 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 520e on Linux
On Fri, Oct 14, 2011 at 9:19 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: While the basic chips used are different, they are completely different hardware designs and likely have different GPIO configurations as well as IF specs. The IF settings for xc5000 with DRX-K are solved with this patch: http://patchwork.linuxtv.org/patch/7932/ Basically, DRX-K will use whatever IF the tuner uses. While I fundamentally disagree with this change, I'm not going to nack it. That said, this wasn't the issue I was concerned with. My suggestion was simply that you cannot assume that all devices that happen to have a particular demod and tuner combo will always use the same IF configuration. The PCB layout can effect the optimal IF. This is one of those things that (like many tuners in the LinuxTV tree) will probably work good enough to get a signal lock for whoever added the board profile, but will result in poor tuning performance (and a failure to work in less-than-ideal reception conditions). All that said, if somebody actually intends to hack on it, I can look up what the correct IF is for the 520e. 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 520e on Linux
On Fri, Oct 14, 2011 at 10:01 AM, Sönke Brandt sbra...@pctvsystems.com wrote: Just a quick note: The 520e does use the TDA18271 tuner, not an XC5000. Soenke. Wow, how the hell did I screw that up? Of course Sönke is correct. I momentarily got the 520e confused with the HVR-930c (I've done work on both in the past). Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCTV 520e on Linux
On Fri, Oct 14, 2011 at 12:14 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: The tda18271-dd/drx-k/em28xx combination works fine, provided that the GPIO initialization enables both tuner and demod during probe time. Currently, the device I used to add support for it (a Terratec H5) has a hack to enable the devices: it just replies whatever initialization the original driver does. When I have some time, I'll fix that, but I'm not urging doing so, because it just works ;) In order to add support for PCTV 520e, it is probably a matter of just set the GPIO's. Complements of our friends at PCTV: 520e: GPIO02: Decoder Reset, active-low GPIO04: Decoder Suspend, active-low GPIO06: Demod Reset, active-low GPIO07: LED on, active-high 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 520e on Linux
On Fri, Oct 14, 2011 at 1:39 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: What are the USB ID's for the device? I may try to do a patch for it during this weekend, if I found time to add support for a few other devices that Terratec gently donated me. 510e 2304:0242 520e 2013:0251, 2013:0252 Of course, you shouldn't just blindly check anything in. That said, seems there are people on this list who have at least some of these variants. 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: recent cx23385?
On Thu, Oct 13, 2011 at 1:59 AM, James bjloc...@lockie.ca wrote: Is there a newer cx23385 driver than the one in kernel-3.0.4? I bought a http://linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1250 and it shows video for about 5 seconds and then locks up the system. You cannot install individual drivers (Linux doesn't work like Windows in this regards). You have to either install the latest kernel or you can swap out the whole media subsystem with a later version. http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers 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 520e on Linux
On Thu, Oct 13, 2011 at 10:49 AM, Claus Olesen ceole...@gmail.com wrote: I'm looking for a USB stick for DVB-C on Linux, have good experience with the PCTV nanoStick T2 290e for DVB-T on Linux (except for the replug issue) I believe the replug issue is probably fixed if you're using the current media_build tree. http://www.pctvsystems.com/Products/ProductsEuropeAsia/Digitalproducts/PCTVnanoStickT2/tabid/248/language/en-GB/Default.aspx and wonder if anyone know the status of support, if any, of the PCTV QuatroStick nano 520e for DVB-C on Linux? http://www.pctvsystems.com/Products/ProductsEuropeAsia/Hybridproducts/PCTVQuatroSticknano/tabid/254/language/en-GB/Default.aspx No support currently. I have the stick, but haven't had any time to work 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: PCTV 520e on Linux
On Thu, Oct 13, 2011 at 12:07 PM, Antti Palosaari cr...@iki.fi wrote: No support currently. I have the stick, but haven't had any time to work on it. Is that EM28xx + DRX-K + TDA18217 ? And analog parts... You were close: em2884, drx-k, xc5000, and for analog it uses the afv4910b. 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 520e on Linux
On Thu, Oct 13, 2011 at 12:19 PM, Antti Palosaari cr...@iki.fi wrote: You were close: em2884, drx-k, xc5000, and for analog it uses the afv4910b. Then it should be peace of cake at least for digital side. I don't think we've ever done xc5000 on an em28xx before, so it's entirely possible that the xc5000 clock stretching will expose bugs in the em28xx i2c implementation (it uncovered bugs in essentially every other bridge driver I did work on). That, and we don't know how much is hard-coded into the drx-k driver making it specific to the couple of device it's currently being used with. But yeah, it shouldn't be rocket science. I added support for the board in my OSX driver and it only took me a couple of hours. 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: recent cx23385?
On Thu, Oct 13, 2011 at 12:31 PM, James bjloc...@lockie.ca wrote: Where do I see the date/version of the media subsystem? You can't. The media_build stuff is just a script which backports part of the latest kernel tree and applies some patches to make it work with older kernels. There is no real version for it. It is not video related, w_scan works sometimes but freezes the kernel sometimes. This is booting right to a console. Is there a program to do a stress test on the hardware and print lots of messages as it's working? Not really, you can add the debug=1 modprobe option, but in reality you probably need to get to the bottom of what is causing the hardware lockup. I did: http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers /bin/sh: /sbin/lsmod: No such file or directory Lot's of pr_fmt redefined errors. lsmod is required. Go install whatever package provides it. I put the build log at: lockie.ca/test/v4l_build.txt.bz2 Something is not right though. :-( $ modprobe cx23885 WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. WARNING: Error inserting altera_ci (/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/altera-ci.ko): Invalid module format WARNING: Error inserting media (/lib/modules/3.0.4/kernel/drivers/media/media.ko): Invalid module format WARNING: Error inserting videodev (/lib/modules/3.0.4/kernel/drivers/media/video/videodev.ko): Invalid module format WARNING: Error inserting v4l2_common (/lib/modules/3.0.4/kernel/drivers/media/video/v4l2-common.ko): Invalid module format WARNING: Error inserting videobuf_core (/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-core.ko): Invalid module format WARNING: Error inserting videobuf_dvb (/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dvb.ko): Invalid module format WARNING: Error inserting videobuf_dma_sg (/lib/modules/3.0.4/kernel/drivers/media/video/videobuf-dma-sg.ko): Invalid module format WARNING: Error inserting cx2341x (/lib/modules/3.0.4/kernel/drivers/media/video/cx2341x.ko): Invalid module format WARNING: Error inserting altera_stapl (/lib/modules/3.0.4/kernel/drivers/linux/drivers/misc/altera-stapl/altera-stapl.ko): Invalid module format WARNING: Error inserting rc_core (/lib/modules/3.0.4/kernel/drivers/media/rc/rc-core.ko): Invalid module format FATAL: Error inserting cx23885 (/lib/modules/3.0.4/kernel/drivers/media/video/cx23885/cx23885.ko): Invalid module format Your build is screwed up. Would recommend you do a make clean and then make make install. Then 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: help with azap
On Thu, Oct 13, 2011 at 2:14 PM, James bjloc...@lockie.ca wrote: $ more channels.conf CIII-HD:8500:8VSB:49:52+53:1 OTTAWA CBOFT-DT:18900:8VSB:49:53+52:3 CJOH:21300:8VSB:49:51+52:1 TVO :53300:8VSB:49:52+53:1 OTTAWA CBOT-DT:53900:8VSB:49:52+53:3 Télé-Québec_HD:56900:8VSB:49:52+53:3 CHOT:62900:8VSB:49:52:3 $ azap -c channels.conf CJOH using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' ERROR: error while parsing Audio PID (not a number) $ tzap -c channels.conf CJOH using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file 'channels.conf' ERROR: error while parsing inversion (syntax error) Why does tzap show what file it is reading the channel list from but azap doesn't? If I recall, tzap and azap are actually from different codebases (although I believe one was originally derived from the other). That is why the output is a little inconsistent. That said, you should not be using tzap for ATSC/ClearQAM. tzap is for DVB-T. What does ERROR: error while parsing Audio PID (not a number) mean? I don't know where your channels.conf came from, but it appears to be malformed. You cannot have 52+53 as the audio PID. If you just want to get up and running, remove the +53 part. 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 520e on Linux
On Thu, Oct 13, 2011 at 7:06 PM, Benjamin Larsson benja...@southpole.se wrote: On 10/13/2011 07:48 PM, Devin Heitmueller wrote: On Thu, Oct 13, 2011 at 12:19 PM, Antti Palosaari cr...@iki.fi wrote: You were close: em2884, drx-k, xc5000, and for analog it uses the afv4910b. Then it should be peace of cake at least for digital side. I don't think we've ever done xc5000 on an em28xx before, so it's entirely possible that the xc5000 clock stretching will expose bugs in the em28xx i2c implementation (it uncovered bugs in essentially every other bridge driver I did work on). That, and we don't know how much is hard-coded into the drx-k driver making it specific to the couple of device it's currently being used with. But yeah, it shouldn't be rocket science. I added support for the board in my OSX driver and it only took me a couple of hours. Devin Eddi De Pieri has patches for the HVR-930C that works somewhat. The hardware in that stick is the same. MvH Benjamin Larsson While the basic chips used are different, they are completely different hardware designs and likely have different GPIO configurations as well as IF specs. 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: where is the cx23887 module in kernel-3.04 config?
On Wed, Oct 12, 2011 at 4:42 PM, James bjloc...@lockie.ca wrote: On 10/12/11 16:30, James wrote: Where is the cx23887 module in the kernel-3.04 config? I'm trying to get a Hauppauge WinTV-HVR-1250 working. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Found it under video4lnux driver and not DVB/ATSC adapters (which seems more logical). In general, everything that is a hybrid card is under media/video. That's just a product of the way the two trees evolved (v4l vs. dvb)... Steven actually has a tree which I believe has support for pretty much every 1250 variant. It's not merged upstream though, so you will likely have to do some tweaking of the code to make it work with current kernels. http://kernellabs.com/hg/~stoth/cx23888-encoder/ 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: digital tuner
On Thu, May 12, 2011 at 3:49 PM, James bjloc...@lockie.ca wrote: I have an analog: Hauppauge WinTV-Go PLUS which has a lineout. I'm considering a digital card. The Hauppauge WinTV-HVR-1250 does NOT have a lineout so how does it do sound? Does PCIe pass through the sound to the OS sound system? I read on the linuxtv wiki that only the digital works on this card. You've probably already figured this out by now, but the cx23885 does have an ALSA driver, which isn't yet upstream. Igor actually just rebased Steven's tree with the support against the latest kernel, so hopefully it will make it upstream soon (see the linux-media mailing list for the last couple of days to find the thread). 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: tvtime at linuxtv.org
On Thu, Oct 6, 2011 at 9:59 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Devin, I had some discussions with Mikael today at the #linuxtv channel about tvtime. Mikael has write access to the tvtime site at sourceforge and he is doing some maintainance on it for some time, and worked on some bugs from Gentoo, and also imported some stuff from Ubuntu. I've merged his patches on my repository: http://git.linuxtv.org/mchehab/tvtime.git Tvtime is compiling, at least on Fedora 15. I also added your patch there, and changed the latency delay to 50ms. I didn't test it yet. I'll do it later today or tomorrow. Btw, Mikael updated the Related Sites there to point to the LinuxTV site: http://tvtime.sourceforge.net/links.html He will try to contact Vektor again, in order to get his ack about adding a note at the main page pointing to us. I think we should move those patches to the main repository after testing the merges, and give write rights to the ones that are interested on maintaining tvtime. I'm interested on it, and also Mikael. IMHO, after testing it and applying a few other patches that Mikael might have, it is time for us to rename the version to 1.10 and do a tvtime release. Would that work for you? Thank you! Mauro Hi Mauro, It's good to hear that patches are continuing to be merged, and of course contributors are always welcome. The more I think about this, the more I recognize that I'm not really adding any value to this process. While I would really like to put more time/energy into tvtime, I just don't have the time and it appears I'm actually slowing down a community of contributors who are trying to move things forward. At this point I would recommend the LinuxTV community just take over the project, give yourself write access to the main repo, and spin a release. I would indeed recommend calling it 1.10, to prevent confusion with the various vendor branches where I believe some of which may actually already be calling themselves 1.03. Regarding expanding the list of individuals with commit rights, I might suggest keeping the list of write privileges for the main repo to a minimum in the short term (starting with yourself), until developers have demonstrated their ability to author coherent patches which won't cause breakage as well as the ability to review the work of others. 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: fm player for v4l2
On Wed, Oct 5, 2011 at 2:32 PM, Will Milspec will.mils...@gmail.com wrote: hi all, After recent-ish kernel updates, fmtools no longer works. (I'm running gentoo currently on kernel 3.0.6) I believe the changes pertain to V4L1 vs L2 api changes. I am not a linux developer, however, and can't speak w/ authority. I've appended my v4l-info at the end of this email Example Failing Command == $fm 91.5 ioctl VIDIOCGAUDIO: Invalid argument Kernel V4L options == Here's my kernel configuration: CONFIG_VIDEO_V4L2_COMMON=y CONFIG_VIDEO_V4L2=y CONFIG_V4L_USB_DRIVERS=y # CONFIG_V4L_MEM2MEM_DRIVERS is not set Can anyone recommend: - any fm software that works w/ V4L2? - any kernel tweaks I can make to keep the old fmtools app working? - any other next steps Unfortunately, despite V4L1 having been deprecated almost a decade ago, essentially every application out there was still depending on it at the source code level. Once the kernel finally dropped the support entirely, changes were required to MythTV, tvtime, xawtv, for them to start working again (pretty much every project I know of went oh crap when it disappeared). Somebody will probably have to fix the fmtools source code to no longer depend on V4L1. 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 tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included
On Fri, Sep 30, 2011 at 7:59 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Michael/Devin may be able to double check what tda18271 variants are used at the hvr1100 supported models. Mike could confirm definitively but I would be very surprised if it was anything other than a C2. I also don't think we've had multiple revisions of that board (other than the ones in the list which were all released at the same time and are just different population options). All that said, I also wonder if perhaps this is an issue with the analog demod as opposed to the tuner. It feels unlikely but that might explain why I didn't see similar results when I did the testing on the cx231xx/tda18271 combo back in February. The big problem here really though is that somebody who is knowledgeable of the driver internals needs to dig into the issue, and I don't foresee that happening in the immediate future (I cannot speak for Michael but I've been too tied up in other projects). I'm definitely not discounting Simon's skills or findings, but this needs to be investigated in a context beyond the tuner/demod combination found on a single product. 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 tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included
Hi Simon,
On Wed, Sep 28, 2011 at 8:50 AM, Simon Farnsworth
simon.farnswo...@onelan.com wrote:
(note - the CC list is everyone over 50% certainty from get_maintainer.pl)
I'm having problems getting a Hauppauge HVR-1110 card to successfully
tune PAL-D at 85.250 MHz vision frequency; by experimentation, I've
determined that the tda18271 is tuning to a frequency 1.25 MHz lower
than the vision frequency I've requested, so the following workaround
fixes it for me.
diff --git a/drivers/media/common/tuners/tda18271-fe.c
b/drivers/media/common/tuners/tda18271-fe.c
index 63cc400..1a94e1a 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -1031,6 +1031,7 @@ static int tda18271_set_analog_params(struct
dvb_frontend *fe,
mode = I;
} else if (params-std V4L2_STD_DK) {
map = std_map-atv_dk;
+ freq += 125;
mode = DK;
} else if (params-std V4L2_STD_SECAM_L) {
map = std_map-atv_l;
I've checked with a signal analyser, and confirmed that my signal
generator is getting the spectrum right - I am seeing vision peaking
at 85.25 MHz, with one sideband going down to 84.5 MHz, and the other
going up to 90.5MHz. I also see an audio carrier at 91.75 MHz.
I'm going to run with this hack in place, but I'd appreciate it if
someone who knew more about the TDA18271 looked at this, and either
gave me a proper fix for testing, or confirmed that what I'm doing is
right.
Hi Simon,
This is interesting. I did some testing with an 18271 based device a
few months back (a Hauppauge cx231xx based tuner), and I believe
PAL-DK was working (although I did have unrelated issues with the DIF
configuration).
When you are doing the tuning request, are you explicitly stating
PAL-D in your calling application? Or are you passing PAL to the
V4L layer and expecting it to work with a PAL-D feed?
I'm not doubting your findings, and clearly you've done a good bit of
research/analysis, but I did want to raise it as a data point to
consider
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: support for Elgato eyetv one
2011/9/28 Tim Bolder timbol...@gmail.com: Hi, I was wondering if the Elago eyetv one is on the list for (near) future support. I've tried to make te device work with the settings of other eyetv devices but wit no luck. I have attached a lsusb log for mor info on the device. To my knowledge nobody is working on it. In general the Mac products tend to be much more expensive than their Windows equivalents, and thus very few developers own units to test/debug with. For example, I added support for one of the original EyeTV products which I added the driver support for, but it was a fluke that it fell in my lap. I wouldn't have gone out and spent $129.00 to buy one just to add Linux support for 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: Problems cloning the git repostories
On Sun, Sep 25, 2011 at 11:25 PM, Mauro Carvalho Chehab mauroche...@gmail.com wrote: I fail to see any trial from your side to send the patches upstream: no pull requests and no patches for this driver were _ever_ sent to the ML. You and I have discussed this issue multiple times with these drivers, including the drx-j (which is the basis for the 80e device in question). All the code is publicly available, and I in fact invited you personally to pull whatever you want (as a policy we don't publish public trees that have outstanding licensing issues). Look how long it took to get xc4000 upstream. Look how long it took drx-d to get upstream. Those trees sat there for *years* with your full knowledge of their existence and that the only reason they weren't merged was because of codingstyle issues. Oh, and I did spend a bunch of hours doing cleanup work on the as102 driver, and it was still not good enough. I decided it wasn't worth the additional time. That tree has only been rotting for 19 months. I can only guess that maybe submitting it upstream were not part of your contract with the vendor. I don't even know what this means. Commercial customers who I've done work for almost never are willing to pay for me to merge code upstream. And yet code does get upstream. Why? Because I do it in my free time as a courtesy to the community. Probably also worth noting that the project in question - the 80e - was not done for any customer. I just did the work because I wanted to see the device supported under Linux. Coding Style fixes are generally trivial, and they can be done very quickly with some scripting. I took only a few hours to convert drx-d and drx-k to the Linux Coding Style, on my spare time. The scripts I wrote for that are together with the commits (they're generally a few lines perl scripting doing some replacements). I usually do this with other drivers, when people submit me them with those troubles and I have some time, and never asked or earned a single penny for doing that. Hey, feel free to grab the drx-j driver then. This is like the fourth time I'm invited you to pull the sources and do such a cleanup. And like I said above, I don't earn any money for such cleanups either. I just believe it's a colossal waste of my time that would be better spent doing real driver development. Also, as I've told you several times before, code with broken coding styles can be submitted as-is, without any changes to drivers/staging, where they're fixed by kernel newbies with more time to work on that. Last I checked you can't put demod or tuners drivers into staging because they are a dependency of the bridge driver. I guess maybe you can accomplish that if you litter the bridge driver source and makefiles with #ifdef lines. If that situation has changed, then great. So, please don't use weak arguments like that as an excuse for you to not submit your drivers. Suggesting that the developers who are trying to give you working code at zero cost is a pretty crappy way to treat them. Want to see more device support upstream? Optimize the process to make it easy for the people who know the hardware and how to write the drivers to get code upstream, and leave it to the janitors to work out the codingstyle issues. The process you've just described exists already since Sept, 2008. It is called: /drivers/staging In summary, if you don't have a couple hours to make your driver to match Kernel Coding Style, just send it as is to /drivers/staging, c/c me and Greg KH, and that's it. PULL http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/ PULL http://kernellabs.com/hg/~dheitmueller/v4l-dvb-as102-2/ Have fun. The harder you make it to get code upstream, the more developers who will just say to hell with this. And *that* is why there are thousands of lines of working drivers which various developers have in out-of-tree drivers. You can sit in denial that there is a fundamental problem with the management of this project and blame the developers for being lazy, or you can take some concrete action to get the code merged upstream. Your call. 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 cloning the git repostories
On Sun, Sep 25, 2011 at 8:33 AM, Patrick Dickey pdickeyb...@gmail.com wrote: Hello there, I tried to follow the steps for cloning both the media_tree.git and media_build.git repositories, and received errors for both. The media_tree repository failed on the first line git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb which I'm assuming is because kernel.org is down. The media_build.git repository fails on the first line also git clone git://linuxtv.org/media_build.git with a fatal: read error: Connection reset by peer. Is it possible to clone either (or both) repositories at this time, or are they down? And in the absence of cloning the kernel for the media_tree.git repository, is it possible to simply clone the git://linuxtv.org/media_tree.git repository and work from that? My interest in this is to install some patches created by Devin Heitmueller for the Pinnacle PCTV 80e USB tuner (at least the ATSC portion of the tuner). Once I'm able to determine exactly what changes are made, I would like to either submit the patches to the repository, or send them to someone who has more experience in patching the files for submission. One other question (totally unrelated to this post though): When I send emails, normally they are GPG signed. Should I disable that for this list, or is it acceptable? Thank you for any information, and have a great day:) Patrick. Hi Patrick, As I said on the blog, the issue isn't getting the driver to work against current kernels. Merging the driver against the current tree is a trivial exercise (the patch series should apply trivially against the current code, with only a few minor conflicts related to board numbers, etc). The bigger issue though is once you do that and have the driver running, you now have a body of code 10,000 lines which doesn't meet the coding standards. Doing such a refactoring is a relatively straightforward exercise but very time consuming (you already have a working driver, so you just have to make sure you don't break anything). The more I think about this, the more it annoys me. I did all the hard parts: * I worked with the product vendor to get the details for the design * I got Hauppauge/PCTV to compel the chipset vendor to release the reference code under a GPL compatible license * I worked out redistribution terms on the firmware * I ported the driver to Linux * I integrated the driver and debugged it to achieve signal lock And why is it not in the mainline? Because none of the above matters if I didn't waste a bunch of my time removing a bunch of #ifdef WINDOWS lines and converting whitespace from tabs to spaces. It's crap like this that's the reason why some of the best LinuxTV driver authors still have a bunch of stuff that isn't merged upstream. We just don't have time for this sort of bullshit that any monkey could do if he/she was willing to invest the effort. We're just too busy doing *actual* driver work. Five years ago the hard part was finding competent developers, getting access to datasheets, getting access to reference driver code, and getting access to the details for a hardware design. Now most of those problems are not the issue - we have access to all the data but we want to waste the time of the few competent developers out there making them do coding style cleanup before perfectly good code gets merged upstream. There has been more than one case where I've considered doing a driver for a new board and decided against it because the barrier to getting it upstream is not worth my time. Want to see more device support upstream? Optimize the process to make it easy for the people who know the hardware and how to write the drivers to get code upstream, and leave it to the janitors to work out the codingstyle 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: cx231xx: DMA problem on ARM
On Thu, Sep 22, 2011 at 10:45 AM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: Hello, Le Wed, 21 Sep 2011 08:04:52 -0400, Devin Heitmueller dheitmuel...@kernellabs.com a écrit : I ran into the same issue on em28xx in the past (which is what those parts of cx231xx are based on). Yes, just adding URB_NO_TRANSFER_DMA_MAP should result in it starting to work. Please try that out, and assuming it works feel free to submit a patch which can be included upstream. So, we did try with URB_NO_TRANSFER_DMA_MAP, and now, we don't have the BUG_ON() assertion anymore, but instead a large set of error messages: [ 325.856231] cx231xx #0: setPowerMode::mode = 48, No Change req. [ 325.858398] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 325.860656] cx231xx #0: setPowerMode::mode = 48, No Change req. [ 326.144073] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 326.151245] cx231xx #0: cx231xx_initialize_stream_xfer: set video registers [ 326.151763] cx231xx #0: cx231xx_start_stream():: ep_mask = 8 [ 396.907318] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 396.912048] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 396.977355] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 396.987091] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71) [ 456.665252] cx231xx #0: setPowerMode::mode = 48, No Change req. [ 456.675292] cx231xx #0: cannot change alt number to 3 (error=-71) [ 456.714508] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.718811] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.719635] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 456.729522] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71) [ 456.750427] cx231xx #0: setPowerMode::mode = 48, No Change req. [ 456.756317] cx231xx #0: cannot change alt number to 3 (error=-71) [ 456.778625] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.782745] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.786987] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.791381] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.795501] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.795532] cx231xx #0: cx231xx_set_decoder_video_input: adjust_ref_count :Failed to setAFE input mux - errCode [-71]! [ 456.841491] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.845642] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.849792] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.854003] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.858123] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.862274] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.866394] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.870513] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.875030] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.879150] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.883239] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.887390] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.891632] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.895751] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.83] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.904174] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.914825] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.919036] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.924499] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.936920] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.941131] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.946655] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.960144] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.968658] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.984344] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 456.999572] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 457.004577] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 457.015014] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 457.019561] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 457.029083] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 457.033264] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 457.039031] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 457.043121] cx231xx #0
Re: cx231xx: DMA problem on ARM
On Wed, Sep 21, 2011 at 7:56 AM, Thomas Petazzoni
thomas.petazz...@free-electrons.com wrote:
Hello,
On an x86 platform, we have managed to use a Hauppauge USB Live 2
capture device with the cx231xx on a 3.0 kernel with the patch at [1].
Things work nicely.
However, using a similar 3.0 kernel with the exact same device on an
ARM platform (BeagleBoard-XM), starting a V4L application to capture
the video immediately triggers the following BUG_ON in
arch/arm/mm/dma-mapping.c:
429 void ___dma_single_cpu_to_dev(const void *kaddr, size_t size,
430 enum dma_data_direction dir)
431 {
432 unsigned long paddr;
433
434 BUG_ON(!virt_addr_valid(kaddr) || !virt_addr_valid(kaddr + size -
1));
This problem looks similar to the problem fixed on the gspca driver by:
commit 882787ff8fdeb0be790547ee9b22b281095e95da
Author: Jason Wang jason77.w...@gmail.com
Date: Fri Sep 3 06:57:19 2010 -0300
V4L/DVB: gspca - main: Fix a crash of some webcams on ARM arch
When plugging some webcams on ARM, the system crashes.
This is because we alloc buffer for an urb through usb_buffer_alloc,
the alloced buffer is already in DMA coherent region, so we should
set the flag of this urb to URB_NO_TRANSFER_DMA_MAP, otherwise when
we submit this urb, the hcd core will handle this address as an
non-DMA address and call dma_map_single/sg to map it. On arm
architecture, dma_map_single a DMA coherent address will be catched
by a BUG_ON().
Signed-off-by: Jason Wang jason77.w...@gmail.com
Signed-off-by: Jean-François Moine moin...@free.fr
Cc: sta...@kernel.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
I guess the cx231xx driver is trying to DMA-map buffers whose location
is not appropriate for DMA-mapping, because they are already in an DMA
coherent region. Is the fix just to add the same
URB_NO_TRANSFER_DMA_MAP to the urb-transfer_flags ? Or is it something
completely different ?
Hi Thomas,
I ran into the same issue on em28xx in the past (which is what those
parts of cx231xx are based on). Yes, just adding
URB_NO_TRANSFER_DMA_MAP should result in it starting to work. Please
try that out, and assuming it works feel free to submit a patch which
can be included upstream.
Regards,
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recursive locking problem
On Tue, Sep 13, 2011 at 5:34 PM, Steve Kerrison st...@stevekerrison.com wrote: At the risk of sounding silly, why do we rely on i2c gating so much? The whole point of i2c is that you can sit a bunch of devices on the same pair of wires and talk to one at a time. Steve, There are essentially two issues here. To address the general question, many tuner chips require an i2c gate because their onboard i2c controller is implemented using interrupts, and servicing the interrupts to even check if the traffic is intended for the tuner can interfere with the core tuning function. In other words, the cost of the chip watching for traffic can adversely effect tuning quality. As a result, most hardware designs are such that the demodulator gates the i2c traffic such that the tuner only *ever* sees traffic intended for it. The second issue is that within the LinuxTV drivers there is inconsistency regarding whether the i2c gate is opened/closed by the tuner driver or whether it's done by the demod. Some drivers have the demod driver open the gate, issue the tuning request, and then close the gate, while in other drivers the tuner driver opens/closes the gate whenever there are register reads/writes to the tuner. It's all about the granularity of implementation (the demod approach only involves one open/close but it's for potentially a longer period of time, versus the tuner approach which opens/closes the gate repeatedly as needed, which means more open/closes but the gate is open for the bare minimum of time required). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recursive locking problem
On Tue, Sep 13, 2011 at 5:58 PM, Steven Toth st...@kernellabs.com wrote: Can any one shed some light on this? I appreciate it's not a linux or indeed linux-media specific issue as the hardware itself is designed this way. i2c gates exist to isolate the downstream components from any spurious RF noise generated by noisy components on the i2c bus. You don't want to couple demod noise into the tuner by default. Steve (Kerrison), I would take Steven Toth's explanation as more authoritative than mine any day of the week. It's possible that I may have been misinformed regarding the rationale for why the gate is required. Regards, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:40 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Hi Devin, Em 06-09-2011 12:29, Mauro Carvalho Chehab escreveu: There are several issues with the original alsa_stream code that got fixed on xawtv3, made by me and by Hans de Goede. Basically, the code were re-written, in order to follow the alsa best practises. Backport the changes from xawtv, in order to make it to work on a wider range of V4L and sound adapters. FYI, just flooded your mailbox with 10 patches for tvtime. ;) I'm wanting to test some things with tvtime on one of my testboxes, but some of my cards weren't working with the alsa streaming, due to a few bugs that were solved on xawtv fork. So, I decided to backport it to tvtime and recompile the Fedora package for it. That's where the other 9 patches come ;) Basically, after applying this series of 10 patches, we can just remove all patches from Fedora, making life easier for distro maintainers (as the same thing is probably true on other distros - at least one of the Fedora patches came from Debian, from the fedora git logs). One important thing for distros is to have a tarball with the latest version hosted on a public site, so I've increased the version to 1.0.3 and I'm thinking on storing a copy of it at linuxtv, just like we do with xawtv3. If you prefer, all patches are also on my tvtime git tree, at: http://git.linuxtv.org/mchehab/tvtime.git Thanks, Mauro Hi Mauro, Funny you should send these along today. Last Friday I was actually poking around at the Fedora tvtime repo because I was curious how they had dealt with the V4L1 support issue (whether they were using my patch removing v4l1 or some variant). I've actually pulled in Fedora patches in the past (as you can see from the hg repo), and it has always been my intention to do it for the other distros as well (e.g. debian/Ubuntu). So I appreciate your having sent these along. I'll pull these in this week, do some testing to make sure nothing serious got broken, and work to spin a 1.0.3 toward the end of the week. Given the number of features/changes, and how long it's been since the last formal release, I was considering calling it 1.1.0 instead though. I've been thinking for a while that perhaps the project should be renamed (or I considered prepending kl onto the front resulting in it being called kl-tvtime). This isn't out of vanity but rather my concern that the fork will get confused with the original project (for example, I believe Ubuntu actually already calls their modified tree tvtime 1.0.3). I'm open to suggestions in this regards. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 2:19 PM, Hans de Goede hdego...@redhat.com wrote: I think that what should be done is contact the debian / ubuntu maintainers, get any interesting fixes they have which the kl version misses merged, and then just declare the kl version as being the new official upstream (with the blessing of the debian / ubuntu guys, and if possible also with the blessing of the original authors). It has always been my intention to get the Debian/Ubuntu patches merged (as well as other distros). My thoughts behind renaming were oriented around the notion that that there are more distros out there than just Fedora/Ubuntu/Debian, but that may be something that isn't really a concern. Also, I had no idea whether the distros would actually switch over to the Kernel Labs version as the official upstream source, so providing it under a different name would in theory allow both packages to be available in parallel. From a practical standpoint, the Ubuntu folks have the original tvtime tarball and all their changes in one patch, which is clearly a bunch of patches that are mashed together probably in their build system. I need to reach out to them to find where they have an actual SCM tree or the individual patches. They've got a bunch of patches which would be good to get into a single tree (autobuild fixes, cross-compilation, locale updates, etc). This would require kl git to be open to others for pushing, or we could move the tree to git.linuxtv.org (which I assume may be easier then for you to make the necessary changes to give others push rights on kl.org). Kernel Labs has never really had any real interest in owning tvtime. I just setup the hg tree in an effort to get all the distro patches in one place and have something that builds against current kernels (and on which I can add improvements/fixes without users having to deal with patches). At the time there was also nobody who clearly had the desire to serve as an official maintainer. In the long term I have no real issue with the LinuxTV group being the official maintainer of record. I've got lots of ideas and things I would like to do to improve tvtime, but in practice I've done a pretty crappy job of maintaining the source (merging patches, etc) at this point. 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 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 3:12 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: From a practical standpoint, the Ubuntu folks have the original tvtime tarball and all their changes in one patch, which is clearly a bunch of patches that are mashed together probably in their build system. I need to reach out to them to find where they have an actual SCM tree or the individual patches. They've got a bunch of patches which would be good to get into a single tree (autobuild fixes, cross-compilation, locale updates, etc). Yeah, it seems interesting. Maybe we can get something from this place: http://packages.qa.debian.org/t/tvtime.html The maintainer there seems to be: http://qa.debian.org/developer.php?login=ba...@debian.org I reached out to the Ubuntu maintainer; we'll see if he gets back to me. From what I can tell it seems like Debian is actually taking the patches from Ubuntu (yes, I realize this is backwards from their typical process where Ubuntu bases their stuff on Debian). In the long term I have no real issue with the LinuxTV group being the official maintainer of record. I've got lots of ideas and things I would like to do to improve tvtime, but in practice I've done a pretty crappy job of maintaining the source (merging patches, etc) at this point. Putting it on a common place and giving permissions to a group of people is interesting, as none of us are focused on userspace, so we all have a very limited amount of time for dealing with userspace applications. By giving commit rights to a group of developers, it ends that more developers will contribute, speeding up the development. That was what happened with v4l-utils and, on a minor scale, with xawtv3. If you're ok with that, I can set a tvtime git repository at LinuxTV, cloning the tree I've created there already (it is a pure conversion of your tree from mercurial into git, if I remove the patches I've done so far from your clone), giving you the ownership of the new tree, and marking it as a shared repository. I have no problem with this. Let's set it up. I have already all set there to allow shared access to the repository (in opposite to -hg, git works really cool with shared repositories). I actually haven't hosted any git repos on linuxtv.org before. I'm assuming my ssh public key got copied over from when I was hosting hg repos there? We can later add permissions to the developers interested on helping the tvtime maintenance that you agree to add. Sounds good. As said earlier, Kernel Labs never really wanted to be the maintainer for tvtime - we did it because nobody else wanted to (and vektor never responded to emails I sent him offering to help). That said, a community oriented approach is probably the best for everybody involved. I'll probably be looking in the next couple of weeks to write some fresh content for a tvtime website. The stuff on tvtime.sourceforge.net is so dated almost none of it still applies. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:29 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: There are several issues with the original alsa_stream code that got fixed on xawtv3, made by me and by Hans de Goede. Basically, the code were re-written, in order to follow the alsa best practises. Backport the changes from xawtv, in order to make it to work on a wider range of V4L and sound adapters. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Mauro, What tuners did you test this patch with? I went ahead and did a git pull of your patch series into my local git tree, and now my DVC-90 (an em28xx device) is capturing at 32 KHz instead of 48 (this is one of the snd-usb-audio based devices, not em28xx-alsa). Note I tested immediately before pulling your patch series and the audio capture was working fine. I think this patch series is going in the right direction in general, but this patch in particular seems to cause a regression. Is this something you want to investigate? I think we need to hold off on pulling this series into the new tvtime master until this problem is resolved. 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 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 10:58 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
On Tue, Sep 6, 2011 at 11:29 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
There are several issues with the original alsa_stream code that got
fixed on xawtv3, made by me and by Hans de Goede. Basically, the
code were re-written, in order to follow the alsa best practises.
Backport the changes from xawtv, in order to make it to work on a
wider range of V4L and sound adapters.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Mauro,
What tuners did you test this patch with? I went ahead and did a git
pull of your patch series into my local git tree, and now my DVC-90
(an em28xx device) is capturing at 32 KHz instead of 48 (this is one
of the snd-usb-audio based devices, not em28xx-alsa).
Note I tested immediately before pulling your patch series and the
audio capture was working fine.
I think this patch series is going in the right direction in general,
but this patch in particular seems to cause a regression. Is this
something you want to investigate? I think we need to hold off on
pulling this series into the new tvtime master until this problem is
resolved.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
Spent a few minutes digging into this. Looks like the snd-usb-audio
driver advertises 8-48KHz. However, it seems that it only captures
successfully at 48 KHz.
I made the following hack and it started working:
diff --git a/src/alsa_stream.c b/src/alsa_stream.c
index b6a41a5..57e3c3d 100644
--- a/src/alsa_stream.c
+++ b/src/alsa_stream.c
@@ -261,7 +261,7 @@ static int setparams(snd_pcm_t *phandle, snd_pcm_t *chandle,
fprintf(error_fp, alsa: Will search a common rate between %u and %u\n,
ratemin, ratemax);
-for (i = ratemin; i = ratemax; i+= 100) {
+for (i = ratemax; i = ratemin; i-= 100) {
err = snd_pcm_hw_params_set_rate_near(chandle, c_hwparams, i, 0);
if (err)
continue;
Basically the above starts at the *maximum* capture resolution and
works its way down. One might argue that this heuristic makes more
sense anyway - why *wouldn't* you want the highest quality audio
possible by default (rather than the lowest)?
Even with that patch though, I hit severe underrun/overrun conditions
at 30ms of latency (to the point where the audio is interrupted dozens
of times per second). Turned it up to 50ms and it's much better.
That said, of course such a change would impact lipsync, so perhaps we
need to be adjusting the periods instead.
ALSA has never been my area of expertise, so I look to you and Hans to
offer some suggestions.
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 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:29 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Basically the above starts at the *maximum* capture resolution and works its way down. One might argue that this heuristic makes more sense anyway - why *wouldn't* you want the highest quality audio possible by default (rather than the lowest)? That change makes sense to me. Yet, you should try to disable pulseaudio and see what's the _real_ speed that the audio announces. On Fedora, just removing pulsaudio-oss-plugin (or something like that) is enough. It seems doubtful that my em2820 WinTV USB2 is different than yours. I suspect that pulseaudio is passing the extra range, offering to interpolate the data. I disabled pulseaudio and the capture device is advertising the exact same range (8-48 KHz). Seems to be behaving the same way as well. So while I'm usually willing to blame things on Pulse, this doesn't look like the case here. Even with that patch though, I hit severe underrun/overrun conditions at 30ms of latency (to the point where the audio is interrupted dozens of times per second). Yes, it is the same here: 30ms on my notebook is not enough for WinTV USB2 (it is OK with HVR-950). Turned it up to 50ms and it's much better. That said, of course such a change would impact lipsync, so perhaps we need to be adjusting the periods instead. We've added a parameter for that on xawtv3 (--alsa-latency). We've parametrized it at the alsa stream function call. So, all it needs is to add a new parameter at tvtime config file. Ugh. We really need some sort of heuristic to do this. It's unreasonable to expect users to know about some magic parameter buried in a config file which causes it to start working. Perhaps a counter that increments whenever an underrun is hit, and after a certain number it automatically restarts the stream with a higher latency. Or perhaps we're just making some poor choice in terms of the buffers/periods for a given rate. 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 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:37 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Tue, Sep 6, 2011 at 11:29 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Basically the above starts at the *maximum* capture resolution and works its way down. One might argue that this heuristic makes more sense anyway - why *wouldn't* you want the highest quality audio possible by default (rather than the lowest)? That change makes sense to me. Yet, you should try to disable pulseaudio and see what's the _real_ speed that the audio announces. On Fedora, just removing pulsaudio-oss-plugin (or something like that) is enough. It seems doubtful that my em2820 WinTV USB2 is different than yours. I suspect that pulseaudio is passing the extra range, offering to interpolate the data. I disabled pulseaudio and the capture device is advertising the exact same range (8-48 KHz). Seems to be behaving the same way as well. So while I'm usually willing to blame things on Pulse, this doesn't look like the case here. Even with that patch though, I hit severe underrun/overrun conditions at 30ms of latency (to the point where the audio is interrupted dozens of times per second). Yes, it is the same here: 30ms on my notebook is not enough for WinTV USB2 (it is OK with HVR-950). Turned it up to 50ms and it's much better. That said, of course such a change would impact lipsync, so perhaps we need to be adjusting the periods instead. We've added a parameter for that on xawtv3 (--alsa-latency). We've parametrized it at the alsa stream function call. So, all it needs is to add a new parameter at tvtime config file. Ugh. We really need some sort of heuristic to do this. It's unreasonable to expect users to know about some magic parameter buried in a config file which causes it to start working. Perhaps a counter that increments whenever an underrun is hit, and after a certain number it automatically restarts the stream with a higher latency. Or perhaps we're just making some poor choice in terms of the buffers/periods for a given rate. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com One more thing worth noting before I quit for the night: What audio processor is on your WinTV USB 2 device? The DVC-90 has an emp202. Perhaps the WInTV uses a different audio processor (while still using an em2820 as the bridge)? That might explain why your device advertises effectively only one capture rate (32), while mine advertises a whole range (8-48). 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 01/10] alsa_stream: port changes made on xawtv3
On Tue, Sep 6, 2011 at 11:42 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: One more thing worth noting before I quit for the night: What audio processor is on your WinTV USB 2 device? The DVC-90 has an emp202. Perhaps the WInTV uses a different audio processor (while still using an em2820 as the bridge)? That might explain why your device advertises effectively only one capture rate (32), while mine advertises a whole range (8-48). Just took a look at the driver code. Seems we are calling em28xx_analog_audio_set() even if it's not using vendor audio. And that function actually hard-codes the rate to 48KHz. So here's the question: if using snd-usb-audio, should we really be poking at the AC97 registers at all? It seems that doing such can just get the audio processor state out of sync with however snd-usb-audio set it up. For example, the snd-usb-audio driver may very well be configuring the audio to 32 KHz, and then we reset the chip's state to 48Khz when we start streaming without the snd-usb-audio driver's knowledge. It seems like we should only be setting up the AC97 registers if it's an AC97 audio processor *and* it's using vendor audio. 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: AVerTV Hybrid Volar MAX (H826) wiki entry
On Tue, Aug 30, 2011 at 7:44 AM, Brian J. Murrell br...@interlinx.bc.ca wrote: Hi, I was looking at the wiki for the supported status of the AVerMedia AVerTV Hybrid Volar MAX (H826). The wiki says it's not supported. But the wiki also says it's a PCIe card, which it's clearly not: http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431 Additionally in the AP Driver tab of that page (http://www.avermedia-usa.com/AVerTV/Product/ProductDetail.aspx?Id=431tab=APDriver) there is a Linux driver which appears to have (granted, non-GPL) source included with it. But surely given source to a working driver, a cleanroom GPL driver could be developed and supported, yes? Maybe that source is just supporting source for a binary blob. I didn't look that closely. In any case, I am just wondering what the real supported status of that device is given that the wiki is incorrect about at least some details of the device. Even if it's not supported, somebody with more understanding of this device than I (I've just read a product page) ought to fix the wiki. In fixing it, I think it's only fair to point to the vendor supplied driver, even if it's not open source and/or not a compatible open source license. They've got a history of violating the GPL by shipping closed source binary drivers which link against GPL'd DVB drivers (thereby leveraging the hard work of the developers who GPL'd drivers, while not giving any of their stuff back). I cannot speak for the other developers but I wont' go near this crap with a ten foot pole. 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 1/2] DVB: dvb_frontend: convert semaphore to mutex
On Wed, Aug 24, 2011 at 1:33 PM, Andreas Oberritter o...@linuxtv.org wrote: Signed-off-by: Andreas Oberritter o...@linuxtv.org This may seem like a silly question, but *why* are you making this change? There is no explanation for what prompted it. Is it in response to some issue you encountered? I'm asking because in general dvb_frontend has a fairly complicated locking model, and unless there is a compelling reason to make changes I would be against it. In other words, this is a bad place for arbitrary cleanup patches. 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 1/2] DVB: dvb_frontend: convert semaphore to mutex
On Wed, Aug 24, 2011 at 2:02 PM, Andreas Oberritter o...@linuxtv.org wrote: It's impossible to clean up dvb_frontend.c, which looks quite unmaintained, without touching it. It is quite unmaintained. In fact, it was broken for numerous cards for almost two years before I finally got someone in the Hauppauge UK office to mail me a couple of affected boards to test with. Now that it works, I'm very hesitant to see any chances made unless there is a *very* good reason. It's just too damn easy to introduce subtle bugs in there that work for your card but cause breakage for others. 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 1/2] DVB: dvb_frontend: convert semaphore to mutex
On Wed, Aug 24, 2011 at 2:08 PM, Andreas Oberritter o...@linuxtv.org wrote: Instead of wasting your time with theory, you could have easily reviewed my patch. It's really *very* simple any anyone having used semphores or mutexes in the kernel should be able to see that. There's no need to resort to belittlement. Both of us have a non-trivial number of commits to the Linux kernel. My concern is that in the kernel a semaphore with a unit of one is *not* necessarily the same as a mutex. In particular you need to take into account the calling context since mutexes do more enforcement of certain conditions that may have been acceptable for a semaphore. From http://www.kernel.org/doc/Documentation/mutex-design.txt : === - 'struct mutex' semantics are well-defined and are enforced if CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have virtually no debugging code or instrumentation. The mutex subsystem checks and enforces the following rules: * - only one task can hold the mutex at a time * - only the owner can unlock the mutex * - multiple unlocks are not permitted * - recursive locking is not permitted * - a mutex object must be initialized via the API * - a mutex object must not be initialized via memset or copying * - task may not exit with mutex held * - memory areas where held locks reside must not be freed * - held mutexes must not be reinitialized * - mutexes may not be used in hardware or software interrupt * contexts such as tasklets and timers === and: === Disadvantages - The stricter mutex API means you cannot use mutexes the same way you can use semaphores: e.g. they cannot be used from an interrupt context, nor can they be unlocked from a different context that which acquired it. [ I'm not aware of any other (e.g. performance) disadvantages from using mutexes at the moment, please let me know if you find any. ] === In short, you cannot just arbitrarily replace one with the other. You need to look at all the possible call paths and ensure that there aren't any cases for example where the mutex is set in one but cleared in the other. Did you evaluate your change in the context of each of the differences described in the list above? Without any documentation in the patch, we have absolutely no idea what level of due diligence you exercised in ensuring this didn't cause breakage. 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] Latest version of em28xx / em28xx-dvb patch for PCTV 290e
On Thu, Aug 18, 2011 at 1:52 PM, Chris Rankin ranki...@yahoo.com wrote: Hi, Here's my latest patch for the em28xx / em28xx-dvb modules, which addresses the following problems: a) Locking problem when unplugging and then replugging USB adapter. b) Race conditions between adding/removing devices from the devlist, while simultaneously loading/unloading extension modules. c) Resource leaks on error paths. d) Preventing the DVB framework from trying to put the adapter into sleep mode when the adapter has been physically unplugged. (This results in occasional -19 errors from I2C functions when disconnecting.) e) Use atomic bit operations to manage device in use slots, and enforce upper limit of EM28XX_MAXBOARDS slots. Hi Chris, You would be well served to break this into a patch series, as it tends to be difficult to review a whole series of changes in a single patch. You seem to be mixed in a bunch of useless changes alongside functional changes. For example, if you're trying to add in a missing goto inside an exception block, doing that at the same time as renaming instances of errCode to retval just creates confusion. And finally, the mutex structure used for the modules is somewhat complicated due to to the need to keep the analog side of the board locked while initializing the digital side. This code was added specifically to prevent race conditions that were seen during initialization as things like udev and dbus attempted to connect to the newly created V4L device while the em28xx-dvb module was still coming up. In other words, I don't doubt there are bugs, and I cannot say whether your fixes are appropriate without giving a hard look at the logic. But you should be aware of the thinking behind the way it was done and it would be very worthwhile if you could test with at least one hybrid product to ensure the changes you are making don't break anything (the em2874 used in the 290e is a poor test case since it doesn't have analog support). BTW, was there a reason why the em28xx-dvb module doesn't use dvb-usb? This is largely a product of the history of the devices using the framework. The em28xx driver was originally analog only, and DVB support was added later as new chips came out which needed it. The dvb-usb driver came from dedicated DVB devices that had no analog support. In fact, even today the lack of analog support is a huge deficiency in that framework which is why we don't support the analog side of any hybrid devices that use dvb-usb. In other words, if we were reinventing this stuff today, there would probably be only a single framework shared by dvb-usb and em28xx. But at this point it's too much cost and too little benefit to go through the work to attempt to merge 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] Latest version of em28xx / em28xx-dvb patch for PCTV 290e
On Thu, Aug 18, 2011 at 2:43 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Thu, Aug 18, 2011 at 1:52 PM, Chris Rankin ranki...@yahoo.com wrote: Hi, Here's my latest patch for the em28xx / em28xx-dvb modules, which addresses the following problems: a) Locking problem when unplugging and then replugging USB adapter. b) Race conditions between adding/removing devices from the devlist, while simultaneously loading/unloading extension modules. c) Resource leaks on error paths. d) Preventing the DVB framework from trying to put the adapter into sleep mode when the adapter has been physically unplugged. (This results in occasional -19 errors from I2C functions when disconnecting.) e) Use atomic bit operations to manage device in use slots, and enforce upper limit of EM28XX_MAXBOARDS slots. Hi Chris, You would be well served to break this into a patch series, as it tends to be difficult to review a whole series of changes in a single patch. You seem to be mixed in a bunch of useless changes alongside functional changes. For example, if you're trying to add in a missing goto inside an exception block, doing that at the same time as renaming instances of errCode to retval just creates confusion. And finally, the mutex structure used for the modules is somewhat complicated due to to the need to keep the analog side of the board locked while initializing the digital side. This code was added specifically to prevent race conditions that were seen during initialization as things like udev and dbus attempted to connect to the newly created V4L device while the em28xx-dvb module was still coming up. In other words, I don't doubt there are bugs, and I cannot say whether your fixes are appropriate without giving a hard look at the logic. But you should be aware of the thinking behind the way it was done and it would be very worthwhile if you could test with at least one hybrid product to ensure the changes you are making don't break anything (the em2874 used in the 290e is a poor test case since it doesn't have analog support). BTW, was there a reason why the em28xx-dvb module doesn't use dvb-usb? This is largely a product of the history of the devices using the framework. The em28xx driver was originally analog only, and DVB support was added later as new chips came out which needed it. The dvb-usb driver came from dedicated DVB devices that had no analog support. In fact, even today the lack of analog support is a huge deficiency in that framework which is why we don't support the analog side of any hybrid devices that use dvb-usb. In other words, if we were reinventing this stuff today, there would probably be only a single framework shared by dvb-usb and em28xx. But at this point it's too much cost and too little benefit to go through the work to attempt to merge them. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Probably one more point worth making: I definitely appreciate that you've take the time to focus on these particular problems. I've been complaining about them for months but just never got around to rolling up my sleeves to debug them myself. In other words, don't interpret anything in my previous email as discouragement. 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: Hauppauge Aero-M Driver Problem
On Sun, Aug 14, 2011 at 2:33 AM, Trip Ericson webmas...@rabbitears.info wrote: Hello, all: Since my previous e-mail, I was able to get a Linux driver for the tuner from Hauppauge. It came in the form of a v4l tree with the driver included. I adjusted the v4l/.config file to only build the necessary driver. Once it built and I invoked depmod -a, I hooked in my tuner, it detected the tuner, but then dmesg gave me: [31537.360109] dvb_usb_mxl111sf: probe of 2-1.4:1.0 failed with error -22 Does anyone have any idea what this could be? I can't find anything helpful about error -22 when I go looking. I can provide the link to the driver or output from any command requested, I just need to know what to provide and how best to share it. There was also a driver for the Mobile DTV half of the tuner included, but I could not get that part to build successfully, so I abandoned it for the time being in favor of getting the regular ATSC part to work. Thanks for any thoughts or assistance. It is greatly appreciated. =) - Trip Hello Trip, If Hauppauge provided you a driver, you need to direct all support questions to them. We aren't going to know the first thing about what is wrong with such a driver since we've never seen it. If they've made available a driver in source form under the GPL, that's a great first step. However it doesn't mean that the open source community all of a sudden becomes responsible for the burden associated with supporting such a driver (in particular when no datasheets have been made available). 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: How to git and build HVR-2200 drivers from Kernel labs ?
On Sun, Aug 14, 2011 at 5:21 AM, Declan Mullen declan.mul...@bigpond.com wrote: Hi I've got a 8940 edition of a Hauppauge HVR-2200. The driver is called saa7164. The versions included in my OS (mythbuntu 10.10 x86 32bit, kernel 2.6.35-30) and from linuxtv.org are too old to recognise the 8940 edition. Posts #124 to #128 in the Hauppauge HVR-2200 Tuner Install Guide topic (http://www.pcmediacenter.com.au/forum/topic/37541-hauppauge-hvr-2200-tuner- install-guide/page__view__findpost__p__321195) document my efforts with those versions. So I wish to use the latest stable drivers from the driver maintainers, ie http://kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=summary Problem is, I don't know git and I don't know how I'm suppose to git, build and install it. Taking a guess I've tried: git clone git://kernellabs.com/stoth/saa7164-stable.git cd saa7164-stable make menuconfig make However I suspect these are not the optimum steps, as it seems to have downloaded and built much more than just the saa7164 drivers. The git pulled down nearly 1GB (which seems a lot) and the resultant menuconfig produced a very big .config. Am I doing the right steps or should I be doing something else to git, build and install the latest drivers ? Thanks, Declan Hello Declan, Blame Mauro and the other LinuxTV developers for moving to Git. When we had HG you could do just the v4l-dvb stack and apply it to your existing kernel. Now you have to suck down the *entire* kernel, and there's no easy way to separate out just the v4l-dvb stuff (like the saa7164 driver). The net effect is it's that much harder for end-users to try out new drivers, and even harder still for developers to maintain drivers out-of-tree. All that said, Ubuntu 10.10 deviates very little in terms of the saa7164 driver. What you have is probably already identical to what's in the kernellabs.com tree. And yes, PAL support is broken even in the kernellabs tree, so if that was your motivation then updating to the current KL stable tree won't help you. 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: How to git and build HVR-2200 drivers from Kernel labs ?
Only Steven can look at the schematic and know for sure what prompted them to update to a new PCI ID. However, you can definitely try doing card=4 and see if it works. Card=9 won't work since that card number is not valid given the card list in your driver. Devin On Sun, Aug 14, 2011 at 7:23 PM, Declan Mullen declan.mul...@bigpond.com wrote: On Sunday 14 August 2011 22:14:48 you wrote: On Sun, Aug 14, 2011 at 5:21 AM, Declan Mullen declan.mul...@bigpond.com wrote: Hi I've got a 8940 edition of a Hauppauge HVR-2200. The driver is called saa7164. The versions included in my OS (mythbuntu 10.10 x86 32bit, kernel 2.6.35-30) and from linuxtv.org are too old to recognise the 8940 edition. Posts #124 to #128 in the Hauppauge HVR-2200 Tuner Install Guide topic (http://www.pcmediacenter.com.au/forum/topic/37541-hauppauge-hvr-2200-tun er- install-guide/page__view__findpost__p__321195) document my efforts with those versions. So I wish to use the latest stable drivers from the driver maintainers, ie http://kernellabs.com/gitweb/?p=stoth/saa7164-stable.git;a=summary Problem is, I don't know git and I don't know how I'm suppose to git, build and install it. Taking a guess I've tried: git clone git://kernellabs.com/stoth/saa7164-stable.git cd saa7164-stable make menuconfig make However I suspect these are not the optimum steps, as it seems to have downloaded and built much more than just the saa7164 drivers. The git pulled down nearly 1GB (which seems a lot) and the resultant menuconfig produced a very big .config. Am I doing the right steps or should I be doing something else to git, build and install the latest drivers ? Thanks, Declan Hello Declan, Blame Mauro and the other LinuxTV developers for moving to Git. When we had HG you could do just the v4l-dvb stack and apply it to your existing kernel. Now you have to suck down the *entire* kernel, and there's no easy way to separate out just the v4l-dvb stuff (like the saa7164 driver). The net effect is it's that much harder for end-users to try out new drivers, and even harder still for developers to maintain drivers out-of-tree. All that said, Ubuntu 10.10 deviates very little in terms of the saa7164 driver. What you have is probably already identical to what's in the kernellabs.com tree. And yes, PAL support is broken even in the kernellabs tree, so if that was your motivation then updating to the current KL stable tree won't help you. Cheers, Devin Many thanks for the clarification about git. The only reason why I'm attempting to use a newer saa7164 driver is because the driver in my ubuntu 10.10 (2.6.35-30, x86 32bit) doesn't recognise the 8940 edition of my HVR-2200 (and doesn't support the card=9 option that I believe is specifically for the 8940 edition). Example dmesg output: $ dmesg | grep saa7 [ 18.367431] saa7164 driver loaded [ 18.367467] saa7164 :02:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 18.367472] saa7164[0]: Your board isn't known (yet) to the driver. [ 18.367473] saa7164[0]: Try to pick one of the existing card configs via [ 18.367474] saa7164[0]: card=n insmod option. Updating to the latest [ 18.367475] saa7164[0]: version might help as well. [ 18.367684] saa7164[0]: Here are valid choices for the card=n insmod option: [ 18.367739] saa7164[0]: card=0 - Unknown [ 18.367789] saa7164[0]: card=1 - Generic Rev2 [ 18.367840] saa7164[0]: card=2 - Generic Rev3 [ 18.367891] saa7164[0]: card=3 - Hauppauge WinTV-HVR2250 [ 18.367943] saa7164[0]: card=4 - Hauppauge WinTV-HVR2200 [ 18.367995] saa7164[0]: card=5 - Hauppauge WinTV-HVR2200 [ 18.368059] saa7164[0]: card=6 - Hauppauge WinTV-HVR2200 [ 18.368112] saa7164[0]: card=7 - Hauppauge WinTV-HVR2250 [ 18.368164] saa7164[0]: card=8 - Hauppauge WinTV-HVR2250 [ 18.369142] CORE saa7164[0]: subsystem: 0070:8940, board: Unknown [card=0,autodetected] [ 18.369147] saa7164[0]/0: found at :02:00.0, rev: 129, irq: 16, latency: 0, mmio: 0xfd40 [ 18.369152] saa7164 :02:00.0: setting latency timer to 64 [ 18.369162] saa7164_initdev() Unsupported board detected, registering without firmware To get this 8940 card working with my ubuntu 10.10 system, what would you recommend I try ? Should I be trying to extract the new driver from what the above git and makes, ie just copy into place the new saa7164.ko file ? Or should my existing driver work if i use the card=4 option ? Thanks, Declan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
Re: PCTV 290e nanostick and remote control support
On Sat, Aug 13, 2011 at 9:43 PM, Chris Rankin ranki...@yahoo.com wrote:
Hi,
The rc-pinnacle-pctv-hd keymap is missing the definition of the OK key:
--- linux-3.0/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c.orig
2011-08-14 02:42:01.0 +0100
+++ linux-3.0/drivers/media/rc/keymaps/rc-pinnacle-pctv-hd.c 2011-08-14
02:12:45.0 +0100
@@ -20,6 +20,7 @@
{ 0x0701, KEY_MENU }, /* Pinnacle logo */
{ 0x0739, KEY_POWER },
{ 0x0703, KEY_VOLUMEUP },
+ { 0x0705, KEY_OK },
{ 0x0709, KEY_VOLUMEDOWN },
{ 0x0706, KEY_CHANNELUP },
{ 0x070c, KEY_CHANNELDOWN },
Cheers,
Chris
Wow, how the hell did I miss that? I did numerous remotes for em28xx
based devices that use that RC profile, and never noticed that issue.
Will have to check the merge logs. Maybe the key got lost when they
refactored the IR support.
Chris, you should add a signed-off-by tag and submit this as a patch
so it can be included upstream.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
LinuxTV.org wiki broken - won't allow edits
Well, now I understand why there hasn't been any spam on the linuxtv.org wiki for a couple of weeks. Editing is broken. Attempts to edit articles shows: Internal error Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. 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: Support for Hauppauge WinTV HVR-3300
On Sat, Aug 6, 2011 at 10:44 AM, Steve Wolter swol...@sdf.lonestar.org wrote: Dear linux-media list, I have recently bought a Hauppauge WinTV HVR-3300 and am trying to make it run with Linux. Going by the output of lspci -v [1], I tried to go with the cx23885, which doesn't recognize the card: [24296.910574] cx23885 driver version 0.0.2 loaded [24296.910612] cx23885 :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [24296.910620] cx23885[0]: Your board isn't known (yet) to the driver. [24296.910621] cx23885[0]: Try to pick one of the existing card configs via [24296.910623] cx23885[0]: card=n insmod option. Updating to the latest [24296.910625] cx23885[0]: version might help as well. [...] [24296.911165] CORE cx23885[0]: subsystem: 0070:53f1, board: UNKNOWN/GENERIC [card=0,autodetected] [24297.037221] cx23885_dev_checkrevision() Hardware revision = 0xd0 [24297.037228] cx23885[0]/0: found at :01:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xfe40 [24297.037236] cx23885 :01:00.0: setting latency timer to 64 [24297.037304] cx23885 :01:00.0: irq 48 for MSI/MSI-X Seems like some work is necessary to do here, which I'd be willing to do. Can anyone suggest which might be the most similar card or what I should try to write a driver for this? Hi Steve, Like the 4400 and 5500, the 3300 uses both DVB-S and DVB-T demodulator chips for which there is currently no driver. Somebody would have to write those drivers from scratch in order for any of those products to be supported. In other words, it's not a case of just needing to add a few lines of code for another board profile. 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: Support for Hauppauge WinTV HVR-3300
On Sat, Aug 6, 2011 at 12:05 PM, Steve Wolter swol...@sdf.lonestar.org wrote: Fair enough, thanks for the feedback, I think that project is out of my scope for now. I'm mainly interested in the analog demodulation at the moment, have the DVB capacity mainly for future use. Do you know anything about the analog TV decoder in there? Is this decoupled from the DVB stuff and could be made to work on its own? The support for dvb is indeed decoupled from analog. However, the cx23888 is different enough from the cx23885 where work needs to be done on the core driver before analog could work. Steven Toth did a bunch of this work in a private tree, but it hasn't been merged into the mainline kernel yet (and given how onerous the upstream submission process has become, it is unclear when that will actually happen). http://kernellabs.com/hg/~stoth/cx23888-encoder/ In other words, even for analog you would need a bunch of patches in the mainline cx23885 driver before anything would start to work. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any advice for writing Ruby driver for Hauppauge WinTV-HVR-1150 on Linux?
On Sat, Aug 6, 2011 at 8:48 PM, Bob Carpenter rgc3...@yahoo.com wrote: I'd like to write a driver using Ruby language for a Hauppauge WinTV-HVR-1150 card. I will be attaching an NTSC analog camera to the composite video input and want to stream the video across the internet to a client app that can display it. I've never written a PCI driver. The 1150 card will be attached to an Ubuntu 10.04 box. I'd welcome any ideas or advice to get started. Thanks, --Bob Several points: Under Linux, you don't write drivers in Ruby. You write them in C. The HVR-1150 already has a driver under Linux. You probably want to be writing a Ruby application, not a driver. You should probably start by reading the video4linux2 API documentation, which is the kernel API for interacting with tuner drivers. 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: Trying to support for HAUPPAUGE HVR-930C
Hi Daniel, Sorry for the delayed reply. I actually did reply five days ago but the message got dropped by the ML filter because my phone apparently formatted it into HTML content. Resending here... Do you have a contact at Trident I can ask to get access to that data sheet? I have been looking for it for some time now as well. Nope. I had access to them under NDA but do not anymore. And do you know if there are significant differences between the avf4910a and the avf4910b? They're completely different. I wouldn't even try to glean anything about the avfb by looking at the avfa 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: Trying to support for HAUPPAUGE HVR-930C
On Fri, Jul 29, 2011 at 7:15 AM, Eddi De Pieri e...@depieri.net wrote: 2011/7/28 Benjamin Larsson benja...@southpole.se: 0x82 is the address of the chip handling the analog signals(?) Micronas AVF 4910BA1 maybe. I don't have the schematic of hauppauge card, so I can't say you if 082 is the AVF 4910 Yes, it's an avf4910b. I did a Linux driver for the AVFA for the Viewcast boards, but there isn't a driver for the AFVB at this time. Should be pretty easy for you to whip one up though just by capturing the register sets under Windows and then replaying them for each of the three inputs. Devin So change the names so it is clear that this part sends commands to that chip. As I already told my patch is a derivate work of Terratec H5 Patch. Mauro's patch should have the same issue I'm not sure I understand the I2C addressing but my tuner is at 0xc2 and the demod at 0x52. Correct: the xc5000 is at 0xc2, the avf4910b is at 0x82 and the drx-k is at 0x52. 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: DVB-T issues w/ kernel 3.0
2011/7/27 Toralf Förster toralf.foers...@gmx.de: Hello, I'm wondering, whether there are known issues with the new kernel version just b/c of https://forums.gentoo.org/viewtopic.php?p=6766690#6766690 and https://bugs.kde.org/show_bug.cgi?id=278561 Hello Toralf, I don't think you're the first person to report this issue. That said, I don't think any developers have seen it, so it would be a very useful exercise if you could bisect the kernel and figure out which patch introduced the problem. Once we know what patch introduced the problem we will have a much better idea what action needs to be taken to address it. 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 v3] tuner_xc2028: Allow selection of the frequency adjustment code for XC3028
On Wed, Jul 27, 2011 at 10:34 AM, Mauro Carvalho Chehab mche...@redhat.com wrote: Btw, what's the video standard that you're using? DTV7? Does your device use a xc3028 or xc3028xl? Whats's your demod and board? It was in the first sentence of his email. He's got an HVR-1400, which uses the xc3028L and dib7000p. It's also worth noting that he isn't the first person to complain about tuning offset problems with the xc3028L. Just look at the rather nasty hack some random user did for the EVGA inDtube (which is xc3208L/s5h1409). http://linuxtv.org/wiki/index.php/EVGA_inDtube Bear in mind that it worked when I added the original support. Somebody caused a regression since then though. In short, I can appreciate why the user is frustrated. The xc3028L support worked at one point and then somebody broke the xc3028 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: DVB-T issues w/ kernel 3.0
On Wed, Jul 27, 2011 at 10:57 AM, Steffen Barszus steffenbpu...@googlemail.com wrote: Quote: The drivers from 2011-02-05 does not run, but the drivers from 2010-10-16 runs perfectly. should give at least a startingpoint/timeframe for bisecting ... allthough would be more usefull if based linuxtv git. Bear in mind the user was using the s2-liplianin branch and *not* the mainline linux_media tree. Hence anybody who does a bisect should be sure the starting/ending points are accurate. 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 problem: cx231xx error -71 with Hauppauge USB live2 on Ubuntu 11.04, netbook edition
On Tue, Jul 26, 2011 at 7:53 AM, Doychin Dokov r...@net1.cc wrote: [416830.939483] cx231xx #0: can't change interface 3 alt no. to 0 (err=-71) This is with the stock kernel, no media_build tree installed (I'm currently compiling it). Patches for this issue were submitted over the weekend. Check the mailing list for posts from Saturday or wait a few days for the patches to be merged into the linux_media tree. 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 problem: cx231xx error -71 with Hauppauge USB live2 on Ubuntu 11.04, netbook edition
On Tue, Jul 26, 2011 at 8:40 AM, Doychin Dokov r...@net1.cc wrote: I find only the Sunday fix for the power ramp issue, which states it's for a problem caused by the config hz being different of 100. Is this the patch you point me to, and do you think it's the solution in my case? # cat /boot/config-2.6.38-10-server | grep CONFIG_HZ CONFIG_HZ_100=y # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=100 There were actually two patches sent over the weekend, but the power ramp issue was only for people who had CONFIG_HZ set to 1000. In your case, you only need the first patch. See the email with subject: [PATCH] Fix regression introduced which broke the Hauppauge USBLive 2 for the patch you need. 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] Fix regression introduced which broke the Hauppauge USBLive 2
On Mon, Jul 25, 2011 at 1:48 AM, Palash Bandyopadhyay palash.bandyopadh...@conexant.com wrote: Mauro/Devin, Can someone give steps to reproduce the problem? Also if we need any particular h/w board to reproduce this problem. I dont seem to recall any delay requirement on the chip at power up/cycle time. Any I also dont recall seeing any problems with the Conexant evk boards. Mauro, have you been able to see this issue with a Conexant board? Hello Palash, The problem occurs if the kernel is configured for CONFIG_HZ to 1000 and on the Hauppauge USBLIve 2 hardware design. I'm assuming it's tied to two factors: 1. Some aspect of the power supply tied to the Mako core being a little slow to startup. I haven't compared the schematic to the EVK, but I could do that if we *really* think that is a worthwhile exercise. 2. On typical kernels which have CONFIG_HZ set to 100, a call to msleep(5) will actually take approximately 10ms (due to the clock resolution). However, if you have CONFIG_HZ set to 1000 then the call *actually* takes 5ms which is too short for this design. In other words, you would be unlikely to notice the issue unless you had CONFIG_HZ set to a high enough resolution for the msleep(5) to actually take 5ms. The changed as proposed should be very low impact. For users who have CONFIG_HZ set to 100 (which is typical), there will be no visible increase in time (since the call was already taking 10ms). For users who have CONFIG_HZ set to 1000, the net effect is that it takes an extra 20ms to switch hardware modes (since the #define in question is used at most four times in sequence). 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
