On Wed, May 04, 2011 at 05:16:29PM -0300, Mauro Carvalho Chehab wrote: > Hi Lawerence, > > Em 03-05-2011 14:19, Jarod Wilson escreveu: > > On May 3, 2011, at 3:25 AM, Lawrence Rust wrote: > > > >> On Mon, 2011-05-02 at 15:50 -0300, Mauro Carvalho Chehab wrote: > >>> Em 08-04-2011 09:50, Lawrence Rust escreveu: > >>>> This patch restores remote control input for cx2388x based boards on > >>>> Linux kernels >= 2.6.38. > >>>> > >>>> After upgrading from Linux 2.6.37 to 2.6.38 I found that the remote > >>>> control input of my Hauppauge Nova-S plus was no longer functioning. > >>>> I posted a question on this newsgroup and Mauro Carvalho Chehab gave > >>>> some helpful pointers as to the likely cause. > >>>> > >>>> Turns out that there are 2 problems: > >>>> > >>>> 1. In the IR interrupt handler of cx88-input.c there's a 32-bit multiply > >>>> overflow which causes IR pulse durations to be incorrectly calculated. > > I'm adding the patch for it today on my linux-next tree. I'll probably send > upstream on the next couple days. > > >>>> > >>>> 2. The RC5 decoder appends the system code to the scancode and passes > >>>> the combination to rc_keydown(). Unfortunately, the combined value is > >>>> then forwarded to input_event() which then fails to recognise a valid > >>>> scancode and hence no input events are generated. > > In this case, a patch should be sent to -stable in separate. > > Greg, > > On 2.6.38, there are two RC5 keytables for Hauppauge devices, one with incomplete > scancodes (just 8 bits for each key) and the other one with 14 bits. One patch > changed the IR handling for cx88 to accept 14-bits for scancodes, but the change > didn't switch to the complete table. > > For 2.6.39, all keytables for Hauppauge (4 different tables) were unified into > just one keytable. So, on 2.6.39-rc, the cx88 code already works fine for 64-bits > kernels, and the fix for 32-bits is undergoing. > > In the case of 2.6.38 kernel, the Remote Controller is broken for both kernels. > The fix is as simple as: > > --- a/drivers/media/video/cx88/cx88-input.c > +++ b/drivers/media/video/cx88/cx88-input.c > @@ -283,7 +283,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev *pci) > case CX88_BOARD_PCHDTV_HD3000: > case CX88_BOARD_PCHDTV_HD5500: > case CX88_BOARD_HAUPPAUGE_IRONLY: > - ir_codes = RC_MAP_HAUPPAUGE_NEW; > + ir_codes = RC_MAP_RC5_HAUPPAUGE_NEW; > ir->sampling = 1; > break; > case CX88_BOARD_WINFAST_DTV2000H: > > > But this change diverges from upstream, due to the table unify. Would such patch > be acceptable for stable, even not having a corresponding upstream commit? Yes, as long as .39 is working properly. We take patches in -stable for stuff like this at times, it just needs to be specified exactly like you did above. Want me to take this patch as-is for .38-stable? thanks, greg k-h -- 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
