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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
; 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
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
,
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
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
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
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
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
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
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
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
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
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
=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
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
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
.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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
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
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
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.
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
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
64 matches
Mail list logo
