Re: em28xx: msi Digivox ATSC board id [0db0:8810]

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari <crope@iki.fi> escreveu:

> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
> > Am 10.12.2012 21:48, schrieb Antti Palosaari:
> >> On 12/10/2012 09:24 PM, Frank Schäfer wrote:
> >>> Am 10.12.2012 18:57, schrieb Antti Palosaari:
> >>>> On 12/10/2012 06:13 PM, Devin Heitmueller wrote:
> >>>>> On Mon, Dec 10, 2012 at 11:01 AM, Frank Schäfer
> >>>>>> Adding a new property to the RC profile certainly seems to be the
> >>>>>> cleanest solution.
> >>>>>> Do all protocols have paritiy checking ? Otherwise we could add a new
> >>>>>> type RC_TYPE_NEC_NO_PARITY.
> >>>>>> OTOH, introducing a new bitfield in struct rc_map might be usefull
> >>>>>> for
> >>>>>> other flags, too, in the future...
> >>>>>
> >>>>> It's probably also worth mentioning that in that mode the device
> >>>>> reports four bytes, not two.  I guess perhaps if parity is ignored it
> >>>>> reports the data in some other format?  You will probably have to do
> >>>>> some experimentation there.
> >
> > ...
> >
> >>>>
> >>>> Uh, current em28xx NEC implementation is locked to traditional 16 bit
> >>>> NEC, where is hw checksum used.
> >>>>
> >>>> Implementation should be changed to more general to support 24 and 32
> >>>> bit NEC too. There is multiple drivers doing already that, for example
> >>>> AF9015.
> >>>>
> >>>
> >>> Hmm... are there and documents (, links, books, ...) where I can learn
> >>> more about all those RC protocols ?
> >>
> >> Specification comes here:
> >> NEC send always 32 bit, 4 bytes. There is 3 different "sub" protocols:
> >>
> >> 1) 16bit NEC standard, 1 byte address code, 1 byte key code
> >> full 4 byte code: AA BB CC DD
> >> where:
> >> AA = address code
> >> BB = ~address code
> >> CC = key code
> >> DD = ~key code
> >>
> >> checksum:
> >> AA + BB = 0xff
> >> CC + DD = 0xff
> >>
> >> 2) 24bit NEC extended, 2 byte address code, 1 byte key code
> >> full 4 byte code: AA BB CC DD
> >> where:
> >> AA = address code (MSB)
> >> BB = address code (LSB)
> >> CC = key code
> >> DD = ~key code
> >>
> >> 3) 32bit NEC full, 4 byte key code
> >> full 4 byte code: AA BB CC DD
> >> where:
> >> AA =
> >> BB =
> >> CC =
> >> DD =
> >>
> >> I am not sure if there is separate parts for address and key code in
> >> case of 32bit NEC. See some existing remote keytables if there is any
> >> such table. It is very rare protocol. 1) and 2) are much more common.
> >>
> >
> > Many thanks.
> > So the problem is, that we have only a single RC_TYPE for all 3 protocol
> > variants and need a method to distinguish between them, right ?

This is not actually needed, as it is very easy to distinguish them when
doing the table lookups. Take a look at v4l-utils, at /utils/keytable/rc_keymaps:

A 16-bits NEC table:
	# table kworld_315u, type: NEC
	0x6143 KEY_POWER
	0x6101 KEY_VIDEO
	...

A 24-bits NEC table:
	# table pixelview_002t, type: NEC
	0x866b13 KEY_MUTE
	0x866b12 KEY_POWER2
	...

A 32-bits NEC table:
	# table tivo, type: NEC
	0xa10c900f KEY_MEDIA
	0xa10c0807 KEY_POWER2
	...

If you see there, there's no way for the Kernel to handle it wrong, as
there's an implicit rule when dealing with "extended NEC" protocols:

Being the IR code being given by: AA BB CC DD

On a 24-bit NEC table: AA is always different than ~BB, otherwise, it would
be a 16-bit NEC.

On a 32-bit NEC table: CC is always different than ~DD, otherwise, it would be
a 24-bit NEC.

> Yes, that is. I have said it "million" times I would like to see that 
> implemented as a one single 4 byte NEC, but it is currently what it is. 

The hard thing is that, if this is changed upstream, existing
tools/keytables will break. So, regressions will be introduced.

> What I understand David Härdeman has done some work toward that too, but 
> it is not ready.

One alternative would be to add some compatibility code at the table
read function that would convert a 16 bits or 24 bits NEC keycode table
into a 32 bits one, but doing it right can be a problem.

> See current af9015 driver as example how driver makes decision which 
> variant of NEC is used. You will need something similar. Read all 4 NEC 
> bytes from the hardware and then use driver to make decision which 
> variant it is. I am quite sure em28xx hardware supports reading all 4 
> bytes, but if not, you will need to do some other tricks.
> 
> regards
> Antti
> 

Regards,
Mauro