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
> ---
> Mauro, please queue this up for inclusion in linux-3.6.
> Patch is also attached to bypass emailer mangling.
> Thanks.
&
Add USB identifiers for MCE compatible I/R transceivers from Twisted Melon.
Signed-off-by: Mark Lord
---
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
linux-3.2.6) fixes the regression.
Signed-off-by: Mark Lord
---
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
-
On 11-12-06 08:56 AM, Devin Heitmueller wrote:
> On Tue, Dec 6, 2011 at 8:43 AM, Mauro Carvalho Chehab
> 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
>> xc5
On 11-12-05 06:47 PM, Devin Heitmueller wrote:
> On Mon, Dec 5, 2011 at 6:32 PM, Eddi De Pieri 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 fro
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 wro
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
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-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
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 tenta
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 l
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:
>>> ..
>>&
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
>> p
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 not
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 th
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
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 i
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 bef
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 tr
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
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 revisio
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..
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 Torokh
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 w
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
>>> wrote:
We should be able to handle the case where scancode is va
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 som
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
"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
h 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
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 "
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 ha
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
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: c
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 t
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
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 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 reco
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
is 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.
Che
h 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
uto
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
(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.
Cheer
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
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 t
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 guar
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
Devin Heitmueller wrote:
On Sun, Jul 19, 2009 at 9:57 PM, Mark Lord 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 t
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
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.
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 &q
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
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.
(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
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 abo
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 o
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 su
Devin Heitmueller wrote:
On Sun, Jul 19, 2009 at 9:15 AM, Mark Lord 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
Devin Heitmueller wrote:
On Sun, Jul 19, 2009 at 9:15 AM, Mark Lord 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
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
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
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
u
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
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.
Cheers
--
To unsubscribe from this list: send the line "unsubs
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
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
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
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
67 matches
Mail list logo
