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 th
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 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, I
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 D
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
workstatio
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, i
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 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, tes
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 Palosaa
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 Palosaa
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 wr
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 12/17
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 12/1
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, c
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 t
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 c
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 lon
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
promis
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: h
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
> Antt
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 escreveu:
On 12/15/2012 02:26 AM, Mauro Carvalho Che
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 escreveu:
>>>
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
> Em Fri, 14 De
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 escreveu:
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab escreveu:
Anyway, fir
Em Sat, 15 Dec 2012 14:11:24 +0100
Frank Schäfer 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 already solved.
> / the sc
Am 15.12.2012 02:54, schrieb Mauro Carvalho Chehab:
> Em Sat, 15 Dec 2012 02:56:25 +0200
> Antti Palosaari escreveu:
>
>> On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 14 Dec 2012 17:39:50 -0200
>>> Mauro Carvalho Chehab escreveu:
>>>
> Anyway, first we have to GET the byte
Em Sat, 15 Dec 2012 03:12:58 +0200
Antti Palosaari escreveu:
> On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote:
> > Em Sat, 15 Dec 2012 02:56:25 +0200
> > Antti Palosaari escreveu:
> >
> >> NACK. NEC variant selection logic is broken by design.
> >
> > If you think so, then feel free to fix
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari escreveu:
> On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
> > Em Fri, 14 Dec 2012 17:39:50 -0200
> > Mauro Carvalho Chehab escreveu:
> >
> >>> Anyway, first we have to GET the bytes from the hardware. That's our
> >>> current problem !
>
On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari 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
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari 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 it
will beha
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab 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
Em Fri, 14 Dec 2012 22:26:31 -0200
Mauro Carvalho Chehab escreveu:
> Em Fri, 14 Dec 2012 17:39:50 -0200
> Mauro Carvalho Chehab 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 f
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab 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 that the we
Em Fri, 14 Dec 2012 16:33:34 +0100
Frank Schäfer escreveu:
> Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
> > Em Tue, 11 Dec 2012 22:59:06 +0200
> > Antti Palosaari escreveu:
> >
> >> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
> >>> Am 10.12.2012 21:48, schrieb Antti Palosaari:
> O
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 escreveu:
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48, schrieb Antti Palosa
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 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 wrot
Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
> Em Tue, 11 Dec 2012 22:59:06 +0200
> Antti Palosaari 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, schr
Em Thu, 13 Dec 2012 18:07:16 -0200
Mauro Carvalho Chehab escreveu:
> Em Tue, 11 Dec 2012 21:51:34 +0100
> Frank Schäfer 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:
> > >>> O
Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari 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 Tue, 11 Dec 2012 21:51:34 +0100
Frank Schäfer 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 10, 2012 at 11:0
Em Mon, 10 Dec 2012 11:13:07 -0500
Devin Heitmueller 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 new
> > type RC_TYPE_
Em Mon, 10 Dec 2012 20:24:23 +0100
Frank Schäfer 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 be the
> >>> cleane
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 us
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 the
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 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 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 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 certa
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 have
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
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, introducin
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
Am 10.12.2012 16:46, schrieb Devin Heitmueller:
> On Mon, Dec 10, 2012 at 10:39 AM, 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
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
On Mon, Dec 10, 2012 at 10:39 AM, 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 re
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, eve
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 RC_TY
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 wrote:
Just to make sure I'm not misunderstanding, the messages should get logged
to dmesg, co
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 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
Am 09.12.2012 16:46, schrieb Devin Heitmueller:
> On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik 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
On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik 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 out at me is
if
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 shouldn'
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 notic
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 e
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
em28xx
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 XXYYZZ
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 p
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:
- use
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
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 (your
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
On 12/06/2012 10:21 PM, Devin Heitmueller wrote:
On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik 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
On Thu, Dec 6, 2012 at 8:40 PM, Matthew Gyurgyik 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 dvb://" caused
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
testing
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 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 hel
Am 06.12.2012 23:03, schrieb Devin Heitmueller:
> On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer
> 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...
> Histor
On Thu, Dec 6, 2012 at 5:01 PM, Frank Schäfer
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 of devices registers that
Am 06.12.2012 22:57, schrieb Devin Heitmueller:
> On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
> 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
On Thu, Dec 6, 2012 at 4:49 PM, Frank Schäfer
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 line writing 0x42 t
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
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.
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
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/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 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 ra
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, d
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 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 LGDT3305_MPEG
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 o
Am 04.12.2012 03:58, schrieb Devin Heitmueller:
> On Mon, Dec 3, 2012 at 9:42 PM, Matthew Gyurgyik 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 Mon, Dec 3, 2012 at 9:42 PM, Matthew Gyurgyik 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
> http://pyther.net/a/di
On 12/03/2012 09:29 PM, Devin Heitmueller wrote:
On Mon, Dec 3, 2012 at 9:15 PM, Matthew Gyurgyik 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/adap
On Mon, Dec 3, 2012 at 9:15 PM, Matthew Gyurgyik 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 was 0 bytes)
I
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 + TDA18
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, Fran
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 ne
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 patc
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 questio
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!
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo
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 107 matches
Mail list logo
