Re: [PATCH] mceusb: Add Twisted Melon USB IDs
On 12-07-11 06:53 PM, Mark Lord wrote:
Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
Signed-off-by: Mark Lord ml...@pobox.com
---
Mauro, please queue this up for inclusion in linux-3.6.
Patch is also attached to bypass emailer mangling.
Thanks.
--- linux-3.5-rc6/drivers/media/rc/mceusb.c 2012-07-07 20:23:56.0
-0400
+++ new/drivers/media/rc/mceusb.c 2012-07-11 18:44:03.113727658 -0400
@@ -199,6 +199,7 @@
#define VENDOR_REALTEK 0x0bda
#define VENDOR_TIVO 0x105a
#define VENDOR_CONEXANT 0x0572
+#define VENDOR_TWISTEDMELON 0x2596
enum mceusb_model_type {
MCE_GEN2 = 0, /* Most boards */
@@ -391,6 +392,12 @@
/* Conexant Hybrid TV RDU253S Polaris */
{ USB_DEVICE(VENDOR_CONEXANT, 0x58a5),
.driver_info = CX_HYBRID_TV },
+ /* Twisted Melon Inc. - Manta Mini Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8008) },
+ /* Twisted Melon Inc. - Manta Pico Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8016) },
+ /* Twisted Melon Inc. - Manta Transceiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8042) },
/* Terminating entry */
{ }
};
Mauro, what is the status of this patch?
Is it going upstream through your tree for Linux-3.6?
If not, I'll send it directly to Linus.
Thanks
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mceusb: Add Twisted Melon USB IDs
Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
Signed-off-by: Mark Lord ml...@pobox.com
---
Mauro, please queue this up for inclusion in linux-3.6.
Patch is also attached to bypass emailer mangling.
Thanks.
--- linux-3.5-rc6/drivers/media/rc/mceusb.c 2012-07-07 20:23:56.0
-0400
+++ new/drivers/media/rc/mceusb.c 2012-07-11 18:44:03.113727658 -0400
@@ -199,6 +199,7 @@
#define VENDOR_REALTEK 0x0bda
#define VENDOR_TIVO0x105a
#define VENDOR_CONEXANT0x0572
+#define VENDOR_TWISTEDMELON0x2596
enum mceusb_model_type {
MCE_GEN2 = 0, /* Most boards */
@@ -391,6 +392,12 @@
/* Conexant Hybrid TV RDU253S Polaris */
{ USB_DEVICE(VENDOR_CONEXANT, 0x58a5),
.driver_info = CX_HYBRID_TV },
+ /* Twisted Melon Inc. - Manta Mini Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8008) },
+ /* Twisted Melon Inc. - Manta Pico Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8016) },
+ /* Twisted Melon Inc. - Manta Transceiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8042) },
/* Terminating entry */
{ }
};
Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
Signed-off-by: Mark Lord ml...@pobox.com
---
Mauro, please queue this up for inclusion in linux-3.6.
Thanks.
--- linux-3.5-rc6/drivers/media/rc/mceusb.c 2012-07-07 20:23:56.0 -0400
+++ new/drivers/media/rc/mceusb.c 2012-07-11 18:44:03.113727658 -0400
@@ -199,6 +199,7 @@
#define VENDOR_REALTEK 0x0bda
#define VENDOR_TIVO 0x105a
#define VENDOR_CONEXANT 0x0572
+#define VENDOR_TWISTEDMELON 0x2596
enum mceusb_model_type {
MCE_GEN2 = 0, /* Most boards */
@@ -391,6 +392,12 @@
/* Conexant Hybrid TV RDU253S Polaris */
{ USB_DEVICE(VENDOR_CONEXANT, 0x58a5),
.driver_info = CX_HYBRID_TV },
+ /* Twisted Melon Inc. - Manta Mini Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8008) },
+ /* Twisted Melon Inc. - Manta Pico Receiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8016) },
+ /* Twisted Melon Inc. - Manta Transceiver */
+ { USB_DEVICE(VENDOR_TWISTEDMELON, 0x8042) },
/* Terminating entry */
{ }
};
[PATCH] dvb: fix tuner registration without CONFIG_DVB_NET
Ever since linux-3.1, my DVB tuners have been non-functional.
This turns out to be due to a bug in with this chunk of code
inside linux/drivers/media/video/videobuf-dvb.c:
/* register network adapter */
dvb_net_init(adapter, dvb-net, dvb-demux.dmx);
if (dvb-net.dvbdev == NULL) {
result = -ENOMEM;
goto fail_fe_conn;
}
The problem is, dvb_net_init() doesn't do anything
for the case where CONFIG_DVB_NET is not set.
And the code in videobuf-dvb.c treats this as a fatal error.
The patch below (linux-3.2.6) fixes the regression.
Signed-off-by: Mark Lord ml...@pobox.com
---
Patch is also attached to bypass email mangling.
--- linux-3.2.6/drivers/media/video/videobuf-dvb.c 2012-02-13
14:17:29.0
-0500
+++ linux/drivers/media/video/videobuf-dvb.c2012-02-18 13:21:42.422716047
-0500
@@ -226,9 +226,10 @@
}
/* register network adapter */
- dvb_net_init(adapter, dvb-net, dvb-demux.dmx);
- if (dvb-net.dvbdev == NULL) {
- result = -ENOMEM;
+ result = dvb_net_init(adapter, dvb-net, dvb-demux.dmx);
+ if (result 0) {
+ printk(KERN_WARNING %s: dvb_net_init failed (errno = %d)\n,
+ dvb-name, result);
goto fail_fe_conn;
}
return 0;
--- linux-3.2.6/drivers/media/video/videobuf-dvb.c 2012-02-13 14:17:29.0 -0500
+++ linux/drivers/media/video/videobuf-dvb.c 2012-02-18 13:21:42.422716047 -0500
@@ -226,9 +226,10 @@
}
/* register network adapter */
- dvb_net_init(adapter, dvb-net, dvb-demux.dmx);
- if (dvb-net.dvbdev == NULL) {
- result = -ENOMEM;
+ result = dvb_net_init(adapter, dvb-net, dvb-demux.dmx);
+ if (result 0) {
+ printk(KERN_WARNING %s: dvb_net_init failed (errno = %d)\n,
+ dvb-name, result);
goto fail_fe_conn;
}
return 0;
Re: [PATCH 5/8] [media] em28xx: initial support for HAUPPAUGE HVR-930C again
On 11-12-05 06:47 PM, Devin Heitmueller wrote: 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? That's good. But there definitely still is a race between modules in there somewhere. The HVR-950Q tuners use several: xc5000, au8522, au0828, .. and unless au0828 is loaded *last*, with a delay before/after, the dongles don't always work. Preloading all of the modules before allowing hardware detection seems to help. Even just changing from a mechanical hard drive to a very fast SSD is enough to change the behaviour from not-working to working (and sometimes the other way around). I tried to track this down a couple of years ago, and found cross-module calls failing because the target functions hadn't been loaded yet. But my lack of notes from 2-3 years ago isn't helpful here. Here's a similar report from 2 years ago, as valid today as it was then: http://www.mythtv.org/pipermail/mythtv-users/2010-January/279912.html Cheers -- To unsubscribe from this list: send the line unsubscribe linux-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 11-12-06 08:56 AM, Devin Heitmueller wrote: 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. If this discussion does change threads, could you folks please copy me on it? I'm already subscribed to several other kernel mailing lists in my roles as developer and maintainer of various bits, but I would like to avoid having yet another daily deluge added to my inbox. :) That said, I can test possible fixes for this stuff, and am rather interested to see it resolved. .. 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. .. 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 may try Mauro's locking suggestion -- more detail or a patch would be useful. Mauro? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Dmitry / Mauro, I'm encouraged by all of the good dialog happening here, and regret that I am unable to poke any further at the issue with ir-keytable for now. The system in question is now getting rebuilt with new/modern userspace, and I expect the original issue to vanish as a result. If I do see ir-keytable acting up again afterward, I'll let you know. But it will be whatever version Ubuntu 10.10 installs, not the newer one I used earlier in this thread. Cheers! -Mark -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-28 11:42 AM, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 11:53:25AM -0800, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 01:12:48PM -0500, Mark Lord wrote: On 11-01-27 11:39 AM, Dmitry Torokhov wrote: .. Hmm, what about compiling with debug and getting a core then? Sure. debug is easy, -g, but you'll have to tell me how to get it do produce a core dump. See if adjusting /etc/security/limits.conf will enable it to dump core. Otherwise you'll have to stick 'ulimit -c unlimited' somewhere... .. Any luck with getting the core? I'd really like to resolve this issue. .. I'm upgrading the box to new userspace now. But I still have the old installation drive, so perhaps I'll go there now and try this. My plan is to replace /usr/bin/ir-keytable with a script that issues the 'ulimit -c unlimited' command and then invokes the original /usr/bin/ir-keytable binary. Should take half an hour or so before I get back here again. -ml -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-28 03:55 PM, Mark Lord wrote: On 11-01-28 11:42 AM, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 11:53:25AM -0800, Dmitry Torokhov wrote: On Thu, Jan 27, 2011 at 01:12:48PM -0500, Mark Lord wrote: On 11-01-27 11:39 AM, Dmitry Torokhov wrote: .. Hmm, what about compiling with debug and getting a core then? Sure. debug is easy, -g, but you'll have to tell me how to get it do produce a core dump. See if adjusting /etc/security/limits.conf will enable it to dump core. Otherwise you'll have to stick 'ulimit -c unlimited' somewhere... .. Any luck with getting the core? I'd really like to resolve this issue. .. I'm upgrading the box to new userspace now. But I still have the old installation drive, so perhaps I'll go there now and try this. My plan is to replace /usr/bin/ir-keytable with a script that issues the 'ulimit -c unlimited' command and then invokes the original /usr/bin/ir-keytable binary. Should take half an hour or so before I get back here again. No-go. According to the syslog, the segfault has not happened since I reconfigured the kernel and startup sequence two days ago to resolve an XFS mount issue. Something in there changed the init timing just enough to make it go away, I believe. Now I'm blowing it all away in favour of fresh userspace, with a whole new set of issues to resolve. :) Off-Topic: Ubuntu (Mythbuntu) really has a ton of timing issues with this upstart thing at startup and shutdown.. running from an SSD really exposes the flaws. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-27 01:38 AM, Dmitry Torokhov wrote: .. BTW, I wonder what package ir-keytable is coming from? Ubuntu seems to have v4l-utils at 0.8.1-2 and you say yours is 0.8.2... .. I downloaded/built/installed it from the link you gave earlier in this thread. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-27 05:30 AM, Mauro Carvalho Chehab wrote: .. 0.8.2 is the new version that was released in Jan, 25. One of the major differences is that it now installs the udev rules, with make install. Oh, and there's no make uninstall option in the Makefile, either. Where does it put those tentacles, so that I can delete them again ? On my tests here, this is working fine, with Fedora and RHEL 6, on my usual test devices, so I don't believe that the tool itself is broken, nor I think that the issue is due to the fix patch. Well, all I know is that it does NOT segfault without the patch, and now it does. At this point I should refer you back to Linus's posts earlier in this thread for the definition of breaks userspace. I remember that when Kay added a persistence utility tool that opens a V4L device in order to read some capabilities, this caused a race condition into a number of drivers that use to register the video device too early. The result is that udev were opening the device before the end of the register process, causing OOPS and other problems. I suspect that Mark may be experiencing a similar issue. Could be. I really don't know. Again, I could not care less about ir-keyboard, as I don't use it here at all. But also again, this thread isn't about what I need fixed, but rather about broken userspace from 2.6.36 onward. And the patch to fix it seems to possibly cause more breakage. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-27 11:39 AM, Dmitry Torokhov wrote: On Wed, Jan 26, 2011 at 10:18:53PM -0500, Mark Lord wrote: No, it does not seem to segfault when I unload/reload ir-kbd-i2c and then invoke it by hand with the same parameters. Quite possibly the environment is different when udev invokes it, and my strace attempt with udev killed the system, so no info there. Hmm, what about compiling with debug and getting a core then? Sure. debug is easy, -g, but you'll have to tell me how to get it do produce a core dump. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 06:26 AM, Mauro Carvalho Chehab wrote: .. However, as said previously in this thread, input-kbd won't work with any RC table that uses NEC extended (and there are several devices on the current Kernels with those tables), since it only reads up to 16 bits. ir-keytable works with all RC tables, if you use a kernel equal or upper to 2.6.36, due to the usage of the new ioctl's. Is there a way to control the key repeat rate for a device controlled by ir-kbd-i2c ? It appears to be limited to a max of between 4 and 5 repeats/sec somewhere, and I'd like to fix that. ??? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 03:29:14PM -0800, Dmitry Torokhov wrote:
On Tue, Jan 25, 2011 at 05:22:09PM -0500, Mark Lord wrote:
On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote:
Em 25-01-2011 18:54, Dmitry Torokhov escreveu:
..
That has been done as well; we have 2 new ioctls and kept 2 old ioctls.
That's the problem: you did NOT keep the two old ioctls().
Those got changed too.. so now we have four NEW ioctls(),
none of which backward compatible with userspace.
Please calm down. This, in fact, is not new vs old ioctl problem but
rather particular driver (or rather set of drivers) implementation
issue. Even if we drop the new ioctls and convert the RC code to use the
old ones you'd be observing the same breakage as RC code responds with
-EINVAL to not-yet-established mappings.
I'll see what can be done for these drivers; I guess we could supply a
fake KEY_RESERVED entry for not mapped scancodes if there are mapped
scancodes above current one. That should result in the same behavior
for RCs as before.
I wonder if the patch below is all that is needed...
Nope. Does not work here:
$ lsinput
protocol version mismatch (expected 65536, got 65537)
Input: ir-keymap - return KEY_RESERVED for unknown mappings
Do not respond with -EINVAL to EVIOCGKEYCODE for not-yet-mapped scancodes,
but rather return KEY_RESERVED.
This fixes breakage with Ubuntu's input-kbd utility that stopped returning
full keymaps for remote controls.
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/media/IR/ir-keytable.c | 28 +---
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index f60107c..c4645d7 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -374,21 +374,27 @@ static int ir_getkeycode(struct input_dev *dev,
index = ir_lookup_by_scancode(rc_tab, scancode);
}
- if (index = rc_tab-len) {
- if (!(ke-flags INPUT_KEYMAP_BY_INDEX))
- IR_dprintk(1, unknown key for scancode 0x%04x\n,
- scancode);
+ if (index rc_tab-len) {
+ entry = rc_tab-scan[index];
+
+ ke-index = index;
+ ke-keycode = entry-keycode;
+ ke-len = sizeof(entry-scancode);
+ memcpy(ke-scancode, entry-scancode, sizeof(entry-scancode));
+
+ } else if (!(ke-flags INPUT_KEYMAP_BY_INDEX)) {
+ /*
+ * We do not really know the valid range of scancodes
+ * so let's respond with KEY_RESERVED to anything we
+ * do not have mapping for [yet].
+ */
+ ke-index = index;
+ ke-keycode = KEY_RESERVED;
+ } else {
retval = -EINVAL;
goto out;
}
- entry = rc_tab-scan[index];
-
- ke-index = index;
- ke-keycode = entry-keycode;
- ke-len = sizeof(entry-scancode);
- memcpy(ke-scancode, entry-scancode, sizeof(entry-scancode));
-
retval = 0;
out:
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 01:24 PM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 03:29:09PM -0200, Mauro Carvalho Chehab wrote:
Em 26-01-2011 14:51, Dmitry Torokhov escreveu:
On Wed, Jan 26, 2011 at 12:18:29PM -0200, Mauro Carvalho Chehab wrote:
diff --git a/input.c b/input.c
index d57a31e..a9bd5e8 100644
--- a/input.c
+++ b/input.c
@@ -101,8 +101,8 @@ int device_open(int nr, int verbose)
close(fd);
return -1;
}
- if (EV_VERSION != version) {
- fprintf(stderr, protocol version mismatch (expected %d, got
%d)\n,
+ if (EV_VERSION version) {
+ fprintf(stderr, protocol version mismatch (expected = %d, got
%d)\n,
EV_VERSION, version);
Please do not do this. It causes check to float depending on the
version of kernel headers it was compiled against.
The check should be against concrete version (0x1 in this case).
The idea here is to not prevent it to load if version is 0x10001.
This is actually the only change that it is really needed (after applying
your KEY_RESERVED patch to 2.6.37) for the tool to work. Reverting it causes
the error:
You did not understand. When comparing against EV_VERSION, if you
compile on 2.6.32 you are comparing with 0x1. If you are compiling
on 2.6.37 you are comparing with 0x10001 as EV_VERSION value changes
(not the value returned by EVIOCGVERSION, the value of the _define_
itself).
The proper check is:
#define EVDEV_MIN_VERSION 0x1
if (version EVDEV_MIN_VERSION) {
fprintf(stderr,
protocol version mismatch (need at least %d, got
%d)\n,
EVDEV_MIN_VERSION, version);
...
}
Guys, NO!
The proper check is actually to remove all of that silly VERSION testing
from the userspace binary. And then have it try EVIOCGKEYCODE_V2 first.
If EVIOCGKEYCODE_V2 fails (-ENOTTY, -EINVAL, or -ENOSYS), then
have it fall back to trying to use EVIOCGKEYCODE.
Of course this does assume that the new EVIOCGKEYCODE_V2 interface uses
correct ioctl return values..
Cheers
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 02:16 PM, Gerd Hoffmann wrote: Hi, The check should be against concrete version (0x1 in this case). Stepping back: what does the version mean? 0x1 == 1.0 ? 0x10001 == 1.1 ? Can I expect the interface stay backward compatible if only the minor revision changes, i.e. makes it sense to accept 1.x? Will the major revision ever change? Does it make sense to check the version at all? As already established earlier in this thread, by Linus Torvalds as well as by myself, NO! That whole version concept is broken and inappropriate. Userspace should simply ignore it completely. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 12:59 PM, Dmitry Torokhov wrote:
On Wed, Jan 26, 2011 at 03:41:01PM -0200, Mauro Carvalho Chehab wrote:
Em 26-01-2011 12:58, Mark Lord escreveu:
On 11-01-26 06:26 AM, Mauro Carvalho Chehab wrote:
..
However, as said previously in this thread, input-kbd won't work with any
RC table that uses NEC extended (and there are several devices on the
current Kernels with those tables), since it only reads up to 16 bits.
ir-keytable works with all RC tables, if you use a kernel equal or upper to
2.6.36, due to the usage of the new ioctl's.
Is there a way to control the key repeat rate for a device
controlled by ir-kbd-i2c ?
It appears to be limited to a max of between 4 and 5 repeats/sec somewhere,
and I'd like to fix that.
It depends on what device do you have. Several I2C chips have the repeat
logic inside the I2C microcontroller PROM firmware. or at the remote
controller itself. So, there's nothing we can do to change it.
I have even one device here (I think it is a saa7134-based Kworld device)
that doesn't send any repeat event at all for most keys (I think it only
sends repeat events for volume - Can't remember the specific details anymore
-
too many devices!).
The devices that produce repeat events can be adjusted via the normal
input layer tools like kbdrate.
Unfortunately kbdrate affects all connected devices and I am not sure if
there is a utility allowing to set rate on individual devices. But here
is the main part:
static int input_set_rate(int fd,
unsigned int delay, unsigned int period)
{
unsigned int rep[2] = { delay, period };
if (ioctl(fd, EVIOCSREP, rep) 0) {
perror(evdev ioctl);
return -1;
}
return 0;
}
Okay, if that's still a global in this day and age,
then I suppose I'll just have to special-case it here in my copy.
The hardware itself is capable of much faster repeat rates,
and prior to 2.6.36 I used to patch it for intelligent ramp-up
on repeats inside ir-kbd-i2c.
As of 2.6.36 that stopped working, and is now limited somewhere
to no more than one repeat every 210msecs.
Cheers
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 11:44 AM, Dmitry Torokhov wrote: On Wed, Jan 26, 2011 at 10:05:57AM -0500, Mark Lord wrote: .. Nope. Does not work here: $ lsinput protocol version mismatch (expected 65536, got 65537) It would be much more helpful if you tried to test what has been fixed (hint: version change wasn't it). It would be much more helpful if you would revert that which was broken in 2.6.36. (hint: version was part of it). The other part does indeed appear to work with the old binary for input-kbd, but the binary for lsinput still fails as above. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 12:32 PM, Mauro Carvalho Chehab wrote: Em 26-01-2011 13:05, Mark Lord escreveu: .. Nope. Does not work here: $ lsinput protocol version mismatch (expected 65536, got 65537) You need to relax the version test at the tree. As I said before, this is a development tool from the early RC days, bound to work with one specific version of the API, and programmed by purpose to fail if there would by any updates at the Input layer. .. As I said before, I personally have done that on my copy here. But that's not what this thread is about. This thread is about broken userspace courtesy of these changes. So I am testing with the original userspace binary here, and it still fails. And will continue to fail until that regression is fixed. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 02:41 PM, Dmitry Torokhov wrote: I do not consider lsinput refusing to work a regression. Obviously, since you don't use that tool. Those of us who do use it see this as broken userspace compatibility. Who the hell reviews this crap, anyway? Code like that should never have made it upstream in the first place. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 02:50 PM, Dmitry Torokhov wrote: On Wed, Jan 26, 2011 at 02:47:18PM -0500, Mark Lord wrote: On 11-01-26 02:41 PM, Dmitry Torokhov wrote: I do not consider lsinput refusing to work a regression. Obviously, since you don't use that tool. Those of us who do use it see this as broken userspace compatibility. Who the hell reviews this crap, anyway? Code like that should never have made it upstream in the first place. You are more than welcome spend more time on reviews. Somehow I detect a totally lack of sincerity there. But thanks for fixing the worst of this regression, at least. Perhaps you might think about eventually fixing the bad use of -EINVAL in future revisions. One way perhaps to approach that, would be to begin fixing it internally, but still returning the same things from the actual f_ops-ioctl() routine. Then eventually provide new ioctl numbers which return the correct -ENOTTY (or whatever is best there), rather than converting to -EVINAL at the interface. Then a nice multi-year overlap, with a scheduled removal of the old codes some day. Then the input subsystem would work more like most other subsystems, and make userspace programming simpler and easier to get correct. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
Or perhaps get rid of that unworkable version number thing (just freeze it in time with the 2.6.35 value returned), and implement a get_feature_flags ioctl or something for going forward. Then you can just turn on new bits in the flags as new features are added. It's a kludge (to get around the poor use of -EINVAL everywhere), but at least it's a design that's workable. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 10:05 AM, Mark Lord wrote: On 11-01-25 09:00 PM, Dmitry Torokhov wrote: .. I wonder if the patch below is all that is needed... Nope. Does not work here: $ lsinput protocol version mismatch (expected 65536, got 65537) Heh.. I just noticed something *new* in the bootlogs on my system: kernel: Registered IR keymap rc-rc5-tv udevd-event[6438]: run_program: '/usr/bin/ir-keytable' abnormal exit kernel: input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input7 kernel: ir-keytable[6439]: segfault at 8 ip 004012d2 sp 7fff6d43ca60 error 4 in ir-keytable[40+7000] kernel: rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0 kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0] That's udev invoking ir-keyboard when the ir-kbd-i2c kernel module is loaded, and that is also ir-keyboard (userspace) segfaulting when run. That behaviour is new, with the proposed fix patch from this thread. So the fix itself appears to also break userspace. The ir-keyboard program reports: IR keytable control version 0.8.2 Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 08:01 PM, Mark Lord wrote: On 11-01-26 10:05 AM, Mark Lord wrote: On 11-01-25 09:00 PM, Dmitry Torokhov wrote: .. I wonder if the patch below is all that is needed... Nope. Does not work here: $ lsinput protocol version mismatch (expected 65536, got 65537) Heh.. I just noticed something *new* in the bootlogs on my system: kernel: Registered IR keymap rc-rc5-tv udevd-event[6438]: run_program: '/usr/bin/ir-keytable' abnormal exit kernel: input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input7 kernel: ir-keytable[6439]: segfault at 8 ip 004012d2 sp 7fff6d43ca60 error 4 in ir-keytable[40+7000] kernel: rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0 kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0] That's udev invoking ir-keyboard when the ir-kbd-i2c kernel module is loaded, and that is also ir-keyboard (userspace) segfaulting when run. Note: I tried to capture an strace of ir-keyboard segfaulting during boot (as above), but doing so kills the system (hangs on boot). The command from udev was: /usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-26 09:12 PM, Dmitry Torokhov wrote: On Wed, Jan 26, 2011 at 08:07:29PM -0500, Mark Lord wrote: On 11-01-26 08:01 PM, Mark Lord wrote: On 11-01-26 10:05 AM, Mark Lord wrote: On 11-01-25 09:00 PM, Dmitry Torokhov wrote: .. I wonder if the patch below is all that is needed... Nope. Does not work here: $ lsinput protocol version mismatch (expected 65536, got 65537) Heh.. I just noticed something *new* in the bootlogs on my system: kernel: Registered IR keymap rc-rc5-tv udevd-event[6438]: run_program: '/usr/bin/ir-keytable' abnormal exit kernel: input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input7 kernel: ir-keytable[6439]: segfault at 8 ip 004012d2 sp 7fff6d43ca60 error 4 in ir-keytable[40+7000] kernel: rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0 kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c driver #0] That's udev invoking ir-keyboard when the ir-kbd-i2c kernel module is loaded, and that is also ir-keyboard (userspace) segfaulting when run. Note: I tried to capture an strace of ir-keyboard segfaulting during boot (as above), but doing so kills the system (hangs on boot). The command from udev was: /usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0 Does it die when you try to invoke the command by hand? Can you see where? No, it does not seem to segfault when I unload/reload ir-kbd-i2c and then invoke it by hand with the same parameters. Quite possibly the environment is different when udev invokes it, and my strace attempt with udev killed the system, so no info there. It does NOT segfault on the stock 2.6.37 kernel, without the patch. -ml -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-25 06:42 AM, Mauro Carvalho Chehab wrote: I lost part of the thread, but a quick search via the Internet showed that you're using the input tools to work with a Remote Controller, right? Are you using a vanilla kernel, or are you using the media_build backports? There are some distros that are using those backports also like Fedora 14. I use kernel.org kernels exclusively. The issue is simple, and it is related on how the input.c used to handle EVIOSGKEYCODE. Basically, before allowing you to change a key, it used to call EVIOCGKEYCODE to check it that key exists. However, when you're creating a new association, the key didn't exist, and, to be strict with input rules, EVIOCGKEYCODE should return -EINVAL. No, if the parameters are a valid key, then -EINVAL is never the correct thing for a kernel to return. -EINVAL means bad parameters, and that's not an accurate description of a valid yet unmapped key. To circumvent that behaviour, old versions were returning 0, and associating unmapped scancodes to KEY_RESERVED. We used this workaround for a few kernel versions, while we were discussing the improvements so support larger scancodes. And now we're stuck with it. If that is how it works, and userspace depends upon it (it does), then consider it cast in stone. Immutable by Linus's Law: don't break userspace. Create a new ioctl() number for the new behaviour, but preserve the old behaviour in exact form for a suitable (multi-year) overlap period. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?
On 11-01-25 05:00 PM, Mauro Carvalho Chehab wrote: Em 25-01-2011 18:54, Dmitry Torokhov escreveu: On Wed, Jan 26, 2011 at 06:09:45AM +1000, Linus Torvalds wrote: On Wed, Jan 26, 2011 at 2:48 AM, Dmitry Torokhov dmitry.torok...@gmail.com wrote: We should be able to handle the case where scancode is valid even though it might be unmapped yet. This is regardless of what version of EVIOCGKEYCODE we use, 1 or 2, and whether it is sparse keymap or not. Is it possible to validate the scancode by driver? More appropriately, why not just revert the thing? The version change Reverting the version increment is a bad thing. I agree with Dmitry that an application that fails just because the API version were incremented is buggy. Well, then we'll break Ubuntu again as they recompiled their input-utils package (without fixing the check). And the rest of distros do not seem to be using that package... Reverting it will also break the ir-keytable userspace program that it is meant to be used by the Remote Controller devices, and uses it to adjust its behaviour to support RC's with more than 16 bits of scancodes. I agree that it is bad that the ABI broke, but reverting it will cause even more damage. There we disagree. Sure it's a very poorly thought out interface, but the way to fix it is to put a new one along side the old, and put the old back the way it was before it got broken. I'm not making a fuss here for myself -- I'm more than capable of working around new kernel bugs like these, but for every person like me there are likely hundreds of others who simply get frustrated and give up. If you're worried about Ubuntu's adaptation to the buggy regression, then email their developers (kernel and input-utils packagers) explaining the revert, and they can coordination their kernel and input-utils updates to do the Right Thing. But for all of the rest of us, our systems are broken by this change. ... As Mark said, breaking user space simply isn't acceptable. And since breaking user space isn't acceptable, then incrementing the version is stupid too. It might not have been the best idea to increment, however I maintain that if there exists version is can be changed. Otherwise there is no point in having version at all. Not arguing in favor of the version numbering, but it is easy to read the version increment at the beginning of the application, and adjust if the code will use EVIOCGKEYCODE or EVIOCGKEYCODE_V2 of the ioctl's, depending on what kernel provides. Ok, we might be just calling the new ioctl and check for -ENOSYS at the beginning, using some fake arguments. As I said, reverting the version bump will cause yet another wave of breakages so I propose leaving version as is. The way we add new ioctl's is not by incrementing some ABI version crap. It's by adding new ioctl's or system calls or whatever that simply used to return -ENOSYS or other error before, while preserving the old ABI. That way old binaries don't break (for _ANY_ reason), and new binaries can see oh, this doesn't support the new thing. That has been done as well; we have 2 new ioctls and kept 2 old ioctls. That's the problem: you did NOT keep the two old ioctls(). Those got changed too.. so now we have four NEW ioctls(), none of which backward compatible with userspace. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 17/04/10 12:43 AM, Andy Walls wrote: I had to disassemble and study some of the microcontorller firmware, and then reread some documents, to figure out how all the audio detection resets must work. I've just pushed some microcontroller reset related changes to the cx18-audio2 repo. Please test and see if things are better or worse. .. Mmm.. something is not right -- the audio is failing constantly with that change. Perhaps if I could dump out the registers, we might see what is wrong. I also tried: v4l2-dbg -d /dev/video1 -c type=host,chip=1 --list-registers=min=0x800,max=0x9ff but that fails to read any of the registers (ioctl: VIDIOC_DBG_G_REGISTER failed for 0xXXX). I think I'll patch the driver to dump them for us. Thank-you for your work on this. There are many of us here hoping that we can figure out and fix whatever is wrong with our cards. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 16/04/10 08:59 AM, Andy Walls wrote: .. Accesses to those are orthognal to the rest of the cx18 driver, including the IRQ handler. (I agree, its hard to follow things in the driver; it's very large.) Do note, however, that the audio standard detection microcontroller *does* write to the registers in 0x800-0x9ff *independent* of the linux cx18 driver. Locking with respect to the microcontroller would mean halting and restarting the microcontroller. I don't know if that causes it to reset or not, and I do not know how it affects it's internal timers. .. Since the problem really does behave like a race condition would behave, I wonder if it could have something to do with how/when we modify any of those registers which are shared with the microcontroller? The cx18 driver *always* does read-modify-write (RMW) of 32-bits at at time, even when just an 8-bit register is being modified. If the microcontroller is using/updating the other 24-bits of any of those registers, then the cx18 driver's RMW will destroy values that the microcontroller has written. Is it possible to write only 8-bits, rather than having to do the RMW on 32-bits ? Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 17/04/10 08:09 AM, Mark Lord wrote: .. Mmm.. something is not right -- the audio is failing constantly with that change. Perhaps if I could dump out the registers, we might see what is wrong. .. When the microcontroller is reset, does it put all settings back to defaults? I wonder if this causes it to select a different audio input, as part of the reset? If so, then we'll need to reselect the tuner-audio afterward. Anything else? ?? -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 15/04/10 01:16 AM, Mark Lord wrote: for now, I've added lower level spinlock protection onto all register writes, .. As you expected, this doesn't seem to have cured anything obvious. :) I had Mythtv wakeup/record/powerdown several times overnight, and it still required fallbacks for about half of those. And.. one of the fallback recordings still had muted audio. Even though my script which checks for that reported audio ok. Enough for now.. I'll hack some more on the weekend. cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 14/04/10 12:32 AM, Mark Lord wrote: .. The syslog shows the usual fallback messages, but the audio consisted of very loud static, the kind of noise one gets when the sample bits are all reversed. While it was failing, I tried retuning, stopping/starting the recording, etc.. nothing mattered. It wanted a reload of the cx18 driver to cure it. .. Since all of this happens rather randomly, I'm beginning to more strongly suspect a race condition somewhere in the driver. Now, it's a rather large driver -- lots of complexity in that chip -- so it will take me a while to sort through things. But at first blush, I don't see any obvious locking around the various read-modify-write sequences for the audio registers. And a quick grep spin *.[ch] shows a few spin_lock/spin_unlock calls in cx18-queue.c and cx18-stream.c (as well as the alsa code, which shouldn't be in play in this scenario). Oddly, none of those spinlocks use _irq or _irq_save/restore, which means they aren't providing any sort of mutual exclusion against the interrupt handler. But like I said, I'm only just beginning to look more closely now. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 15/04/10 12:46 AM, Andy Walls wrote: On Wed, 2010-04-14 at 18:26 -0400, Mark Lord wrote: .. Oddly, none of those spinlocks use _irq or _irq_save/restore, which means they aren't providing any sort of mutual exclusion against the interrupt handler. There is no need. The hard irq handler only really deals with firmware mailbox ack and firmware mailbox ready notifications. It sucks off the mailbox contents and shoves it over to the cx18-NN-in workhandler via work orders placed on a workqueue. The work handler does grab the spinlocks, but it is from a non-irq context. .. Mmmm.. but it does do read-modify-write on several registers inside the IRQ handling. I suppose those might be safe groups, written to _only_ by the IRQ handler, but maybe not. From what I can see, (nearly?) all registers are read/written as full 32-bit units. So when code wants to modify an 8-bit register, this is converted into a read- modify-write of the corresponding 32-bit register. So if two threads, or any thread and the irq handler, want to modify parts of the same 32-bit register, then there's a race. The code _appears_ to mostly not have such a problem, but it would conveniently explain the sporadic failures. :) So, for now, I've added lower level spinlock protection onto all register writes, as well as to routines that themselves do a higher level read-modify-write: eg. the routines to enable/disable specific IRQ sources. This was easy enough to do, and it'll give us confidence that the r-m-w sequences are not the issue. Or perhaps it'll cure some problems. Time will tell. I'll run with that patch on top of yours for the next couple of days, or until I see a fallback log again. None so far, though. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 13/04/10 06:35 AM, Andy Walls wrote: On Mon, 2010-04-12 at 22:34 -0400, Mark Lord wrote: .. As soon as I quit from LiveTV, the next recording still needed a new fallback. So the chip is still in some weird state where auto-audio will continue to fail until I reload the module. .. The *only* other thing I can think of, that I have control over, is the PLL charge pump current in the analog tuner. Right now it is set to low current to minimize phase noise when tuned to a channel. Perhaps setting the PLL charge pump to high current while chaning the channel to get a faster lock, and low current after a short time, will help get a good SIF output from the analog tuner assembly sooner. Perhaps when I have time .. What's weird, is that things work most of the time. But as soon as one fallback is needed, the chip then fails continuously afterward, requiring fallback after fallback. Until the driver is reloaded. So to me, that suggests that perhaps some register has gotten corrupted, or some part of the chip has gone wanky. Perhaps if the driver could re-init more of the chip when tuning, which might correct whatever bits/state happen to need fixing? I might have a look later, and see if there are any obvious registers that perhaps I could have it dump out prior to doing the fallback, and then compare that state with a good tuning state. Or something. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 13/04/10 09:45 PM, Andy Walls wrote: .. # v4l2-dbg -d /dev/video0 -c host1 --list-registers=min=0x800,max=0x9ff Keep in mind that some of these registers aren't settable and only read out the state of various hardware blocks and functions. Dumping the state of the microcontroller memory could also be done, but I'd have to modify the driver to do it. cx18-av-firmware.c:cx18_av_verifyfw() has code that's really close to doing that. .. Thanks. I'll have a go at that some night. Meanwhile, tonight, audio failed. The syslog shows the usual fallback messages, but the audio consisted of very loud static, the kind of noise one gets when the sample bits are all reversed. While it was failing, I tried retuning, stopping/starting the recording, etc.. nothing mattered. It wanted a reload of the cx18 driver to cure it. If needed, once we're in a forced mode, we could stop the microcontroller, reload all of the microcontroller firmware, and restart it. Kind of heavy handed, but it may work. .. Perhaps that's what is needed here. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 14/04/10 12:32 AM, Mark Lord wrote: .. Thanks. I'll have a go at that some night. Meanwhile, tonight, audio failed. .. Oh, I forgot to include this: Apr 13 22:00:05 duke kernel: cx18-0: = START STATUS CARD #0 = Apr 13 22:00:05 duke kernel: cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600 Apr 13 22:00:05 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579 Apr 13 22:00:05 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03 Apr 13 22:00:05 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43) Apr 13 22:00:05 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08) Apr 13 22:00:05 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38) Apr 13 22:00:05 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31) Apr 13 22:00:05 duke kernel: tveeprom 1-0050: has radio Apr 13 22:00:05 duke kernel: cx18-0 843: Video signal: present Apr 13 22:00:05 duke kernel: cx18-0 843: Detected format: NTSC-M Apr 13 22:00:05 duke kernel: cx18-0 843: Specified standard:NTSC-M Apr 13 22:00:05 duke kernel: cx18-0 843: Specified video input: Composite 7 Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audioclock freq: 48000 Hz Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio mode: forced mode Apr 13 22:00:05 duke kernel: cx18-0 843: Detected audio standard: forced audio standard Apr 13 22:00:05 duke kernel: cx18-0 843: Audio muted: no Apr 13 22:00:05 duke kernel: cx18-0 843: Audio microcontroller: running Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio standard: BTSC Apr 13 22:00:05 duke kernel: cx18-0 843: Configured audio mode: MONO2 (LANGUAGE B) Apr 13 22:00:05 duke kernel: cx18-0 843: Specified audio input: Tuner (In8) Apr 13 22:00:05 duke kernel: cx18-0 843: Preferred audio mode: stereo Apr 13 22:00:05 duke kernel: cx18-0 gpio-reset-ctrl: GPIO: direction 0x3001, value 0x3001 Apr 13 22:00:05 duke kernel: tda9887 2-0043: Data bytes: b=0x14 c=0x30 e=0x44 Apr 13 22:00:05 duke kernel: tuner 2-0061: Tuner mode: analog TV Apr 13 22:00:05 duke kernel: tuner 2-0061: Frequency: 531.25 MHz Apr 13 22:00:05 duke kernel: tuner 2-0061: Standard:0xb000 Apr 13 22:00:05 duke kernel: cs5345 1-004c: Input: 1 Apr 13 22:00:05 duke kernel: cs5345 1-004c: Volume: 0 dB Apr 13 22:00:05 duke kernel: cx18-0: Video Input: Tuner 1 Apr 13 22:00:05 duke kernel: cx18-0: Audio Input: Tuner 1 Apr 13 22:00:05 duke kernel: cx18-0: GPIO: direction 0x3001, value 0x3001 Apr 13 22:00:05 duke kernel: cx18-0: Tuner: TV Apr 13 22:00:05 duke kernel: cx18-0: Stream: MPEG-2 Program Stream Apr 13 22:00:05 duke kernel: cx18-0: VBI Format: Private packet, IVTV format Apr 13 22:00:05 duke kernel: cx18-0: Video: 720x480, 30 fps Apr 13 22:00:05 duke kernel: cx18-0: Video: MPEG-2, 4x3, Variable Bitrate, 1200, Peak 1450 Apr 13 22:00:05 duke kernel: cx18-0: Video: GOP Size 15, 2 B-Frames, GOP Closure Apr 13 22:00:05 duke kernel: cx18-0: Audio: 48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No Emphasis, No CRC Apr 13 22:00:05 duke kernel: cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D Horizontal, 0 Apr 13 22:00:05 duke kernel: cx18-0: Temporal Filter: Manual, 8 Apr 13 22:00:05 duke kernel: cx18-0: Median Filter: Off, Luma [0, 255], Chroma [0, 255] Apr 13 22:00:05 duke kernel: cx18-0: Status flags: 0x0021 Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder MPEG: status 0x0118, 0% of 2048 KiB (64 buffers) in use Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder YUV: status 0x, 0% of 2025 KiB (20 buffers) in use Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder VBI: status 0x0038, 5% of 1015 KiB (20 buffers) in use Apr 13 22:00:05 duke kernel: cx18-0: Stream encoder PCM audio: status 0x, 0% of 1024 KiB (256 buffers) in use Apr 13 22:00:05 duke kernel: cx18-0: Read MPEG/VBI: 190420992/476784 bytes Apr 13 22:00:05 duke kernel: cx18-0: == END STATUS CARD #0 == -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 11/04/10 03:01 PM, Andy Walls wrote: I would be interested in hearing how frequent these patches show forced audio standard for you: .. The MythTV box here has many tuners, most of which are not used every power-up. But mythbackend _always_ initializes all tuners, and pre-tunes them to their startup channel each time the system boots up to record/play something. So.. in the logs from the other night, there are some fallback messages. But since the HVR1600 was not actually used to record anything, I don't know for sure if the audio fallback actually worked, other than that v4l-ctl reported non-muted audio afterwards. The abridged syslog is below. Something I find interesting, is that it reported having to fallback twice on this boot (once during the initial anti-stutter tune, and again when mythbackend started up). I wonder if this means that once the audio bug is present, it remains present until the next time the driver is loaded/unloaded. Which matches previous observations. The fallback (hopefully) works around this, but there's still a bug somewhere that is preventing the audio from working without the fallback. Cheers Mark Lord * * * * Apr 12 03:56:55 duke kernel: cx18: Start initialization, version 1.4.0 Apr 12 03:56:55 duke kernel: cx18-0: Initializing card 0 Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge card Apr 12 03:56:55 duke kernel: cx18 :05:03.0: PCI INT A - GSI 18 (level, low) - IRQ 18 Apr 12 03:56:55 duke kernel: cx18-0: Unreasonably low latency timer, setting to 64 (was 2) Apr 12 03:56:55 duke kernel: cx18-0: cx23418 revision 0101 (B) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: Hauppauge model 74551, rev C1A3, serial# 1752579 Apr 12 03:56:55 duke kernel: tveeprom 1-0050: MAC address is 00:0d:fe:1a:be:03 Apr 12 03:56:55 duke kernel: tveeprom 1-0050: tuner model is TCL MFNM05-4 (idx 103, type 43) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: audio processor is CX23418 (idx 38) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: decoder processor is CX23418 (idx 31) Apr 12 03:56:55 duke kernel: tveeprom 1-0050: has radio Apr 12 03:56:55 duke kernel: cx18-0: Autodetected Hauppauge HVR-1600 Apr 12 03:56:55 duke kernel: cx18-0: Simultaneous Digital and Analog TV capture supported Apr 12 03:56:55 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs Apr 12 03:56:55 duke kernel: tuner 2-0043: chip found @ 0x86 (cx18 i2c driver #0-1) Apr 12 03:56:55 duke kernel: tda9887 2-0043: creating new instance Apr 12 03:56:55 duke kernel: tda9887 2-0043: tda988[5/6/7] found Apr 12 03:56:55 duke kernel: tuner 2-0061: chip found @ 0xc2 (cx18 i2c driver #0-1) Apr 12 03:56:55 duke kernel: cs5345 1-004c: chip found @ 0x98 (cx18 i2c driver #0-0) Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: creating new instance Apr 12 03:56:55 duke kernel: tuner-simple 2-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F)) Apr 12 03:56:55 duke kernel: cx18-0: Registered device video1 for encoder MPEG (64 x 32.00 kB) Apr 12 03:56:55 duke kernel: DVB: registering new adapter (cx18) Apr 12 03:56:55 duke kernel: MXL5005S: Attached at address 0x63 Apr 12 03:56:55 duke kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)... Apr 12 03:56:55 duke kernel: cx18-0: DVB Frontend registered Apr 12 03:56:55 duke kernel: cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB) Apr 12 03:56:55 duke kernel: cx18-0: Registered device video33 for encoder YUV (20 x 101.25 kB) Apr 12 03:56:55 duke kernel: cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes) Apr 12 03:56:55 duke kernel: cx18-0: Registered device video25 for encoder PCM audio (256 x 4.00 kB) Apr 12 03:56:55 duke kernel: cx18-0: Registered device radio1 for encoder radio Apr 12 03:56:55 duke kernel: cx18-0: Initialized card: Hauppauge HVR-1600 Apr 12 03:56:55 duke kernel: cx18: End initialization Apr 12 03:56:58 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-cpu.fw Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes) Apr 12 03:56:58 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-apu.fw Apr 12 03:56:58 duke kernel: cx18-0: loaded v4l-cx23418-apu.fw firmware V0012 (141200 bytes) Apr 12 03:56:58 duke kernel: cx18-0: FW version: 0.0.74.0 (Release 2007/03/12) Apr 12 03:56:58 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-cpu.fw Apr 12 03:56:59 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-apu.fw Apr 12 03:56:59 duke kernel: cx18 :05:03.0: firmware: requesting v4l-cx23418-dig.fw Apr 12 03:56:59 duke kernel: cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes) Apr 12 03:56:59 duke kernel: cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes) Apr 12 03:57:00 duke kernel: ivtv :05:02.0: firmware: requesting v4l-cx2341x-enc.fw Apr 12 03
Re: cx18: missing audio for analog recordings
On 12/04/10 05:17 PM, Andy Walls wrote: On Mon, 2010-04-12 at 16:08 -0400, Mark Lord wrote: .. I wonder if this means that once the audio bug is present, it remains present until the next time the driver is loaded/unloaded. Which matches previous observations. The fallback (hopefully) works around this, but there's still a bug somewhere that is preventing the audio from working without the fallback. .. Okay, the fallback works -- recordings made with it do have good audio. And.. my hypothesis appears to be true thus far: once the audio fails, requiring the fallback, it stays failed until the driver is reloaded. Every subsequent recording made (after a fallback) also experiences the fallback. This is with a good channel, with good audio. Subsequent recordings using the exact same channel. Weird, eh. I wonder how to discover the real cause? Good workaround, though! Thanks. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 12/04/10 10:22 PM, Mark Lord wrote: .. Okay, the fallback works -- recordings made with it do have good audio. And.. my hypothesis appears to be true thus far: once the audio fails, requiring the fallback, it stays failed until the driver is reloaded. Every subsequent recording made (after a fallback) also experiences the fallback. This is with a good channel, with good audio. Subsequent recordings using the exact same channel. .. Mmm.. further to that: the problem went away as soon as I told it to tune to a different channel. No more fallbacks (for now). It can now even retune the original channel without fallbacks. So.. tuning to a new channel appears to fix whatever the bad state was that was triggering the fallbacks. Based on my sample of one, anyway. ;) Now that it is behaving again, I cannot poke further until the next time I'm lucky enough to be around when it fails. Weird, eh. I wonder how to discover the real cause? Good workaround, though! Thanks. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 12/04/10 10:30 PM, Mark Lord wrote: .. Mmm.. further to that: the problem went away as soon as I told it to tune to a different channel. No more fallbacks (for now). It can now even retune the original channel without fallbacks. So.. tuning to a new channel appears to fix whatever the bad state was that was triggering the fallbacks. Based on my sample of one, anyway. ;) .. Nope.. what that second email should have said, was Changing channels in LiveTV, no fallbacks required because the audio is already working from the initial fallback. As soon as I quit from LiveTV, the next recording still needed a new fallback. So the chip is still in some weird state where auto-audio will continue to fail until I reload the module. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 11/04/10 07:47 AM, Andy Walls wrote: On Sun, 2010-04-11 at 00:56 -0400, Andy Walls wrote: Try this: http://linuxtv.org/hg/~awalls/cx18-audio2 this waits 1.5 seconds after an input/channel change to see if the audio standard micrcontroller can detect the standard. If it can't, the driver tells it to try a fallback detection. Right now, only the NTSC-M fallback detection is set to force a mode (i.e. BTSC), all the others fall back to their same auto-detection. Some annoyances with the fallback to a forced audio standard, mode, and format: 1. Static gets unmuted on stations with no signal. :( 2. I can't seem to force mode MONO2 (LANGUAGE B). I'm guessing the microcontroller keeps setting it back down to MONO1 (LANGUAGE A/Mono L +R channel for BTSC, EIAJ, A2) Feel free to experiment with the LSB of the fallback setting magic number (0x1101) in cx18-av-core.c:input_change(). I fixed #2. I had a bug so the first patch didn't properly set the fallback audio mode. I still need to fixup cx18_av_s_tuner() and cx18_av_g_tuner() to take into consideration that we might be using a forced audio mode vs. auto detection. However, that is not essential for testing; this should be good enough for testing. .. Those new patches don't want to coexist with the earlier hard/soft reset changes. There's always a chance that *both* things might be needed, and the reset stuff didn't look obviously bad. Why dropped? Thanks -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 11/04/10 03:01 PM, Andy Walls wrote: .. I can always throw the other reset patches back in I guess, but this latest patch set should dominate the behavior of the microcontroller (if I didn't miss something because I was tired). I would be interested in hearing how frequent these patches show forced audio standard for you: .. Thanks. Will do. I've added a printk() to the fallback path, so that it will show up in the syslog whenever the fallback is used. So far, no problem. But prior to now, the HVR-1600 regularly failed about once every 2-3 days according to the script I have which tests for the issue. On a similar note, while checking the logs last evening, I discovered that the muted episode of Survivor Heros Villians (two weeks ago) was actually recorded on the _PVR-250_ card. With no audio. This has happened before, though rarely -- perhaps once every 3-6 months or so. I wonder if a similar fix/workaround could be appropriate for that card as well? In the mean while, I guess I'll update my scripts to test/report for that one as well as the cx18/hvr1600. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: missing audio for analog recordings
On 15/03/10 07:51 AM, Andy Walls wrote:
On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
On 03/02/10 07:40, Andy Walls wrote:
..
after updating to the tip of the v4l2-dvb git tree last week,
I've been hitting the no audio on analog recordings bug much more often.
Digging through google, it appears this problem has been around as long
as the cx18 driver has existed, with no clear resolution. Lots of people
have reported it to you before, and nobody has found a silver bullet fix.
..
Here are all the potential problem areas I can think of:
1. A/V digitizer/decoder audio detection firmware load and init. (I've
added firmware readback verification to try and head this off.)
2. A/V digitizer decoder audio microcontroller hard reset and soft
reset sequencing. (I think the cx18 driver has this wrong ATM.)
3. APU load and init. (The double load is to fix a DTV TS stream bug on
every other APU CPU firmware load sequence. The APU_AI_RESET is to
fix the audio bitrate problem on first capture after a double firmware
load.)
4. AI1 Mux setting failing when switching between the internal A/V
decoder's I2S output and the external I2S inputs. (I thought I had this
fixed, but I don't have detailed register specs for that register - so
maybe not.)
5. A/V decoder audio clock PLL stops operating due to being programmed
out of range. (This was a problem for 32 ksps audio a while ago, but
I'm pretty confident I have it fixed.)
6. A/V decoder analog frontend setup for SIF wrong?. (I fixed this due
to a problen Helen Buus reported with cable TV.)
I think #2 is the real problem. I just started to disassmble the
digitizer firmware 2 nights ago to see if I could get some insight as to
how to properly reset it.
I've got a first WAG at fixing the resets of the audio microcontroller's
resets at:
http://linuxtv.org/hg/~awalls/cx18-audio
If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
from 0x810 to 0x9cc, although that may not work either.
..
Thanks for the troubleshooting and reporting.
..
Back at this again today, after a month away from it -- getting tired
of watching Survivor with closed-captioning instead of audio. :)
I pulled your (Andy) repository today, and merged the cx18 audio reset
changes from it into today's tip from v4l-dvb. Patch attached for reference.
So far, so good. I'll keep tabs on it over time, and see if the audio
is stable, or if it still fails once in a while.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--- v4l-dvb-7c0b887911cf/linux/drivers/media/video/cx18/cx18-av-audio.c
2010-04-05 22:56:43.0 -0400
+++ patched/linux/drivers/media/video/cx18/cx18-av-audio.c 2010-03-13
22:06:55.0 -0500
@@ -305,14 +305,14 @@
struct cx18_av_state *state = cx-av_state;
u8 v;
+ /* assert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) | 0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
+
/* stop microcontroller */
v = cx18_av_read(cx, 0x803) ~0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
- /* assert soft reset */
- v = cx18_av_read(cx, 0x810) | 0x01;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
-
/* Mute everything to prevent the PFFT! */
cx18_av_write(cx, 0x8d3, 0x1f);
@@ -330,16 +330,17 @@
set_audclk_freq(cx, state-audclk_freq);
- /* deassert soft reset */
- v = cx18_av_read(cx, 0x810) ~0x01;
- cx18_av_write_expect(cx, 0x810, v, v, 0x0f);
-
if (state-aud_input CX18_AV_AUDIO_SERIAL2) {
+ /* start microcontroller */
/* When the microcontroller detects the
* audio format, it will unmute the lines */
v = cx18_av_read(cx, 0x803) | 0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
}
+
+ /* deassert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) ~0x01;
+ cx18_av_write_expect(cx, CXADEC_AUDIO_SOFT_RESET, v, v, 0x0f);
}
static int get_volume(struct cx18 *cx)
@@ -449,12 +450,13 @@
* changes to the mute register. */
v = cx18_av_read(cx, 0x803);
if (mute) {
- /* disable microcontroller */
+ /* stop microcontroller */
v = ~0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
+ /* mute all of Path 1 */
cx18_av_write(cx, 0x8d3, 0x1f);
} else {
- /* enable microcontroller */
+ /* start microcontroller */
v |= 0x10;
cx18_av_write_expect(cx, 0x803, v, v, 0x1f);
}
@@ -471,22 +473,29 @@
int retval;
u8 v;
+ /* assert soft reset */
+ v = cx18_av_read(cx, CXADEC_AUDIO_SOFT_RESET) | 0x1
Re: cx18: missing audio for analog recordings
On 10/04/10 06:54 PM, Andy Walls wrote: Hmmm. Darren's having problems (loss of video/black screen) with my patches under my cx18-audio repo, but I'm not quite convinced he doesn't have some other PCI bus problem either. Anyway, my plan now is this: 1. on cx18-av-core.c:input_change() a. set register 0x808 for audio autodetection b. restart the format detection loop c. set or reset a 1.5 second timeout 2. after the timer expires, if no audio standard was detected, a. force the audio standard by programming register 0x808 (e.g. BTSC for NTSC-M) b. restart the format detection loop so the micrcontroller will do the unmute when it detects audio Darren is in NTSC-M/BTSC land. What TV standard are you dealing with? .. I'm in Canada, using the tuner for over-the-air NTSC broadcasts. Cheers! -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cx18: missing audio for analog recordings
On 03/02/10 07:40, Andy Walls wrote: Again, maybe dynamically allocating these work order objects from the kernel as needed, would be better from a small dynamically allocated pool for each card. I was concerned that the interrupt handler was taking to long at the time I implemented the things the way they are now. .. I haven't seen that particular issue again, with or without increasing the work orders, so hopefully it won't recur. But after updating to the tip of the v4l2-dvb git tree last week, I've been hitting the no audio on analog recordings bug much more often. Digging through google, it appears this problem has been around as long as the cx18 driver has existed, with no clear resolution. Lots of people have reported it to you before, and nobody has found a silver bullet fix. The problem is still there. I have now spent a good many hours trying to isolate *when* it happens, and have narrowed it down to module initialization. Basically, if the audio is working after modprobe cx18, it then continues to work from recording to recording until the next reboot. If the audio is not working after modprobe, then simply doing rmmod/modprobe in a loop (until working audio is achieved) is enough to cure it. So for my Mythtv box here, I now have a script to check for missing audio and do the rmmod/modprobe. This is a good, effective workaround. http://rtr.ca/hvr1600/fix_hvr1600_audio.sh That's a link to my script. As for the actual underlying cause/bug, it's still not clear what is happening. But the problem is a LOT more prevalent (for me, and for two other people I know) with versions of the cx18 driver since spring 2009. My suspicion is that the firmware download for the APU is somehow being corrupted, and now that the driver downloads the firmware *twice* during init, it doubles the odds of said corruption. Just a theory, but it's the best fit so far. I think we have some nasty i2c issues somewhere in the kernel. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: Unable to find blank work order form to schedule incoming mailbox ...
On 03/02/10 07:40, Andy Walls wrote: .. 3. The work handler kernel thread, cx18-0-in, got killed, if that's possible, or the processor it was running on got really bogged down. .. .. One thing from the /var/log/messages output: 12:55:59 duke kernel: IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs Which is a result of the code doing this: retval = request_irq(cx-pci_dev-irq, cx18_irq_handler, IRQF_SHARED | IRQF_DISABLED, cx-v4l2_dev.name, (void *)cx); I'm not at the MythTV box right now, but it is likely that this IRQ really is shared with other devices. Does the driver *really* rely upon IRQF_DISABLED (to avoid races in the handler)? If so, then this could be a good clue. If not, then that IRQF_DISABLED should get nuked. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx18: Unable to find blank work order form to schedule incoming mailbox ...
On 03/01/10 20:34, Andy Walls wrote: On Mon, 2010-03-01 at 11:07 -0500, Mark Lord wrote: I'm using MythTV-0.21-fixes (from svn) on top of Linux-2.6.33 (from kernel.org), with an HVR-1600 tuner card. This card usually works okay (with workarounds for the known analog recording bugs) in both analog and digital modes. Last night, for the first time ever, MythTV chose to record from both the analog and digital sides of the HVR-1600 card at exactly the same times.. The kernel driver failed, and neither recording was successful. The only message in /var/log/messages was: Feb 28 19:59:45 duke kernel: cx18-0: Unable to find blank work order form to schedule incoming mailbox command processing This is really odd. It means: 1. Your machine had a very busy burst of cx18 driver buffer handling activity. Stopping a number of different streams, MPEG, VBI, and (DTV) TS at nearly the same time could do it 2. The firmware locked up. 3. The work handler kernel thread, cx18-0-in, got killed, if that's possible, or the processor it was running on got really bogged down. .. Yeah, it was pretty strange. I wonder.. the system also has a Hauppauge 950Q USB tuner, which is also partially controlled by the cx18 driver (I think). I wonder if perhaps that had anything to do with it? If you want to make the problem just go away then up this parameter in cx18-driver.h: #define CX18_MAX_IN_WORK_ORDERS (CX18_MAX_FW_MDLS_PER_STREAM + 7) to something like #define CX18_MAX_IN_WORK_ORDERS (2*CX18_MAX_FW_MDLS_PER_STREAM + 7) .. Heh.. Yup, that's the first thing I did after looking at the code. :) Dunno if it'll help or not, but easy enough to do. And if the cx18 is indeed being used by two cards (HVR-1600 and HVR-950Q), then perhaps that number does need to be bigger or dynamic (?). I've since tried to reproduce the failure on purpose, with no luck to date. Thanks guys! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: On Sun, Jul 19, 2009 at 9:57 PM, Mark Lordl...@rtr.ca wrote: .. One additional thing I noticed here, is that when tuning analog for the first time, the firmware is reloaded yet again.. even though it has already been loaded once for digital operation. Perhaps the extra 6-7second delay here is contributing to Myth's problems. That theory would be very easy to check. Just modprobe xc5000 with no_poweroff=1, load up under digital mode, and then try analog mode and see if you hit the segfault. .. I tried that today, and it didn't fix anything. Oh well. :) -- To unsubscribe from this list: send the line unsubscribe linux-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/3] ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type
Jean Delvare wrote: Hi Mark, On Sun, 19 Jul 2009 08:52:09 -0400, Mark Lord wrote: While you folks are looking into ir-kbd-i2c, perhaps one of you will fix the regressions introduced in 2.6.31-* ? The drive no longer detects/works with the I/R port on the Hauppauge PVR-250 cards, which is a user-visible regression. This is bad. If there a bugzilla entry? If not, where can I read more details / get in touch with an affected user? .. I imagine there will be thousands of affected users once the kernel is released, but for now I'll volunteer as a guinea-pig. It is difficult to test with 2.6.31 on the system at present, though, because that kernel also breaks other things that the MythTV box relies on, and the system is in regular use as our only PVR. Right now, all I know is, that the PVR-250 IR port did not show up in /dev/input/ with 2.6.31 after loading ir_kbd_i2c. But it does show up there with all previous kernels going back to the 2.6.1x days. So, to keep the pain level reasonable, perhaps you could send some debugging patches, and I'll apply those, reconfigure the machine for 2.6.31 again, and collect some output for you. And also perhaps try a few things locally as well to speed up the process. Okay? Thanks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin, Thanks for your good efforts and updates on the xc5000 driver. But the version in 2.6.31 no longer works with mythfrontend from the 0.21-fixes branch of MythTV. The mythbackend (recording) program tunes/records fine with it, but any attempt to watch Live TV via mythfrontend just locks up the UI for 30 seconds or so, and then it reverts to the menus. I find that rather odd, as mythfrontend normally has very little interaction with the tuner devices. But it does try to read the signal strength and quality from the tuner, so perhaps this is a clue as to what has gone wrong? I also took just the xc5000.[ch] files from 2.6.31 and tried them with 2.6.30, to help isolate things. Exactly the same behaviour was observed there, too. The mythbackend could tune/record, but the mythfrontend would lock up. ??? -- To unsubscribe from this list: send the line unsubscribe linux-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/3] ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type
Mark Lord wrote: Jean Delvare wrote: Hi Mark, On Sun, 19 Jul 2009 08:52:09 -0400, Mark Lord wrote: While you folks are looking into ir-kbd-i2c, perhaps one of you will fix the regressions introduced in 2.6.31-* ? The drive no longer detects/works with the I/R port on the Hauppauge PVR-250 cards, which is a user-visible regression. This is bad. If there a bugzilla entry? If not, where can I read more details / get in touch with an affected user? .. I imagine there will be thousands of affected users once the kernel is released, but for now I'll volunteer as a guinea-pig. It is difficult to test with 2.6.31 on the system at present, though, because that kernel also breaks other things that the MythTV box relies on, and the system is in regular use as our only PVR. Right now, all I know is, that the PVR-250 IR port did not show up in /dev/input/ with 2.6.31 after loading ir_kbd_i2c. But it does show up there with all previous kernels going back to the 2.6.1x days. .. Actually, I meant to say that it does not show up in the output from the lsinput command, whereas it did show up there in all previous kernels. So, to keep the pain level reasonable, perhaps you could send some debugging patches, and I'll apply those, reconfigure the machine for 2.6.31 again, and collect some output for you. And also perhaps try a few things locally as well to speed up the process. Okay? Thanks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type
Mark Lord wrote: Mark Lord wrote: Jean Delvare wrote: Hi Mark, On Sun, 19 Jul 2009 08:52:09 -0400, Mark Lord wrote: While you folks are looking into ir-kbd-i2c, perhaps one of you will fix the regressions introduced in 2.6.31-* ? The drive no longer detects/works with the I/R port on the Hauppauge PVR-250 cards, which is a user-visible regression. This is bad. If there a bugzilla entry? If not, where can I read more details / get in touch with an affected user? .. I imagine there will be thousands of affected users once the kernel is released, but for now I'll volunteer as a guinea-pig. It is difficult to test with 2.6.31 on the system at present, though, because that kernel also breaks other things that the MythTV box relies on, and the system is in regular use as our only PVR. Right now, all I know is, that the PVR-250 IR port did not show up in /dev/input/ with 2.6.31 after loading ir_kbd_i2c. But it does show up there with all previous kernels going back to the 2.6.1x days. .. Actually, I meant to say that it does not show up in the output from the lsinput command, whereas it did show up there in all previous kernels. So, to keep the pain level reasonable, perhaps you could send some debugging patches, and I'll apply those, reconfigure the machine for 2.6.31 again, and collect some output for you. And also perhaps try a few things locally as well to speed up the process. .. I'm debugging various other b0rked things in 2.6.31 here right now, so I had a closer look at the Hauppauge I/R remote issue. The ir_kbd_i2c driver *does* still find it after all. But the difference is that the output from 'lsinput' has changed and no longer says Hauppauge. Which prevents the application from finding the remote control in the same way as before. I'll hack the application code here now to use the new output, but I wonder what the the thousands of other users will do when they first try 2.6.31 after release ? Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: On Sun, Jul 19, 2009 at 9:15 AM, Mark Lordl...@rtr.ca wrote: .. The mythbackend (recording) program tunes/records fine with it, but any attempt to watch Live TV via mythfrontend just locks up the UI for 30 seconds or so, and then it reverts to the menus. .. Could you please provide the following: 1. Exactly which product you are using (including the USB/PCI id) .. Doh! Yes, of course! It's the popular Hauppauge HVR-950Q USB Stick: Bus 007 Device 006: ID 2040:7200 Hauppauge 3. Whether you are using the device for digital, analog, or both, and which the mythtv attempted to use when running the mythfrontend. .. Digital-only, since the tuner stick has never worked (and still doesn't) for analog NTSC with MythTV-0.21-fixes. That's okay, I really only use it for digital ATSC over-the-air (OTA) reception. 2. dmesg output from the time the card is inserted (or booted up if PCI) to the time *after* you attempted to use the frontend with mythtv. The remainder of this email contains (only) the dmesg output. Thanks. rocessor 1 APIC 0x1 ip 0x6000 Initializing CPU#1 Calibrating delay using timer specific routine.. 5319.72 BogoMIPS (lpj=2659862) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 mce: CPU supports 6 MCE banks CPU1: Thermal monitoring enabled (TM2) x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106 CPU1: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz stepping 06 checking TSC synchronization [CPU#0 - CPU#1]: passed. Brought up 2 CPUs Total of 2 processors activated (10639.55 BogoMIPS). NET: Registered protocol family 16 ACPI: bus type pci registered dca service started, version 1.8 PCI: MCFG configuration 0: base e000 segment 0 buses 0 - 255 PCI: MCFG area at e000 reserved in E820 PCI: Using MMCONFIG at e000 - efff PCI: Using configuration type 1 for base access bio: create slab bio-0 at 0 ACPI: EC: Look up EC in DSDT ACPI: Interpreter enabled ACPI: (supports S0 S3 S4 S5) ACPI: Using IOAPIC for interrupt routing ACPI: No dock devices found. ACPI: PCI Root Bridge [PCI0] (:00) pci :00:01.0: PME# supported from D0 D3hot D3cold pci :00:01.0: PME# disabled pci :00:1a.0: reg 20 io port: [0xfc00-0xfc1f] pci :00:1a.1: reg 20 io port: [0xf800-0xf81f] pci :00:1a.7: reg 10 32bit mmio: [0xfdfff000-0xfdfff3ff] pci :00:1a.7: PME# supported from D0 D3hot D3cold pci :00:1a.7: PME# disabled pci :00:1b.0: reg 10 64bit mmio: [0xfdff4000-0xfdff7fff] pci :00:1b.0: PME# supported from D0 D3hot D3cold pci :00:1b.0: PME# disabled pci :00:1c.0: PME# supported from D0 D3hot D3cold pci :00:1c.0: PME# disabled pci :00:1c.3: PME# supported from D0 D3hot D3cold pci :00:1c.3: PME# disabled pci :00:1d.0: reg 20 io port: [0xf400-0xf41f] pci :00:1d.1: reg 20 io port: [0xf000-0xf01f] pci :00:1d.2: reg 20 io port: [0xec00-0xec1f] pci :00:1d.7: reg 10 32bit mmio: [0xfdffe000-0xfdffe3ff] pci :00:1d.7: PME# supported from D0 D3hot D3cold pci :00:1d.7: PME# disabled pci :00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO pci :00:1f.0: quirk: region 0480-04bf claimed by ICH6 GPIO pci :00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0800 (mask 003f) pci :00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290 (mask 003f) pci :00:1f.2: reg 10 io port: [0xe800-0xe807] pci :00:1f.2: reg 14 io port: [0xe400-0xe403] pci :00:1f.2: reg 18 io port: [0xe000-0xe007] pci :00:1f.2: reg 1c io port: [0xdc00-0xdc03] pci :00:1f.2: reg 20 io port: [0xd800-0xd81f] pci :00:1f.2: reg 24 32bit mmio: [0xfdffd000-0xfdffd7ff] pci :00:1f.2: PME# supported from D3hot pci :00:1f.2: PME# disabled pci :00:1f.3: reg 10 32bit mmio: [0xfdffc000-0xfdffc0ff] pci :00:1f.3: reg 20 io port: [0x500-0x51f] pci :00:1f.6: reg 10 64bit mmio: [0xfdffb000-0xfdffbfff] pci :01:00.0: reg 10 32bit mmio: [0xfa00-0xfaff] pci :01:00.0: reg 14 64bit mmio: [0xc000-0xcfff] pci :01:00.0: reg 1c 64bit mmio: [0xf800-0xf9ff] pci :01:00.0: reg 24 io port: [0x5c00-0x5c7f] pci :01:00.0: reg 30 32bit mmio: [0x00-0x07] pci :00:01.0: bridge io port: [0x5000-0x5fff] pci :00:01.0: bridge 32bit mmio: [0xf800-0xfbff] pci :00:01.0: bridge 64bit mmio pref: [0xc000-0xcfff] pci :00:1c.0: bridge io port: [0xa000-0xafff] pci :00:1c.0: bridge 32bit mmio: [0xfdc0-0xfdcf] pci :00:1c.0: bridge 64bit mmio pref: [0xfdb0-0xfdbf] pci :04:00.0: reg 10 64bit mmio: [0xfdefc000-0xfdef] pci :04:00.0: reg 18 io port: [0x6c00-0x6cff] pci :04:00.0: reg 30 32bit mmio: [0x00-0x01] pci :04:00.0: supports D1 D2 pci :04:00.0: PME# supported from D0 D1 D2 D3hot D3cold pci :04:00.0: PME# disabled pci :00:1c.3: bridge io port: [0x6000-0x6fff] pci :00:1c.3: bridge 32bit mmio: [0xfde0-0xfdef] pci
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: On Sun, Jul 19, 2009 at 9:15 AM, Mark Lordl...@rtr.ca wrote: Devin, Thanks for your good efforts and updates on the xc5000 driver. But the version in 2.6.31 no longer works with mythfrontend from the 0.21-fixes branch of MythTV. .. Also, Could you please install the latest v4l-dvb code using the directions at http://linuxtv.org/repo and see if the problem still occurs. This will tell us if the problem is some patch that didn't make it upstream, and will make it easier for me to give you patches that provide more debug info. .. Okay, I pulled in v4l-dvb-bdd711bbc07e, built/installed/rebooted, and ended up with exactly the same behaviour. So the good news is, nothing appears to have been left out in 2.6.31. :) But still no really good clues to go on, other than this observation from before: The mythbackend (recording) program tunes/records fine with it, but any attempt to watch Live TV via mythfrontend just locks up the UI for 30 seconds or so, and then it reverts to the menus. I find that rather odd, as mythfrontend normally has very little interaction with the tuner devices. But it does try to read the signal strength and quality from the tuner, so perhaps this is a clue as to what has gone wrong? .. Really, the mythfrontend DOES NOT DEAL WITH TUNERS directly, leaving that to the mythbackend. EXCEPT for when it wants to show a signal strength/quality indication onscreen, which is done when tuning to a new channel. So it's got to be something on that pathway, I suspect, but despite being a kernel developer, I'm not terribly knowledgeable about V4L, DVB, or the MythTV internals. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Mark Lord wrote: .. Really, the mythfrontend DOES NOT DEAL WITH TUNERS directly, leaving that to the mythbackend. EXCEPT for when it wants to show a signal strength/quality indication onscreen, which is done when tuning to a new channel. So it's got to be something on that pathway, I suspect, but despite being a kernel developer, I'm not terribly knowledgeable about V4L, DVB, or the MythTV internals. .. Okay, got it. Sort of. :) 1. Patched mythtv to not show the signal strength info. No effect. 2. Substituted a different brand/model/chipset DVB tuner for the 950Q, and everything was working fine again. So we know it's not a generic issue. 3. In mythtv-setup - CaptureCards - DVB:1 - RecordingOptions there is a tickbox for Open DVB Card on Demand. It was ticked, so I un-ticked that box. Everything now works! When that tickbox was selected, the xc5000 took five (5) seconds to open, as it did the firmware upload every time. This appeared to exceed some timeout inside myth. With the tickbox NOT ticked, myth just opens the tuner once at startup, and keeps it open, so no more delay when it wants to use it. I wonder if we can be smarter/faster about the xc5000 firmware uploads? Cheers -- To unsubscribe from this list: send the line unsubscribe linux-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/3] ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type
Jean Delvare wrote:
On Sun, 19 Jul 2009 10:38:37 -0400, Mark Lord wrote:
I'm debugging various other b0rked things in 2.6.31 here right now,
so I had a closer look at the Hauppauge I/R remote issue.
The ir_kbd_i2c driver *does* still find it after all.
But the difference is that the output from 'lsinput' has changed
and no longer says Hauppauge. Which prevents the application from
finding the remote control in the same way as before.
OK, thanks for the investigation.
I'll hack the application code here now to use the new output,
but I wonder what the the thousands of other users will do when
they first try 2.6.31 after release ?
Where does lsinput get the string from?
..
Here's a test program for you:
#include stdio.h
#include stdlib.h
#include unistd.h
#include errno.h
#include fcntl.h
#include sys/ioctl.h
#include linux/input.h
// Invoke with /dev/input/event4 as argv[1]
//
// On 2.6.30, this gives the real name, eg. i2c IR (Hauppauge).
// On 2.6.31, it simply gives event4 as the name.
int main(int argc, char *argv[])
{
char buf[32];
int fd, rc;
fd = open(argv[1], O_RDONLY);
if (fd == -1) {
perror(argv[1]);
exit(1);
}
rc = ioctl(fd,EVIOCGNAME(sizeof(buf)),buf);
if (rc = 0)
fprintf(stderr, name: \%.*s\\n, rc, buf);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-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/3] ir-kbd-i2c: Allow use of ir-kdb-i2c internal get_key funcs and set ir_type
(resending.. somebody trimmed linux-kernel from the CC: earlier)
Jean Delvare wrote:
On Sun, 19 Jul 2009 10:38:37 -0400, Mark Lord wrote:
I'm debugging various other b0rked things in 2.6.31 here right now,
so I had a closer look at the Hauppauge I/R remote issue.
The ir_kbd_i2c driver *does* still find it after all.
But the difference is that the output from 'lsinput' has changed
and no longer says Hauppauge. Which prevents the application from
finding the remote control in the same way as before.
OK, thanks for the investigation.
I'll hack the application code here now to use the new output,
but I wonder what the the thousands of other users will do when
they first try 2.6.31 after release ?
Where does lsinput get the string from?
..
Here's a test program for you:
#include stdio.h
#include stdlib.h
#include unistd.h
#include errno.h
#include fcntl.h
#include sys/ioctl.h
#include linux/input.h
// Invoke with /dev/input/event4 as argv[1]
//
// On 2.6.30, this gives the real name, eg. i2c IR (Hauppauge).
// On 2.6.31, it simply gives event4 as the name.
int main(int argc, char *argv[])
{
char buf[32];
int fd, rc;
fd = open(argv[1], O_RDONLY);
if (fd == -1) {
perror(argv[1]);
exit(1);
}
rc = ioctl(fd,EVIOCGNAME(sizeof(buf)),buf);
if (rc = 0)
fprintf(stderr, name: \%.*s\\n, rc, buf);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Mark Lord wrote: .. Digital-only, since the tuner stick has never worked (and still doesn't) for analog NTSC with MythTV-0.21-fixes. That's okay, I really only use it for digital ATSC over-the-air (OTA) reception. .. Further to the analog -- which I don't care a whole bunch about -- I did try tracing it through mythtv today. The mythbackend thread that dies (segfault) is trying to read audio frames from the usb-audio device of the 950Q (/dev/dsp1). It seems to suffer massive stack corruption from something in there, though I'm not at all sure what the cause might be. Presumable this same myth code works with other tuners that lack hardware mpeg encoding, but I don't have any of those here to test with. I wonder if it's a 64-bit thing? My mythbox is pure 64-bits. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: ioctl(EVIOCGNAME) no longer returns device name
Dmitry Torokhov wrote: On Sun, Jul 19, 2009 at 03:20:50PM -0400, Mark Lord wrote: Mark Lord wrote: (resending.. somebody trimmed linux-kernel from the CC: earlier) Jean Delvare wrote: On Sun, 19 Jul 2009 10:38:37 -0400, Mark Lord wrote: I'm debugging various other b0rked things in 2.6.31 here right now, so I had a closer look at the Hauppauge I/R remote issue. The ir_kbd_i2c driver *does* still find it after all. But the difference is that the output from 'lsinput' has changed and no longer says Hauppauge. Which prevents the application from finding the remote control in the same way as before. OK, thanks for the investigation. I'll hack the application code here now to use the new output, but I wonder what the the thousands of other users will do when they first try 2.6.31 after release ? .. Mmm.. appears to be a systemwide thing, not just for the i2c stuff. *All* of the input devices now no longer show their real names when queried with ioctl(EVIOCGNAME). This is a regression from 2.6.30. Note that the real names *are* still stored somewhere, because they do still show up correctly under /sys/ Should be fixed by f936601471d1454dacbd3b2a961fd4d883090aeb in the for-linus branch of my tree. .. Peachy. Push it, or post it here and I can re-test with it. (does anyone else find it spooky that a google search for the above commit id actually finds Dmitry's email quoted above ? Mere seconds after he posted it for the very first time ??) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Mark Lord wrote: .. 3. In mythtv-setup - CaptureCards - DVB:1 - RecordingOptions there is a tickbox for Open DVB Card on Demand. It was ticked, so I un-ticked that box. Everything now works! When that tickbox was selected, the xc5000 took five (5) seconds to open, as it did the firmware upload every time. This appeared to exceed some timeout inside myth. With the tickbox NOT ticked, myth just opens the tuner once at startup, and keeps it open, so no more delay when it wants to use it. I wonder if we can be smarter/faster about the xc5000 firmware uploads? .. The firmware downloads take a little over six seconds, each time, and appear to be done after any sleep of the device. The un-ticked checkbox above means that the device will NEVER be put to sleep, though.. One problem (not new) remains: the device remains live on the USB even when the system is powered-off. It stays quite warm to the touch and is obviously wasting power this way. Is there not something the driver could do to put it to sleep on system shutdown, so that it draws much less power, per USB spec ? thanks! -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: 2. You hit the known analog audio issue that is preventing people from using analog with MythTV. I guess you can look at the analog support as a work in progress - it works with most apps, but there is something going on specific to MythTV that I haven't isolated yet. Note this issue is completely related to the 950q analog project and has nothing to do with the xc5000 tuner improvements. .. One additional thing I noticed here, is that when tuning analog for the first time, the firmware is reloaded yet again.. even though it has already been loaded once for digital operation. Perhaps the extra 6-7second delay here is contributing to Myth's problems. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Regression 2.6.31: xc5000 no longer works with Myth-0.21-fixes branch
Devin Heitmueller wrote: Yeah, the situation with the seven second firmware load time is well known. It's actually a result of the i2c's implementation in the au0828 hardware not properly supporting i2c clock stretching. Because of some bugs in the hardware, I have it clocked down to something like 30KHz as a workaround. I spent about a week investigating the i2c bus issue with my logic analyzer, and had to move on to other things. I documented the gory details here back in March if you really care: .. From your livejournal comments, it sounded like the slow clock might not be necessary until *after* the firmware transfer. Mmm.. I wonder if perhaps a higher clock speed could be used during the firmware download, and then switch to the slower 30KHz speed afterward ? This could reduce the firmware transfer to a couple of seconds, much better than the current 6-7 second pause. Cheers -- To unsubscribe from this list: send the line unsubscribe linux-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 for 2.6.29 stable series: remove #ifdef MODULE nonsense
Michael Krufky wrote:
Hans Verkuil wrote:
Hi Mike,
The attached patch should be queued for 2.6.29.X. It corresponds to
changeset 11098 (v4l2-common: remove incorrect MODULE test) in our
v4l-dvb tree and is part of the initial set of git patches going into
2.6.30.
Without this patch loading ivtv as a module while v4l2-common is
compiled into the kernel will cause a delayed load of the i2c modules
that ivtv needs since request_module is never called directly.
While it is nice to see the delayed load in action, it is not so nice
in that ivtv fails to do a lot of necessary i2c initializations and
will oops later on with a division-by-zero.
Thanks to Mark Lord for reporting this and helping me figure out what
was wrong.
Regards,
Hans
Got it, thanks.
In the future, please point to hash codes rather than revision ID's --
my rev IDs are not the same as yours, but hash codes are always unique.
I'll queue this the moment Linus merges Mauro's pending request.
..
Can either of you guys figure out how to get this patch (or something
equivalent) merged? It's been pending for some time now.
Thanks.
Message-ID: 49884ccb.3070...@rtr.ca
Date: Tue, 03 Feb 2009 08:55:23 -0500
From: Mark Lord l...@rtr.ca
MIME-Version: 1.0
To: video4linux-l...@redhat.com, Linux Kernel linux-ker...@vger.kernel.org
Subject: [PATCH] ir-kbd-i2c: support Hauppauge HVR-1600 R/C port
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
(resending, with video4linux-l...@redhat.com this time)
Update the ir-kbd-i2c driver to recognize the remote-control port
on the Hauppauge HV-1600 hybrid tuner card.
Signed-off-by: Mark Lord ml...@pobox.com
--- old/drivers/media/video/ir-kbd-i2c.c2008-12-24 18:26:37.0
-0500
+++ linux/drivers/media/video/ir-kbd-i2c.c 2009-02-01 13:08:19.0
-0500
@@ -354,6 +354,11 @@
} else {
ir_codes= ir_codes_rc5_tv;
}
+ } else if (adap-id == I2C_HW_B_CX2341X) {
+ name= Hauppauge;
+ ir_type = IR_TYPE_RC5;
+ ir-get_key = get_key_haup_xvr;
+ ir_codes= ir_codes_hauppauge_new;
} else {
/* Handled by saa7134-input */
name= SAA713x remote;
@@ -449,7 +454,7 @@
That's why we probe 0x1a (~0x34) first. CB
*/
- static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64, 0x30, -1};
+ static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64, 0x30, 0x71,
-1};
static const int probe_saa7134[] = { 0x7a, 0x47, 0x71, 0x2d, -1 };
static const int probe_em28XX[] = { 0x30, 0x47, -1 };
static const int probe_cx88[] = { 0x18, 0x6b, 0x71, -1 };
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bttv ir patch from Mark Lord
Michael Krufky wrote:
Mark Lord wrote:
Michael Krufky wrote:
Hans Verkuil wrote:
Hi Mike,
The attached patch should be queued for 2.6.29.X. It corresponds to
changeset 11098 (v4l2-common: remove incorrect MODULE test) in our
v4l-dvb tree and is part of the initial set of git patches going
into 2.6.30.
Without this patch loading ivtv as a module while v4l2-common is
compiled into the kernel will cause a delayed load of the i2c
modules that ivtv needs since request_module is never called directly.
While it is nice to see the delayed load in action, it is not so
nice in that ivtv fails to do a lot of necessary i2c initializations
and will oops later on with a division-by-zero.
Thanks to Mark Lord for reporting this and helping me figure out
what was wrong.
Regards,
Hans
Got it, thanks.
In the future, please point to hash codes rather than revision ID's
-- my rev IDs are not the same as yours, but hash codes are always
unique.
I'll queue this the moment Linus merges Mauro's pending request.
..
Can either of you guys figure out how to get this patch (or something
equivalent) merged? It's been pending for some time now.
Thanks.
Message-ID: 49884ccb.3070...@rtr.ca
Date: Tue, 03 Feb 2009 08:55:23 -0500
From: Mark Lord l...@rtr.ca
MIME-Version: 1.0
To: video4linux-l...@redhat.com, Linux Kernel
linux-ker...@vger.kernel.org
Subject: [PATCH] ir-kbd-i2c: support Hauppauge HVR-1600 R/C port
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
(resending, with video4linux-l...@redhat.com this time)
Update the ir-kbd-i2c driver to recognize the remote-control port
on the Hauppauge HV-1600 hybrid tuner card.
Signed-off-by: Mark Lord ml...@pobox.com
--- old/drivers/media/video/ir-kbd-i2c.c2008-12-24
18:26:37.0 -0500
+++ linux/drivers/media/video/ir-kbd-i2c.c2009-02-01
13:08:19.0 -0500
@@ -354,6 +354,11 @@
} else {
ir_codes= ir_codes_rc5_tv;
}
+} else if (adap-id == I2C_HW_B_CX2341X) {
+name= Hauppauge;
+ir_type = IR_TYPE_RC5;
+ir-get_key = get_key_haup_xvr;
+ir_codes= ir_codes_hauppauge_new;
} else {
/* Handled by saa7134-input */
name= SAA713x remote;
@@ -449,7 +454,7 @@
That's why we probe 0x1a (~0x34) first. CB
*/
-static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64, 0x30, -1};
+static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64, 0x30,
0x71, -1};
static const int probe_saa7134[] = { 0x7a, 0x47, 0x71, 0x2d, -1 };
static const int probe_em28XX[] = { 0x30, 0x47, -1 };
static const int probe_cx88[] = { 0x18, 0x6b, 0x71, -1 };
looks like a zilog, and you should use LIRC for that.
..
It's a Hauppauge remote port, just like the one on the (supported) PVR-250.
And I don't want the LIRC monstrosity when there's a perfectly good
kernel driver to run it directly. The patch does not prevent others
from using LIRC.
PLEASE DO NOT HIJAAK unrelated threads with unrelated emails.
..
Hijack, not HIJAAK. :)
thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bttv ir patch from Mark Lord
Hans Verkuil wrote: It's best to wait a bit. Jean Delvare is working on this ir-kbd-i2c driver right now and when he's finished it should be much easier to add this. Most importantly you can add this new i2c address to the cx18 driver rather than add it to the probe_bttv list, which is rather overloaded anyway. He should be finished within 1-3 weeks I guess. Probably sooner rather than later. Just watch the linux-media list for it. .. Thanks. I'll just watch for it arriving upstream in 2.6.31 (?) then, if the current ir-kbd-i2c patch doesn't end up in 2.6.30 already. Good idea on the cleanup in there, too. It was looking a bit tattered around the edges, and my patch doesn't really help much with that aspect. :) Cheers -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
