On 2015-02-24 14:44, Mauro Carvalho Chehab wrote:
Em Tue, 24 Feb 2015 11:15:53 +0100
David Härdeman escreveu:
The output that you gave (the actual scancodes that are generated) is
what I was looking for, not the keymap. If I remember correctly my
patch
wasn't supposed to change the generated
Em Tue, 24 Feb 2015 11:15:53 +0100
David Härdeman escreveu:
> On 2015-02-24 11:08, David Cimbůrek wrote:
> >>> Hi,
> >>>
> >>> I looked at this again and I still don't see why the order is
> >>> important.
> >>> Plus the code looks like it does what it should be doing when using
> >>> RC_SCANCO
On 2015-02-24 11:08, David Cimbůrek wrote:
Hi,
I looked at this again and I still don't see why the order is
important.
Plus the code looks like it does what it should be doing when using
RC_SCANCODE_NEC, RC_SCANCODE_NEC32, RC_SCANCODE_NECX and
RC_SCANCODE_RC5.
Unfortunately I can't review
>> Hi,
>>
>> I looked at this again and I still don't see why the order is important.
>> Plus the code looks like it does what it should be doing when using
>> RC_SCANCODE_NEC, RC_SCANCODE_NEC32, RC_SCANCODE_NECX and RC_SCANCODE_RC5.
>>
>> Unfortunately I can't review this if I am not sure about it
2015-02-12 22:57 GMT+01:00 Luis de Bethencourt :
> On Thu, Feb 12, 2015 at 06:34:40PM +0100, David Cimbůrek wrote:
>> 2015-02-12 12:50 GMT+01:00 Mauro Carvalho Chehab :
>> > Em Wed, 11 Feb 2015 17:41:01 +0100
>> > David Cimbůrek escreveu:
>> >
>> > Please don't top post. I reordered the messages b
On Thu, Feb 12, 2015 at 06:34:40PM +0100, David Cimbůrek wrote:
> 2015-02-12 12:50 GMT+01:00 Mauro Carvalho Chehab :
> > Em Wed, 11 Feb 2015 17:41:01 +0100
> > David Cimbůrek escreveu:
> >
> > Please don't top post. I reordered the messages below in order to get some
> > sanity.
> >
> >>
> >> 2015
2015-02-12 12:50 GMT+01:00 Mauro Carvalho Chehab :
> Em Wed, 11 Feb 2015 17:41:01 +0100
> David Cimbůrek escreveu:
>
> Please don't top post. I reordered the messages below in order to get some
> sanity.
>
>>
>> 2015-02-11 15:40 GMT+01:00 David Härdeman :
>> > Can you generate some scancodes befor
Em Wed, 11 Feb 2015 17:41:01 +0100
David Cimbůrek escreveu:
Please don't top post. I reordered the messages below in order to get some
sanity.
>
> 2015-02-11 15:40 GMT+01:00 David Härdeman :
> > Can you generate some scancodes before and after commit
> > af3a4a9bbeb00df3e42e77240b4cdac5479812f9
On Thu, Feb 12, 2015 at 08:15:10AM +0100, David Cimbůrek wrote:
> I'll try to describe my thoughts.
>
> The changed structure "dib0700_rc_response" is used in
> dib0700_core.c:dib0700_rc_urb_completion(struct urb *purb) function:
>
> struct dib0700_rc_response *poll_reply;
> ...
> poll_reply = pu
I'll try to describe my thoughts.
The changed structure "dib0700_rc_response" is used in
dib0700_core.c:dib0700_rc_urb_completion(struct urb *purb) function:
struct dib0700_rc_response *poll_reply;
...
poll_reply = purb->transfer_buffer;
dib0700_rc_urb_completion() is then used in
dib0700_core.c
On Tue, Feb 10, 2015 at 11:38:11AM +0100, David Cimbůrek wrote:
> Please include this patch to kernel! It takes too much time for such a
> simple fix!
>
The patch is simple but why it fixes the issue isn't that simple. Could you
explain why the order of the variables inside the structure is break
Let me know what exactly do you want me to do (which commands, which
traces etc.). I'm not very familiar with the Linux media stuff...
2015-02-11 15:40 GMT+01:00 David Härdeman :
> Can you generate some scancodes before and after commit
> af3a4a9bbeb00df3e42e77240b4cdac5479812f9?
>
>
>
> On 2015-0
Can you generate some scancodes before and after commit
af3a4a9bbeb00df3e42e77240b4cdac5479812f9?
On 2015-02-11 14:53, David Cimbůrek wrote:
David Härdeman: I'm using defaults, I have no custom modifications.
2015-02-11 14:24 GMT+01:00 David Härdeman :
David C: are you using the in-kernel k
David Härdeman: I'm using defaults, I have no custom modifications.
2015-02-11 14:24 GMT+01:00 David Härdeman :
> David C: are you using the in-kernel keymap or loading a custom one?
>
>
> On 2015-02-10 11:45, Antti Palosaari wrote:
>>
>> David Härdeman,
>> Could you look that as it is your patch
David C: are you using the in-kernel keymap or loading a custom one?
On 2015-02-10 11:45, Antti Palosaari wrote:
David Härdeman,
Could you look that as it is your patch which has broken it
commit af3a4a9bbeb00df3e42e77240b4cdac5479812f9
Author: David Härdeman
Date: Thu Apr 3 20:31:51 2014 -0
David Härdeman,
Could you look that as it is your patch which has broken it
commit af3a4a9bbeb00df3e42e77240b4cdac5479812f9
Author: David Härdeman
Date: Thu Apr 3 20:31:51 2014 -0300
[media] dib0700: NEC scancode cleanup
Antti
On 02/10/2015 12:38 PM, David Cimbůrek wrote:
Please inclu
Please include this patch to kernel! It takes too much time for such a
simple fix!
2015-01-07 13:51 GMT+01:00 David Cimbůrek :
> No one is interested? I'd like to get this patch to kernel to fix the
> issue. Can someone here do it please?
>
>
> 2014-12-20 14:36 GMT+01:00 David Cimbůrek :
>> Hi,
>
No one is interested? I'd like to get this patch to kernel to fix the
issue. Can someone here do it please?
2014-12-20 14:36 GMT+01:00 David Cimbůrek :
> Hi,
>
> with kernel 3.17 remote control for Pinnacle 73e (ID 2304:0237
> Pinnacle Systems, Inc. PCTV 73e [DiBcom DiB7000PC]) does not work
> an
Hi,
with kernel 3.17 remote control for Pinnacle 73e (ID 2304:0237
Pinnacle Systems, Inc. PCTV 73e [DiBcom DiB7000PC]) does not work
anymore.
I checked the changes and found out the problem in commit
af3a4a9bbeb00df3e42e77240b4cdac5479812f9.
In dib0700_core.c in struct dib0700_rc_response the fo
19 matches
Mail list logo
