On 02/17/2013 01:38 AM, Matthew Gyurgyik wrote:
On 01/20/2013 12:46 PM, Antti Palosaari wrote:
On 01/20/2013 04:40 PM, Matthew Gyurgyik wrote:
On 01/02/2013 09:53 PM, Matthew Gyurgyik wrote:
On 01/02/2013 03:59 PM, Antti Palosaari wrote:
On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
I can
On 02/24/2013 05:23 PM, Antti Palosaari wrote:
I rebased it to the latest LinuxTV 3.9. There is quite a lot of changes
done for em28xx driver so it could work. Please test.
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/HU345-Q
regards
Antti
I checked out the branch and
On 01/20/2013 12:46 PM, Antti Palosaari wrote:
On 01/20/2013 04:40 PM, Matthew Gyurgyik wrote:
On 01/02/2013 09:53 PM, Matthew Gyurgyik wrote:
On 01/02/2013 03:59 PM, Antti Palosaari wrote:
On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
I can test patches Tue and Wed this week. Afterwards,
On 01/02/2013 09:53 PM, Matthew Gyurgyik wrote:
On 01/02/2013 03:59 PM, Antti Palosaari wrote:
On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
I can test patches Tue and Wed this week. Afterwards, I probably won't
be able to test anything until Dec 28th/29th as I will be away from my
On 01/20/2013 04:40 PM, Matthew Gyurgyik wrote:
On 01/02/2013 09:53 PM, Matthew Gyurgyik wrote:
On 01/02/2013 03:59 PM, Antti Palosaari wrote:
On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
I can test patches Tue and Wed this week. Afterwards, I probably won't
be able to test anything until
On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
I can test patches Tue and Wed this week. Afterwards, I probably won't
be able to test anything until Dec 28th/29th as I will be away from my
workstation.
In regards to my issue compiling my kernel, it helps if I include
devtmpfs. :)
Matthew,
On Tue, Dec 11, 2012 at 10:59:06PM +0200, Antti Palosaari wrote:
Yes, that is. I have said it million times I would like to see that
implemented as a one single 4 byte NEC, but it is currently what it
is. What I understand David Härdeman has done some work toward that
too, but it is not ready.
On 01/02/2013 03:59 PM, Antti Palosaari wrote:
On 12/18/2012 05:08 AM, Matthew Gyurgyik wrote:
I can test patches Tue and Wed this week. Afterwards, I probably won't
be able to test anything until Dec 28th/29th as I will be away from my
workstation.
In regards to my issue compiling my kernel,
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
On 12/16/2012 08:26 PM, Antti Palosaari wrote:
On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Matthew, could you please validate your test results and try Mauros
patches ? If it doesn't work, please
On 12/17/2012 11:33 AM, Antti Palosaari wrote:
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
On 12/16/2012 08:26 PM, Antti Palosaari wrote:
On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Matthew, could you please validate your test results and
On 12/17/2012 06:08 AM, Antti Palosaari wrote:
On 12/17/2012 11:33 AM, Antti Palosaari wrote:
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
On 12/16/2012 08:26 PM, Antti Palosaari wrote:
On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Matthew,
On 12/17/2012 01:17 PM, Matthew Gyurgyik wrote:
On 12/17/2012 06:08 AM, Antti Palosaari wrote:
On 12/17/2012 11:33 AM, Antti Palosaari wrote:
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
On 12/16/2012 08:26 PM, Antti Palosaari wrote:
On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
On
Em 17-12-2012 10:30, Antti Palosaari escreveu:
On 12/17/2012 01:17 PM, Matthew Gyurgyik wrote:
On 12/17/2012 06:08 AM, Antti Palosaari wrote:
On 12/17/2012 11:33 AM, Antti Palosaari wrote:
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
On 12/16/2012 08:26 PM, Antti Palosaari wrote:
On
Hi Matthew,
Em 17-12-2012 09:17, Matthew Gyurgyik escreveu:
On 12/17/2012 06:08 AM, Antti Palosaari wrote:
On 12/17/2012 11:33 AM, Antti Palosaari wrote:
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
On 12/16/2012 08:26 PM, Antti Palosaari wrote:
On 12/17/2012 03:09 AM, Matthew Gyurgyik
On 12/17/2012 11:14 AM, Mauro Carvalho Chehab wrote:
Hi Matthew,
Em 17-12-2012 09:17, Matthew Gyurgyik escreveu:
On 12/17/2012 06:08 AM, Antti Palosaari wrote:
On 12/17/2012 11:33 AM, Antti Palosaari wrote:
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
On 12/16/2012 08:26 PM, Antti
On 12/17/2012 11:14 AM, Mauro Carvalho Chehab wrote:
Hi Matthew,
Em 17-12-2012 09:17, Matthew Gyurgyik escreveu:
On 12/17/2012 06:08 AM, Antti Palosaari wrote:
On 12/17/2012 11:33 AM, Antti Palosaari wrote:
On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
On 12/16/2012 08:26 PM, Antti
Am 15.12.2012 17:51, schrieb Antti Palosaari:
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Am 15.12.2012 14:38, schrieb Antti Palosaari:
On 12/15/2012 03:11 PM, Frank Schäfer wrote:
Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Matthew, could you please validate your test results and try Mauros
patches ? If it doesn't work, please create another USB-log.
Sorry it took me so long to test the patch, but the results look
promising, I actually got various keycodes!
dmesg:
On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Matthew, could you please validate your test results and try Mauros
patches ? If it doesn't work, please create another USB-log.
Sorry it took me so long to test the patch, but the results look
On 12/16/2012 08:26 PM, Antti Palosaari wrote:
On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Matthew, could you please validate your test results and try Mauros
patches ? If it doesn't work, please create another USB-log.
Sorry it took me so
Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Anyway, first we have to
Em Sat, 15 Dec 2012 14:11:24 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Sorry we completely lost the focus !
Do you remeber the thread title ? ;)
We have two separate issues here.
1) Making Matthews hardware
Didn't read the entire thread, but it seems that this were
On 12/15/2012 03:11 PM, Frank Schäfer wrote:
Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab
Am 15.12.2012 14:38, schrieb Antti Palosaari:
On 12/15/2012 03:11 PM, Frank Schäfer wrote:
Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
Em Fri, 14 Dec 2012
On 12/15/2012 06:21 PM, Frank Schäfer wrote:
Am 15.12.2012 14:38, schrieb Antti Palosaari:
On 12/15/2012 03:11 PM, Frank Schäfer wrote:
Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/15/2012 02:26 AM, Mauro
Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank Schäfer wrote:
Am 10.12.2012 18:57, schrieb
On 12/14/2012 05:33 PM, Frank Schäfer wrote:
Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank
On 12/14/2012 06:32 PM, Antti Palosaari wrote:
On 12/14/2012 05:33 PM, Frank Schäfer wrote:
Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48, schrieb
Em Fri, 14 Dec 2012 16:33:34 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48,
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Anyway, first we have to GET the bytes from the hardware. That's our
current problem !
And the hardware seems to need a different setup for reg 0x50 for the
different NEC sub protocols.
Which means
Em Fri, 14 Dec 2012 22:26:31 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Anyway, first we have to GET the bytes from the hardware. That's our
current problem !
And the hardware seems to
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Anyway, first we have to GET the bytes from the hardware. That's our
current problem !
And the hardware seems to need a different setup for reg 0x50 for
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari cr...@iki.fi escreveu:
NACK. NEC variant selection logic is broken by design.
If you think so, then feel free to fix it without causing regressions to
the existing userspace.
While you don't do it, I don't see anything wrong on this patch, as
On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari cr...@iki.fi escreveu:
NACK. NEC variant selection logic is broken by design.
If you think so, then feel free to fix it without causing regressions to
the existing userspace.
While you
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Anyway, first we have to GET the bytes from the hardware. That's our
Em Sat, 15 Dec 2012 03:12:58 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari cr...@iki.fi escreveu:
NACK. NEC variant selection logic is broken by design.
If you think so, then feel
On 12/12/2012 11:34 PM, Frank Schäfer wrote:
Am 12.12.2012 22:25, schrieb Frank Schäfer:
...
Am 11.12.2012 21:59, schrieb Antti Palosaari:
See current af9015 driver as example how driver makes decision which
variant of NEC is used. You will need something similar. Read all 4
NEC bytes from
Am 13.12.2012 16:09, schrieb Antti Palosaari:
On 12/12/2012 11:34 PM, Frank Schäfer wrote:
Am 12.12.2012 22:25, schrieb Frank Schäfer:
...
Am 11.12.2012 21:59, schrieb Antti Palosaari:
See current af9015 driver as example how driver makes decision which
variant of NEC is used. You will need
Em Mon, 10 Dec 2012 20:24:23 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 10.12.2012 18:57, schrieb Antti Palosaari:
On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
Adding a new property to the RC profile certainly seems to
Em Mon, 10 Dec 2012 11:13:07 -0500
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
Adding a new property to the RC profile certainly seems to be the
cleanest solution.
Do all protocols have paritiy checking ? Otherwise we could add a
Em Tue, 11 Dec 2012 21:51:34 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank Schäfer wrote:
Am 10.12.2012 18:57, schrieb Antti Palosaari:
On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
On Mon, Dec
Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari cr...@iki.fi escreveu:
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank Schäfer wrote:
Am 10.12.2012 18:57, schrieb Antti Palosaari:
On 12/10/2012 06:13 PM, Devin
Em Thu, 13 Dec 2012 18:07:16 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:
Em Tue, 11 Dec 2012 21:51:34 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank Schäfer wrote:
Am 10.12.2012 18:57,
Am 11.12.2012 21:59, schrieb Antti Palosaari:
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank Schäfer wrote:
Am 10.12.2012 18:57, schrieb Antti Palosaari:
On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
On Mon, Dec 10,
Am 12.12.2012 22:25, schrieb Frank Schäfer:
...
Am 11.12.2012 21:59, schrieb Antti Palosaari:
See current af9015 driver as example how driver makes decision which
variant of NEC is used. You will need something similar. Read all 4
NEC bytes from the hardware and then use driver to make
Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank Schäfer wrote:
Am 10.12.2012 18:57, schrieb Antti Palosaari:
On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
Adding a new property to the RC profile certainly seems to
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank Schäfer wrote:
Am 10.12.2012 18:57, schrieb Antti Palosaari:
On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
Adding a new
Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
On 12/09/2012 12:06 PM, Frank Schäfer wrote:
Forget this sh... (never do multiple things at the same time ;) )
Reg 0x50 is set to according to rc_type specified in the selected remote
control map.
So if the correct map is selected, everything
On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer
fschaefer@googlemail.com wrote:
Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
On 12/09/2012 12:06 PM, Frank Schäfer wrote:
Forget this sh... (never do multiple things at the same time ;) )
Reg 0x50 is set to according to rc_type specified
On 2012-12-10 10:39, Frank Schäfer wrote:
Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
On 12/09/2012 12:06 PM, Frank Schäfer wrote:
Forget this sh... (never do multiple things at the same time ;) )
Reg 0x50 is set to according to rc_type specified in the selected
remote
control map.
So if
Am 10.12.2012 16:46, schrieb Devin Heitmueller:
On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer
fschaefer@googlemail.com wrote:
Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
On 12/09/2012 12:06 PM, Frank Schäfer wrote:
Forget this sh... (never do multiple things at the same time ;) )
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
Adding a new property to the RC profile certainly seems to be the
cleanest solution.
Do all protocols have paritiy checking ? Otherwise we could add a new
type RC_TYPE_NEC_NO_PARITY.
OTOH, introducing a new bitfield in struct rc_map might be
On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
Adding a new property to the RC profile certainly seems to be the
cleanest solution.
Do all protocols have paritiy checking ? Otherwise we could add a new
type RC_TYPE_NEC_NO_PARITY.
OTOH,
Am 10.12.2012 18:57, schrieb Antti Palosaari:
On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
Adding a new property to the RC profile certainly seems to be the
cleanest solution.
Do all protocols have paritiy checking ? Otherwise we could add a
On 12/10/2012 09:24 PM, Frank Schäfer wrote:
Am 10.12.2012 18:57, schrieb Antti Palosaari:
On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
Adding a new property to the RC profile certainly seems to be the
cleanest solution.
Do all protocols
Am 08.12.2012 23:04, schrieb Matthew Gyurgyik:
On 12/08/2012 04:47 PM, Antti Palosaari wrote:
On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
On 12/08/2012 12:49 PM, Frank Schäfer wrote:
Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
That shouldn't be necessary. I just noticed that there is
On 12/09/2012 07:48 AM, Frank Schäfer wrote:
Am 08.12.2012 23:04, schrieb Matthew Gyurgyik:
On 12/08/2012 04:47 PM, Antti Palosaari wrote:
On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
On 12/08/2012 12:49 PM, Frank Schäfer wrote:
Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
That
On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik matt...@pyther.net wrote:
Just to make sure I'm not misunderstanding, the messages should get logged
to dmesg, correct?
I wrote the original IR support for the em2874, but it seems to have
changed a bit since I submitted it. One thing that jumps
Am 09.12.2012 16:46, schrieb Devin Heitmueller:
On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik matt...@pyther.net wrote:
Just to make sure I'm not misunderstanding, the messages should get logged
to dmesg, correct?
I wrote the original IR support for the em2874, but it seems to have
changed
Am 09.12.2012 17:19, schrieb Frank Schäfer:
Am 09.12.2012 16:46, schrieb Devin Heitmueller:
On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik matt...@pyther.net wrote:
Just to make sure I'm not misunderstanding, the messages should get logged
to dmesg, correct?
I wrote the original IR support
Am 09.12.2012 17:23, schrieb Frank Schäfer:
Am 09.12.2012 17:19, schrieb Frank Schäfer:
Am 09.12.2012 16:46, schrieb Devin Heitmueller:
On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik matt...@pyther.net wrote:
Just to make sure I'm not misunderstanding, the messages should get logged
to
On 12/09/2012 12:06 PM, Frank Schäfer wrote:
Forget this sh... (never do multiple things at the same time ;) )
Reg 0x50 is set to according to rc_type specified in the selected remote
control map.
So if the correct map is selected, everything should be fine (as long as
it is RC_TYPE_NEC or
Am 06.12.2012 23:58, schrieb Matthew Gyurgyik:
On 12/06/2012 04:49 PM, Frank Schäfer wrote:
Did you switch back to
.mpeg_mode = LGDT3305_MPEG_SERIAL,
.tpclk_edge = LGDT3305_TPCLK_FALLING_EDGE,
in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
On 12/08/2012 08:52 AM, Frank Schäfer wrote:
I lied, it works! I must have forgotten to do run make modules_install
or something! This patch accurately states my current code changes:
http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
Great, that's a big one step forward.
Based on this
Am 08.12.2012 15:10, schrieb Matthew Gyurgyik:
On 12/08/2012 08:52 AM, Frank Schäfer wrote:
I lied, it works! I must have forgotten to do run make modules_install
or something! This patch accurately states my current code changes:
http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
Great,
On 12/08/2012 10:20 AM, Frank Schäfer wrote:
Am 08.12.2012 15:10, schrieb Matthew Gyurgyik:
Ok, thanks. So the USB log was right and the bridge setup should be
complete, except that the remote control doesn't work yet...
Could you please test the patch in the attachment ?
Changes from V3:
-
Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
On 12/08/2012 10:20 AM, Frank Schäfer wrote:
Am 08.12.2012 15:10, schrieb Matthew Gyurgyik:
Ok, thanks. So the USB log was right and the bridge setup should be
complete, except that the remote control doesn't work yet...
Could you please test
On 12/08/2012 12:49 PM, Frank Schäfer wrote:
Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
That shouldn't be necessary. I just noticed that there is a module
parameter 'ir_debug'. ;)
With ir_debug enabled, you should see messages
em28xx_ir_handle_key: toggle: XX, count: XX, key
On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
On 12/08/2012 12:49 PM, Frank Schäfer wrote:
Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
That shouldn't be necessary. I just noticed that there is a module
parameter 'ir_debug'. ;)
With ir_debug enabled, you should see messages
On 12/08/2012 04:47 PM, Antti Palosaari wrote:
On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
On 12/08/2012 12:49 PM, Frank Schäfer wrote:
Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
That shouldn't be necessary. I just noticed that there is a module
parameter 'ir_debug'. ;)
With ir_debug
On 12/06/2012 10:21 PM, Devin Heitmueller wrote:
On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik matt...@pyther.net wrote:
I was able to do a bit of testing tonight and this is what I found.
A channel scan was unsuccessful:
http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg)
Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
On 12/05/2012 07:55 PM, Antti Palosaari wrote:
It was good snoop. I didn't saw nothing very interesting. But, I
think I found the reason. Just add that one line writing 0x42 to
register 0x0d. IIRC I saw earlier it caused that kind of bug...
Am 06.12.2012 03:32, schrieb Matthew Gyurgyik:
On 12/04/2012 04:06 PM, Frank Schäfer wrote:
I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
but LGDT3305_TPCLK_FALLING_EDGE is used instead of
LGDT3305_TPCLK_RISING_EDGE.
OTOH, the KWorld A340 bord sets this to
On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
fschaefer@googlemail.com wrote:
Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
On 12/05/2012 07:55 PM, Antti Palosaari wrote:
It was good snoop. I didn't saw nothing very interesting. But, I
think I found the reason. Just add that one
Am 06.12.2012 22:57, schrieb Devin Heitmueller:
On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
fschaefer@googlemail.com wrote:
Am 06.12.2012 03:16, schrieb Matthew Gyurgyik:
On 12/05/2012 07:55 PM, Antti Palosaari wrote:
It was good snoop. I didn't saw nothing very interesting. But, I
On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer
fschaefer@googlemail.com wrote:
That's possible, because Matthews log doesn't show any access to this
register.
If it is not used, the question is if writing 0x07 to this register can
cause any trouble...
Historically speaking, on that family
Am 06.12.2012 23:03, schrieb Devin Heitmueller:
On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer
fschaefer@googlemail.com wrote:
That's possible, because Matthews log doesn't show any access to this
register.
If it is not used, the question is if writing 0x07 to this register can
cause any
On 12/06/2012 04:49 PM, Frank Schäfer wrote:
Did you switch back to
.mpeg_mode = LGDT3305_MPEG_SERIAL,
.tpclk_edge = LGDT3305_TPCLK_FALLING_EDGE,
in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
testing this ?
I did not, but switching back doesn't
On 12/06/2012 04:49 PM, Frank Schäfer wrote:
Did you switch back to
.mpeg_mode = LGDT3305_MPEG_SERIAL,
.tpclk_edge = LGDT3305_TPCLK_FALLING_EDGE,
in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
testing this ?
You could also play with the other gpio
On 12/06/2012 05:58 PM, Matthew Gyurgyik wrote:
On 12/06/2012 04:49 PM, Frank Schäfer wrote:
Did you switch back to
.mpeg_mode = LGDT3305_MPEG_SERIAL,
.tpclk_edge = LGDT3305_TPCLK_FALLING_EDGE,
in struct lgdt3305_config em2874_lgdt3305_dev (em28xx-dvb.c) before
On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik matt...@pyther.net wrote:
I was able to do a bit of testing tonight and this is what I found.
A channel scan was unsuccessful:
http://pyther.net/a/digivox_atsc/dec06/scan.txt (no errors in dmesg)
Changing channels by pressing h in mplayer
On 12/05/2012 05:41 AM, Matthew Gyurgyik wrote:
On 12/04/2012 04:06 PM, Frank Schäfer wrote:
I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
but LGDT3305_TPCLK_FALLING_EDGE is used instead of
LGDT3305_TPCLK_RISING_EDGE.
OTOH, the KWorld A340 bord sets this to
On 12/05/2012 07:35 AM, Antti Palosaari wrote:
There is something really wrong.
I am not at US expert but why the hell
us-Cable-Standard-center-frequencies-QAM256 scans up to 999MHz whilst
demodulator max is set 858? Either one is wrong.
Also, demod seems to be HAS_LOCK about all the time.
On 12/05/2012 11:35 PM, Matthew Gyurgyik wrote:
On 12/05/2012 07:35 AM, Antti Palosaari wrote:
There is something really wrong.
I am not at US expert but why the hell
us-Cable-Standard-center-frequencies-QAM256 scans up to 999MHz whilst
demodulator max is set 858? Either one is wrong.
Also,
On 12/05/2012 05:01 PM, Antti Palosaari wrote:
OK, fine, I was then wrong. I have to say you have a lot of channels
over there what I can see from scan result [1]. Those channels which
says tuning failed are channels where is no transmission and those
filter timeout pid means there is ta
On 12/06/2012 12:33 AM, Matthew Gyurgyik wrote:
On 12/05/2012 05:01 PM, Antti Palosaari wrote:
OK, fine, I was then wrong. I have to say you have a lot of channels
over there what I can see from scan result [1]. Those channels which
says tuning failed are channels where is no transmission and
On 12/05/2012 07:55 PM, Antti Palosaari wrote:
It was good snoop. I didn't saw nothing very interesting. But, I think
I found the reason. Just add that one line writing 0x42 to register
0x0d. IIRC I saw earlier it caused that kind of bug...
+static struct em28xx_reg_seq msi_digivox_atsc[] =
On 12/04/2012 04:06 PM, Frank Schäfer wrote:
I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
but LGDT3305_TPCLK_FALLING_EDGE is used instead of
LGDT3305_TPCLK_RISING_EDGE.
OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
Matthew, could you please test V3
Am 04.12.2012 03:58, schrieb Devin Heitmueller:
On Mon, Dec 3, 2012 at 9:42 PM, Matthew Gyurgyik matt...@pyther.net wrote:
I would try running lsusb -v and send the output. Make sure that
it's not expecting to use bulk mode for DVB (which would require
driver changes to support).
Devin
On 12/04/2012 04:06 PM, Frank Schäfer wrote:
I double-checked the log and it is indeed set to LGDT3305_MPEG_SERIAL,
but LGDT3305_TPCLK_FALLING_EDGE is used instead of
LGDT3305_TPCLK_RISING_EDGE.
OTOH, the KWorld A340 bord sets this to LGDT3305_MPEG_PARALLEL...
Matthew, could you please test V3
Am 02.12.2012 18:18, schrieb Frank Schäfer:
Am 02.12.2012 15:23, schrieb Antti Palosaari:
On 12/02/2012 01:44 PM, Frank Schäfer wrote:
Am 30.11.2012 02:45, schrieb Matthew Gyurgyik:
On 11/29/2012 02:28 PM, Frank Schäfer wrote:
Matthew, stay tuned but be patient. ;) Regards, Frank
Sure thing,
On 12/03/2012 01:16 PM, Frank Schäfer wrote:
Here is v2 of the patch (attached).
Antti, could you please take a look at the std_map for the tuner ?
I'm not sure what the correct and complete map is.
For a first test, I've selected the same std_map as used with the KWorld
A340 (LGDT3304 +
On Mon, Dec 3, 2012 at 9:15 PM, Matthew Gyurgyik matt...@pyther.net wrote:
Although, it looked like tuning was semi-successful, I tried the following
* cat /dev/dvb/adapter0/dvr0 (no output)
* mplayer /dev/dvb/adapter0/dvr0 (no output)
* cat /dev/dvb/adapter0/dvr0 test.mpg (test.mpg
On 12/03/2012 09:29 PM, Devin Heitmueller wrote:
On Mon, Dec 3, 2012 at 9:15 PM, Matthew Gyurgyik matt...@pyther.net wrote:
Although, it looked like tuning was semi-successful, I tried the following
* cat /dev/dvb/adapter0/dvr0 (no output)
* mplayer /dev/dvb/adapter0/dvr0 (no output)
On Mon, Dec 3, 2012 at 9:42 PM, Matthew Gyurgyik matt...@pyther.net wrote:
I would try running lsusb -v and send the output. Make sure that
it's not expecting to use bulk mode for DVB (which would require
driver changes to support).
Devin
Here is the output of lsusb -v
Am 30.11.2012 02:45, schrieb Matthew Gyurgyik:
On 11/29/2012 02:28 PM, Frank Schäfer wrote:
Matthew, stay tuned but be patient. ;) Regards, Frank
Sure thing, just let me know what you need me to do!
Ok, please test the attached experimental patch and post the dmesg output.
Open questions:
-
On 12/02/2012 01:44 PM, Frank Schäfer wrote:
Am 30.11.2012 02:45, schrieb Matthew Gyurgyik:
On 11/29/2012 02:28 PM, Frank Schäfer wrote:
Matthew, stay tuned but be patient. ;) Regards, Frank
Sure thing, just let me know what you need me to do!
Ok, please test the attached experimental
Am 02.12.2012 15:23, schrieb Antti Palosaari:
On 12/02/2012 01:44 PM, Frank Schäfer wrote:
Am 30.11.2012 02:45, schrieb Matthew Gyurgyik:
On 11/29/2012 02:28 PM, Frank Schäfer wrote:
Matthew, stay tuned but be patient. ;) Regards, Frank
Sure thing, just let me know what you need me to do!
Am 29.11.2012 03:15, schrieb Antti Palosaari:
On 11/29/2012 04:05 AM, Matthew Gyurgyik wrote:
On 11/28/2012 05:55 PM, Antti Palosaari wrote:
Very, very, good pics and sniffs!!
From the sniff you could see I2C addresses
50 (a0 1) eeprom
0e (1c 1) demod
60 (c0 1) tuner
EM2874,
On 11/29/2012 09:28 PM, Frank Schäfer wrote:
Am 29.11.2012 03:15, schrieb Antti Palosaari:
On 11/29/2012 04:05 AM, Matthew Gyurgyik wrote:
On 11/28/2012 05:55 PM, Antti Palosaari wrote:
Very, very, good pics and sniffs!!
From the sniff you could see I2C addresses
50 (a0 1) eeprom
0e (1c
1 - 100 of 106 matches
Mail list logo
