Re: [PATCH] media: Pinnacle 73e infrared control stopped working since kernel 3.17

[Luis de Bethencourt <luis@debethencourt.com>]

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 <mchehab@osg.samsung.com>:
> > Em Wed, 11 Feb 2015 17:41:01 +0100
> > David Cimbůrek <david.cimburek@gmail.com> 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 <david@hardeman.nu>:
> >> > Can you generate some scancodes before and after commit
> >> > af3a4a9bbeb00df3e42e77240b4cdac5479812f9?
> >>
> >> 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...
> >
> > As root, you should run:
> >
> >         # ir-keytable -r
> >
> > This will print the scancodes and their key associations.
> >
> > Also, on what architecture are you testing?
> >
> > Regards,
> > Mauro
> 
> Output of the "ir-keytable -r" is available here:
> http://pastebin.com/eEDu1Bmn. It is the same before and after the
> patch.
> 
> Architecture is x86_64.
>
>

>From the top-posted thread. Merging it here to not confuse people.

> 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:dib0700_rc_setup() in macros usb_fill_bulk_urb and
> usb_fill_int_urb. These macros are defined in header file usb.h. Here
> I have found in macro description this:
> 
>  * @transfer_buffer: pointer to the transfer buffer
> 
> I suppose that it means that the struct dib0700_rc_response is being
> filled from this transfer buffer. Therefore I suppose that the order
> of structure members IS important.
> 
> Of course it's only my guess but my patch is really working for me :-)

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, and I don't
have the device to be able to properly test your patch.

Hopefully your print of the scancodes helps.

Luis