Re: [PATCH] rc-core: do not change 32bit NEC scancode format for now

[James Hogan <james.hogan@imgtec.com>]

[-- Attachment #1: Type: text/plain, Size: 4605 bytes --]

On Friday 28 March 2014 01:08:56 David Härdeman wrote:
> On Thu, Mar 27, 2014 at 11:21:23PM +0000, James Hogan wrote:
> >Hi David,
> >
> >On Thursday 27 March 2014 22:00:37 David Härdeman wrote:
> >> This reverts 18bc17448147e93f31cc9b1a83be49f1224657b2
> >> 
> >> The patch ignores the fact that NEC32 scancodes are generated not only in
> >> the NEC raw decoder but also directly in some drivers. Whichever approach
> >> is chosen it should be consistent across drivers and this patch needs
> >> more
> >> discussion.
> >
> >Fair enough. For reference which drivers are you referring to?
> 
> The ones I'm aware of right now are:

Thanks, I hadn't looked properly outside of drivers/media/rc/ :(

> drivers/media/usb/dvb-usb/dib0700_core.c

AFAICT this only seems to support 16bit and 24bit NEC, so NEC-32 doesn't affect 
it. I may have missed something subtle.

> drivers/media/usb/dvb-usb-v2/az6007.c
> drivers/media/usb/dvb-usb-v2/af9035.c
> drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> drivers/media/usb/dvb-usb-v2/af9015.c
> drivers/media/usb/em28xx/em28xx-input.c

Note, it appears none of these do any bit reversing for the 32bit case 
compared to 16/24 bit, so they're already different to the NEC32 scancode 
encoding that the raw nec decoder and tivo keymap were using, which used a 
different bitorder (!!) between the 32-bit and the 24/16-bit cases.

> 
> >> Furthermore, I'm convinced that we have to stop playing games trying to
> >> decipher the "meaning" of NEC scancodes (what's the
> >> customer/vendor/address, which byte is the MSB, etc).
> >
> >Well when all the buttons on a remote have the same address, and the
> >numeric buttons are sequential commands only in a certain bit/byte order,
> >then I think the word "decipher" is probably a bit of a stretch.
> 
> I think you misunderstood me. "decipher" is a bit of a stretch when
> talking of one remote control (I'm guessing you're referring to the Tivo
> remote). It's not that much of a stretch if we're referring to trying to
> derive a common meaning from the encoding used for *all* remote controls
> out there.
> 
> The discussion about the 24-bit version of NEC and whether the address
> bytes were in MSB or LSB order was a good example. Andy Walls cited a
> NEC manual which stated one thing and people also referred to
> http://www.sbprojects.com/knowledge/ir/nec.php which stated the opposite
> (while referring to an unnamed VCR service manual).
> 
> As a third example...I've read a Samsung service manual which happily
> stated that the remote (which used the NEC protocol) sent IR commands
> starting with the address x 2 (and looking at the raw NEC command, it
> did start with something like 0x07 0x07).
> 
> So don't get me wrong, I wasn't referring to your analysis of the Tivo
> remote but more the general approach that has been taken until now wrt.
> the NEC protocol in the kernel drivers.

Okay, thanks for the clarification.

> 
> >Nevertheless I don't have any attachment to 32-bit NEC. If it's likely to
> >change again I'd prefer img-ir-nec just not support it for now, so please
> >could you add the following hunks to your patch (or if the original patch
> >is
> >to be dropped this could be squashed into the img-ir-nec patch):
> I'd rather show you my complete proposal first before doing something
> radical with your driver. But it was a good reminder that I need to keep
> the NEC32 parsing in your driver in mind as well.

Okay no problem. I had assumed you were aiming for a short term fix to prevent 
the encoding change hitting mainline or an actual release (v3.15).

Cheers
James

> 
> >> I'll post separate proposals to that effect later.
> >
> >Great, please do Cc me
> >
> >(I have a work in progress branch to unify NEC scancodes, but I'm not sure
> >I'd have time to complete it any time soon anyway)
> 
> That is what I'm working on as well at the moment. It's actually to
> solve two problems...both to unify NEC scancodes (by simply using 32 bit
> scancodes everywhere and some fallback code...I'm not 100% sure it's
> doable but I hope so since it's the only sane solution I can think of in
> the long run)...and to make sure that protocol information actually gets
> used in keymaps, etc.
> 
> I hope to post patches soon that'll make it clearer.
> 
> Regards,
> David
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]