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@xxxxxxxxxxxxxxx>: > > Em Wed, 11 Feb 2015 17:41:01 +0100 > > David Cimbůrek <david.cimburek@xxxxxxxxx> 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@xxxxxxxxxxx>: > >> > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
