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

Am 08.12.2012 15:10, schrieb Matthew Gyurgyik:
> On 12/08/2012 08:52 AM, Frank Schäfer wrote:
>>> I lied, it works! I must have forgotten to do run make modules_install
>>> or something! This patch accurately states my current code changes:
>>> http://pyther.net/a/digivox_atsc/diff-Dec-06-v1.patch
>> Great, that's a big one step forward.
>>
>> Based on this (your) patch, could you please verify that ist was really
>> the adding of
>>
>>      {0x0d,            0x42, 0xff,   0},
>>
>> to struct em28xx_reg_seq msi_digivox_atsc ? The tests before this change
>> were all made with a wrong combination of configuration values for the
>> LGDT3305...
> I have commented that line out and from some basic testing, it doesn't
> appear to change anything. I can still tune and watch a channel, scan
> still fails.

Ok, thanks. So the USB log was right and the bridge setup should be
complete, except that the remote control doesn't work yet...

Could you please test the patch in the attachment ?
Changes from V3:
- use the correct demodulator configuration
- changed the remote control map to RC_MAP_KWORLD_315U (same as DIGIVOX
III but without NEC extended address byte)
- switched from the KWorld std_map for the tuner to a custom one. For
QAM, I selected the values from the log and for atsc I took the standard
values from the tda18271 driver.

Regards,
Frank

>
> Thanks,
> Matthew
  

On 12/08/2012 10:20 AM, Frank Schäfer wrote:
> Am 08.12.2012 15:10, schrieb Matthew Gyurgyik:
>
> Ok, thanks. So the USB log was right and the bridge setup should be
> complete, except that the remote control doesn't work yet...
>
> Could you please test the patch in the attachment ?
> Changes from V3:
> - use the correct demodulator configuration
> - changed the remote control map to RC_MAP_KWORLD_315U (same as DIGIVOX
> III but without NEC extended address byte)
> - switched from the KWorld std_map for the tuner to a custom one. For
> QAM, I selected the values from the log and for atsc I took the standard
> values from the tda18271 driver.
>
> Regards,
> Frank
>

I tested the patch and this is what I found

The remote still doesn't work, would it be helpful to do a usb snoop 
while using the remote in windows (not sure I can make the win7 driver 
work in xp)?

http://pyther.net/a/digivox_atsc/patch4/evtest.txt

A channel scan still fails with the following error:
 > start_filter:1752: ERROR: ioctl DMX_SET_FILTER failed: 71 Protocol error

However there are no messages in dmesg that indicate any errors / warnings.
http://pyther.net/a/digivox_atsc/patch4/scan.txt

When using mplayer dvb://

It seems that switching channels work a bit better, I can switch more 
channels before I get errors and mplayer closes.

http://pyther.net/a/digivox_atsc/patch4/mplayer.txt

Dmesg: http://pyther.net/a/digivox_atsc/patch4/dmesg.txt

Thanks,
Matthew
--
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
  

Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
> On 12/08/2012 10:20 AM, Frank Schäfer wrote:
>> Am 08.12.2012 15:10, schrieb Matthew Gyurgyik:
>>
>> Ok, thanks. So the USB log was right and the bridge setup should be
>> complete, except that the remote control doesn't work yet...
>>
>> Could you please test the patch in the attachment ?
>> Changes from V3:
>> - use the correct demodulator configuration
>> - changed the remote control map to RC_MAP_KWORLD_315U (same as DIGIVOX
>> III but without NEC extended address byte)
>> - switched from the KWorld std_map for the tuner to a custom one. For
>> QAM, I selected the values from the log and for atsc I took the standard
>> values from the tda18271 driver.
>>
>> Regards,
>> Frank
>>
>
> I tested the patch and this is what I found
>
> The remote still doesn't work, would it be helpful to do a usb snoop
> while using the remote in windows (not sure I can make the win7 driver
> work in xp)?

That shouldn't be necessary. I just noticed that there is a module
parameter 'ir_debug'. ;)
With ir_debug enabled, you should see messages

        em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ

everytime you press a button. Once we know the key codes, we can set up
a key map (if it doesn't exist yet).

>
> http://pyther.net/a/digivox_atsc/patch4/evtest.txt
>
> A channel scan still fails with the following error:
> > start_filter:1752: ERROR: ioctl DMX_SET_FILTER failed: 71 Protocol
> error
>
> However there are no messages in dmesg that indicate any errors /
> warnings.
> http://pyther.net/a/digivox_atsc/patch4/scan.txt
>
> When using mplayer dvb://
>
> It seems that switching channels work a bit better, I can switch more
> channels before I get errors and mplayer closes.
>
> http://pyther.net/a/digivox_atsc/patch4/mplayer.txt
>
> Dmesg: http://pyther.net/a/digivox_atsc/patch4/dmesg.txt

Ok. Hopefully the tuner experts have some ideas... Antti, Devin ?

Regards,
Frank

>
> Thanks,
> Matthew

--
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
  

On 12/08/2012 12:49 PM, Frank Schäfer wrote:
> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>
> That shouldn't be necessary. I just noticed that there is a module
> parameter 'ir_debug'. ;)
> With ir_debug enabled, you should see messages
>
>          em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>
> everytime you press a button. Once we know the key codes, we can set up
> a key map (if it doesn't exist yet).
>

Maybe I'm doing something wrong but didn't have any luck :(

> [root@tux ~]# sudo rmmod em28xx_rc
> [root@tux ~]# sudo rmmod em28xx_dvb
> [root@tux ~]# sudo rmmod em28xx
> [root@tux ~]# modprobe em28xx_rc ir_debug=1

I don't see any additional messages in dmesg.

I verified the remote still works in windows (a stupidity check on my part)
--
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
  

On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
> On 12/08/2012 12:49 PM, Frank Schäfer wrote:
>> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>>
>> That shouldn't be necessary. I just noticed that there is a module
>> parameter 'ir_debug'. ;)
>> With ir_debug enabled, you should see messages
>>
>>          em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>>
>> everytime you press a button. Once we know the key codes, we can set up
>> a key map (if it doesn't exist yet).
>>
>
> Maybe I'm doing something wrong but didn't have any luck :(
>
>> [root@tux ~]# sudo rmmod em28xx_rc
>> [root@tux ~]# sudo rmmod em28xx_dvb
>> [root@tux ~]# sudo rmmod em28xx
>> [root@tux ~]# modprobe em28xx_rc ir_debug=1
>
> I don't see any additional messages in dmesg.
>
> I verified the remote still works in windows (a stupidity check on my part)

Maybe Kernel debugs are not enabled? em28xx driver is a little bit 
legacy in logging too as it uses own logging whilst nowadays dynamic 
logging is recommended.

replace KERN_DEBUG as KERN_INFO inside em28xx-input.c and test. It will 
change driver to use Kernel normal log writings instead of current debug 
ones.

regards
Antti
  

On 12/08/2012 04:47 PM, Antti Palosaari wrote:
> On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
>> On 12/08/2012 12:49 PM, Frank Schäfer wrote:
>>> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>>>
>>> That shouldn't be necessary. I just noticed that there is a module
>>> parameter 'ir_debug'. ;)
>>> With ir_debug enabled, you should see messages
>>>
>>>          em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>>>
>>> everytime you press a button. Once we know the key codes, we can set up
>>> a key map (if it doesn't exist yet).
>>>
>>
>> Maybe I'm doing something wrong but didn't have any luck :(
>>
>>> [root@tux ~]# sudo rmmod em28xx_rc
>>> [root@tux ~]# sudo rmmod em28xx_dvb
>>> [root@tux ~]# sudo rmmod em28xx
>>> [root@tux ~]# modprobe em28xx_rc ir_debug=1
>>
>> I don't see any additional messages in dmesg.
>>
>> I verified the remote still works in windows (a stupidity check on my
>> part)
>
> Maybe Kernel debugs are not enabled? em28xx driver is a little bit
> legacy in logging too as it uses own logging whilst nowadays dynamic
> logging is recommended.
>
> replace KERN_DEBUG as KERN_INFO inside em28xx-input.c and test. It will
> change driver to use Kernel normal log writings instead of current debug
> ones.
>
> regards
> Antti
>
>
That unfortunately doesn't make any difference.

I even tried adding a print statment before the debug line got called 
like this (line 97 added; em28xx-input.c):
  97     printk(KERN_INFO "key %02x\n", b);
  98     i2cdprintk("key %02x\n", b);

--
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
  

Am 08.12.2012 23:04, schrieb Matthew Gyurgyik:
> On 12/08/2012 04:47 PM, Antti Palosaari wrote:
>> On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
>>> On 12/08/2012 12:49 PM, Frank Schäfer wrote:
>>>> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>>>>
>>>> That shouldn't be necessary. I just noticed that there is a module
>>>> parameter 'ir_debug'. ;)
>>>> With ir_debug enabled, you should see messages
>>>>
>>>>          em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>>>>
>>>> everytime you press a button. Once we know the key codes, we can
>>>> set up
>>>> a key map (if it doesn't exist yet).
>>>>
>>>
>>> Maybe I'm doing something wrong but didn't have any luck :(
>>>
>>>> [root@tux ~]# sudo rmmod em28xx_rc
>>>> [root@tux ~]# sudo rmmod em28xx_dvb
>>>> [root@tux ~]# sudo rmmod em28xx
>>>> [root@tux ~]# modprobe em28xx_rc ir_debug=1
>>>
>>> I don't see any additional messages in dmesg.
>>>
>>> I verified the remote still works in windows (a stupidity check on my
>>> part)
>>
>> Maybe Kernel debugs are not enabled? em28xx driver is a little bit
>> legacy in logging too as it uses own logging whilst nowadays dynamic
>> logging is recommended.
>>
>> replace KERN_DEBUG as KERN_INFO inside em28xx-input.c and test. It will
>> change driver to use Kernel normal log writings instead of current debug
>> ones.
>>
>> regards
>> Antti
>>
>>
> That unfortunately doesn't make any difference.
>
> I even tried adding a print statment before the debug line got called
> like this (line 97 added; em28xx-input.c):
>  97     printk(KERN_INFO "key %02x\n", b);
>  98     i2cdprintk("key %02x\n", b);
>

The relevant line is

297        dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,

Change it to

297        printk(KERN_INFO "%s: toggle: %d, count: %d, key
0x%02x%02x\n", __func__,

Also double-check that the IR module (em28xx_rc) is enabled / gets loaded.

Regards,
Frank


--
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
  

On 12/09/2012 07:48 AM, Frank Schäfer wrote:
> Am 08.12.2012 23:04, schrieb Matthew Gyurgyik:
>> On 12/08/2012 04:47 PM, Antti Palosaari wrote:
>>> On 12/08/2012 11:40 PM, Matthew Gyurgyik wrote:
>>>> On 12/08/2012 12:49 PM, Frank Schäfer wrote:
>>>>> Am 08.12.2012 17:51, schrieb Matthew Gyurgyik:
>>>>>
>>>>> That shouldn't be necessary. I just noticed that there is a module
>>>>> parameter 'ir_debug'. ;)
>>>>> With ir_debug enabled, you should see messages
>>>>>
>>>>>           em28xx_ir_handle_key: toggle: XX, count: XX, key XXYYZZ
>>>>>
>>>>> everytime you press a button. Once we know the key codes, we can
>>>>> set up
>>>>> a key map (if it doesn't exist yet).
>>>>>
>>>>
>>>> Maybe I'm doing something wrong but didn't have any luck :(
>>>>
>>>>> [root@tux ~]# sudo rmmod em28xx_rc
>>>>> [root@tux ~]# sudo rmmod em28xx_dvb
>>>>> [root@tux ~]# sudo rmmod em28xx
>>>>> [root@tux ~]# modprobe em28xx_rc ir_debug=1
>>>>
>>>> I don't see any additional messages in dmesg.
>>>>
>>>> I verified the remote still works in windows (a stupidity check on my
>>>> part)
>>>
>>> Maybe Kernel debugs are not enabled? em28xx driver is a little bit
>>> legacy in logging too as it uses own logging whilst nowadays dynamic
>>> logging is recommended.
>>>
>>> replace KERN_DEBUG as KERN_INFO inside em28xx-input.c and test. It will
>>> change driver to use Kernel normal log writings instead of current debug
>>> ones.
>>>
>>> regards
>>> Antti
>>>
>>>
>> That unfortunately doesn't make any difference.
>>
>> I even tried adding a print statment before the debug line got called
>> like this (line 97 added; em28xx-input.c):
>>   97     printk(KERN_INFO "key %02x\n", b);
>>   98     i2cdprintk("key %02x\n", b);
>>
>
> The relevant line is
>
> 297        dprintk("%s: toggle: %d, count: %d, key 0x%02x%02x\n", __func__,
>
> Change it to
>
> 297        printk(KERN_INFO "%s: toggle: %d, count: %d, key
> 0x%02x%02x\n", __func__,
>
> Also double-check that the IR module (em28xx_rc) is enabled / gets loaded.
>
> Regards,
> Frank
>
>
Sadly I'm still not getting anything.

[root@tux ~]# rmmod em28xx_rc 

[root@tux ~]# rmmod em28xx_dvb
[root@tux ~]# rmmod em28xx
[root@tux ~]# lsmod | grep em28xx
[root@tux ~]# modprobe em28xx_rc ir_debug=1

[root@tux ~]# lsmod | grep em28xx
em28xx_dvb             17075  0
em28xx_rc               6250  0
em28xx                 85996  2 em28xx_dvb,em28xx_rc
rc_core                12193  3 rc_msi_digivox_iii,em28xx_rc
dvb_core               86050  2 em28xx_dvb,lgdt3305
tveeprom               13658  1 em28xx
videobuf_vmalloc        4136  1 em28xx
videobuf_core          15216  2 videobuf_vmalloc,em28xx
v4l2_common             6927  1 em28xx
videodev               97480  2 em28xx,v4l2_common


Just to make sure I'm not misunderstanding, the messages should get 
logged to dmesg, correct?


--
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
  

On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik <matthew@pyther.net> wrote:
> Just to make sure I'm not misunderstanding, the messages should get logged
> to dmesg, correct?

I wrote the original IR support for the em2874, but it seems to have
changed a bit since I submitted it.  One thing that jumps out at me is
if you specify a remote control of the wrong *type* (e.g. the driver
is configured for RC5 but the actual remote is configured for NEC),
then you're likely to get no events from the device.

You may wish to lookup what type of remote RC_MAP_KWORLD_315U is, and
try a remote that is of the other protocol type (e.g. if
RC_MAP_KWORLD_315U is RC5 then try a remote which is NEC).  Then see
if you get events.  If so, then you know you have the correct RC
protocol and just need to adjust the RC profile specified.

Also, it's possible the remote control is an RC6 remote, which I never
got around to adding em2874 driver support for.  Take a look at the
windows trace and see what register R50 is being set to.  In
particular, bits [3-2] will tell you what RC protocol the Windows
driver expects the remote to be.  I'm pretty sure I put the definition
for the relevant bits in em28xx-reg.h.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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
  

Am 09.12.2012 16:46, schrieb Devin Heitmueller:
> On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>> Just to make sure I'm not misunderstanding, the messages should get logged
>> to dmesg, correct?
> I wrote the original IR support for the em2874, but it seems to have
> changed a bit since I submitted it.  One thing that jumps out at me is
> if you specify a remote control of the wrong *type* (e.g. the driver
> is configured for RC5 but the actual remote is configured for NEC),
> then you're likely to get no events from the device.
>
> You may wish to lookup what type of remote RC_MAP_KWORLD_315U is, and
> try a remote that is of the other protocol type (e.g. if
> RC_MAP_KWORLD_315U is RC5 then try a remote which is NEC).  Then see
> if you get events.  If so, then you know you have the correct RC
> protocol and just need to adjust the RC profile specified.
>
> Also, it's possible the remote control is an RC6 remote, which I never
> got around to adding em2874 driver support for.  Take a look at the
> windows trace and see what register R50 is being set to.  In
> particular, bits [3-2] will tell you what RC protocol the Windows
> driver expects the remote to be.  I'm pretty sure I put the definition
> for the relevant bits in em28xx-reg.h.

According to the USB log, register 0x50 is set to 0x01.

em28xx-reg.h says:

/* em2874 IR config register (0x50) */
#define EM2874_IR_NEC           0x00
#define EM2874_IR_RC5           0x04
#define EM2874_IR_RC6_MODE_0    0x08
#define EM2874_IR_RC6_MODE_6A   0x0b

Any idea what 0x01 is ?

It also seems that em28xx_ir_change_protocol() always sets reg 0x05 to
EM2874_IR_RC5...

Regards,
Frank

> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com

--
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
  

Am 09.12.2012 17:19, schrieb Frank Schäfer:
> Am 09.12.2012 16:46, schrieb Devin Heitmueller:
>> On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>>> Just to make sure I'm not misunderstanding, the messages should get logged
>>> to dmesg, correct?
>> I wrote the original IR support for the em2874, but it seems to have
>> changed a bit since I submitted it.  One thing that jumps out at me is
>> if you specify a remote control of the wrong *type* (e.g. the driver
>> is configured for RC5 but the actual remote is configured for NEC),
>> then you're likely to get no events from the device.
>>
>> You may wish to lookup what type of remote RC_MAP_KWORLD_315U is, and
>> try a remote that is of the other protocol type (e.g. if
>> RC_MAP_KWORLD_315U is RC5 then try a remote which is NEC).  Then see
>> if you get events.  If so, then you know you have the correct RC
>> protocol and just need to adjust the RC profile specified.
>>
>> Also, it's possible the remote control is an RC6 remote, which I never
>> got around to adding em2874 driver support for.  Take a look at the
>> windows trace and see what register R50 is being set to.  In
>> particular, bits [3-2] will tell you what RC protocol the Windows
>> driver expects the remote to be.  I'm pretty sure I put the definition
>> for the relevant bits in em28xx-reg.h.
> According to the USB log, register 0x50 is set to 0x01.
>
> em28xx-reg.h says:
>
> /* em2874 IR config register (0x50) */
> #define EM2874_IR_NEC           0x00
> #define EM2874_IR_RC5           0x04
> #define EM2874_IR_RC6_MODE_0    0x08
> #define EM2874_IR_RC6_MODE_6A   0x0b
>
> Any idea what 0x01 is ?
>
> It also seems that em28xx_ir_change_protocol() always sets reg 0x05 to
> EM2874_IR_RC5...

Sorry, I was wrong. Of course it sets 0x05 to EM2874_IR_RC5 or
EM2874_IR_NEC depending on field .xclk in the board struct.

Frank

>
> Regards,
> Frank
>
>> Devin
>>
>> --
>> Devin J. Heitmueller - Kernel Labs
>> http://www.kernellabs.com

--
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
  

Am 09.12.2012 17:23, schrieb Frank Schäfer:
> Am 09.12.2012 17:19, schrieb Frank Schäfer:
>> Am 09.12.2012 16:46, schrieb Devin Heitmueller:
>>> On Sun, Dec 9, 2012 at 9:50 AM, Matthew Gyurgyik <matthew@pyther.net> wrote:
>>>> Just to make sure I'm not misunderstanding, the messages should get logged
>>>> to dmesg, correct?
>>> I wrote the original IR support for the em2874, but it seems to have
>>> changed a bit since I submitted it.  One thing that jumps out at me is
>>> if you specify a remote control of the wrong *type* (e.g. the driver
>>> is configured for RC5 but the actual remote is configured for NEC),
>>> then you're likely to get no events from the device.
>>>
>>> You may wish to lookup what type of remote RC_MAP_KWORLD_315U is, and
>>> try a remote that is of the other protocol type (e.g. if
>>> RC_MAP_KWORLD_315U is RC5 then try a remote which is NEC).  Then see
>>> if you get events.  If so, then you know you have the correct RC
>>> protocol and just need to adjust the RC profile specified.
>>>
>>> Also, it's possible the remote control is an RC6 remote, which I never
>>> got around to adding em2874 driver support for.  Take a look at the
>>> windows trace and see what register R50 is being set to.  In
>>> particular, bits [3-2] will tell you what RC protocol the Windows
>>> driver expects the remote to be.  I'm pretty sure I put the definition
>>> for the relevant bits in em28xx-reg.h.
>> According to the USB log, register 0x50 is set to 0x01.
>>
>> em28xx-reg.h says:
>>
>> /* em2874 IR config register (0x50) */
>> #define EM2874_IR_NEC           0x00
>> #define EM2874_IR_RC5           0x04
>> #define EM2874_IR_RC6_MODE_0    0x08
>> #define EM2874_IR_RC6_MODE_6A   0x0b
>>
>> Any idea what 0x01 is ?
>>
>> It also seems that em28xx_ir_change_protocol() always sets reg 0x05 to
>> EM2874_IR_RC5...
> Sorry, I was wrong. Of course it sets 0x05 to EM2874_IR_RC5 or
> EM2874_IR_NEC depending on field .xclk in the board struct.

Forget this sh... (never do multiple things at the same time ;) )

Reg 0x50 is set to according to rc_type specified in the selected remote
control map.
So if the correct map is selected, everything should be fine (as long as
it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).

RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
the stick seems to use no NEC protocol.

Matthew, insert a line

        ir_config = 0x01;

before

380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);

in em28xx-input.c and see if something shows up in the dmesg output.

Regards,
Frank


--
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
  

On 12/09/2012 12:06 PM, Frank Schäfer wrote:
> Forget this sh... (never do multiple things at the same time ;) )
>
> Reg 0x50 is set to according to rc_type specified in the selected remote
> control map.
> So if the correct map is selected, everything should be fine (as long as
> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).
>
> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
> the stick seems to use no NEC protocol.
>
> Matthew, insert a line
>
>          ir_config = 0x01;
>
> before
>
> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
>
> in em28xx-input.c and see if something shows up in the dmesg output.
>
> Regards,
> Frank

That seems to be a bit more successful!

Here is the dmesg output:

> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6
> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6
> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6
> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1, key 0x61d6
> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2, key 0x61d6
> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1, key 0x61d6
> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2, key 0x61d6

I pressed all the buttons on the remote (40 buttons).

Thanks,
Matthew
--
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
  

Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
> On 12/09/2012 12:06 PM, Frank Schäfer wrote:
>> Forget this sh... (never do multiple things at the same time ;) )
>>
>> Reg 0x50 is set to according to rc_type specified in the selected remote
>> control map.
>> So if the correct map is selected, everything should be fine (as long as
>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).
>>
>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
>> the stick seems to use no NEC protocol.
>>
>> Matthew, insert a line
>>
>>          ir_config = 0x01;
>>
>> before
>>
>> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
>>
>> in em28xx-input.c and see if something shows up in the dmesg output.
>>
>> Regards,
>> Frank
>
> That seems to be a bit more successful!
>
> Here is the dmesg output:
>
>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>> key 0x61d6
>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>> key 0x61d6
>
> I pressed all the buttons on the remote (40 buttons).

Did you cut the dmesg output ? Or do you really get these messages for
key 0x61d6 only ?

It seems like things are working different with reg 0x50 = 0x01. Taking
a look into the datasheet might help, but I don't have it. ;)

Regards,
Frank

>
> Thanks,
> Matthew

--
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
  

On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer
<fschaefer.oss@googlemail.com> wrote:
> Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
>> On 12/09/2012 12:06 PM, Frank Schäfer wrote:
>>> Forget this sh... (never do multiple things at the same time ;) )
>>>
>>> Reg 0x50 is set to according to rc_type specified in the selected remote
>>> control map.
>>> So if the correct map is selected, everything should be fine (as long as
>>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).
>>>
>>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
>>> the stick seems to use no NEC protocol.
>>>
>>> Matthew, insert a line
>>>
>>>          ir_config = 0x01;
>>>
>>> before
>>>
>>> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
>>>
>>> in em28xx-input.c and see if something shows up in the dmesg output.
>>>
>>> Regards,
>>> Frank
>>
>> That seems to be a bit more successful!
>>
>> Here is the dmesg output:
>>
>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>>> key 0x61d6
>>
>> I pressed all the buttons on the remote (40 buttons).
>
> Did you cut the dmesg output ? Or do you really get these messages for
> key 0x61d6 only ?
>
> It seems like things are working different with reg 0x50 = 0x01. Taking
> a look into the datasheet might help, but I don't have it. ;)

Setting that bit turns off NEC parity checking.  I don't think we've
ever had a need for it before, which is why it isn't exposed as
configurable functionality in the driver.

No clear answer on how this should be fixed, if that's what is really
required.  I guess in theory we could introduce some new board config
option, but that would likely interfere with the ability to
reconfigure the RC protocol at runtime.  An alternative would be a new
property of the RC profile, but that would pollute the definition of
the struct presumably to work around some bug in a crappy remote
control.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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
  

On 2012-12-10 10:39, Frank Schäfer wrote:
> Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
>> On 12/09/2012 12:06 PM, Frank Schäfer wrote:
>>> Forget this sh... (never do multiple things at the same time ;) )
>>>
>>> Reg 0x50 is set to according to rc_type specified in the selected 
>>> remote
>>> control map.
>>> So if the correct map is selected, everything should be fine (as 
>>> long as
>>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others 
>>> yet).
>>>
>>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, 
>>> so
>>> the stick seems to use no NEC protocol.
>>>
>>> Matthew, insert a line
>>>
>>>          ir_config = 0x01;
>>>
>>> before
>>>
>>> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 
>>> 1);
>>>
>>> in em28xx-input.c and see if something shows up in the dmesg 
>>> output.
>>>
>>> Regards,
>>> Frank
>>
>> That seems to be a bit more successful!
>>
>> Here is the dmesg output:
>>
>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep 
>>> handle
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 
>>> 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 
>>> 2,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 
>>> 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 
>>> 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 
>>> 2,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 
>>> 1,
>>> key 0x61d6
>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 
>>> 2,
>>> key 0x61d6
>>
>> I pressed all the buttons on the remote (40 buttons).
>
> Did you cut the dmesg output ? Or do you really get these messages 
> for
> key 0x61d6 only ?
>

Correct, I got these messages for key 0x61d6 regardless of the physical 
key pressed.

> It seems like things are working different with reg 0x50 = 0x01. 
> Taking
> a look into the datasheet might help, but I don't have it. ;)
>
> Regards,
> Frank
>
>>
>> Thanks,
>> Matthew

--
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
  

Am 10.12.2012 16:46, schrieb Devin Heitmueller:
> On Mon, Dec 10, 2012 at 10:39 AM, Frank Schäfer
> <fschaefer.oss@googlemail.com> wrote:
>> Am 09.12.2012 18:53, schrieb Matthew Gyurgyik:
>>> On 12/09/2012 12:06 PM, Frank Schäfer wrote:
>>>> Forget this sh... (never do multiple things at the same time ;) )
>>>>
>>>> Reg 0x50 is set to according to rc_type specified in the selected remote
>>>> control map.
>>>> So if the correct map is selected, everything should be fine (as long as
>>>> it is RC_TYPE_NEC or RC_TYPE_RC5 because we don't support others yet).
>>>>
>>>> RC_MAP_KWORLD_315U and RC_MAP_MSI_DIGIVOX_III are both RC_TYPE_NEC, so
>>>> the stick seems to use no NEC protocol.
>>>>
>>>> Matthew, insert a line
>>>>
>>>>          ir_config = 0x01;
>>>>
>>>> before
>>>>
>>>> 380        em28xx_write_regs(dev, EM2874_R50_IR_CONFIG, &ir_config, 1);
>>>>
>>>> in em28xx-input.c and see if something shows up in the dmesg output.
>>>>
>>>> Regards,
>>>> Frank
>>> That seems to be a bit more successful!
>>>
>>> Here is the dmesg output:
>>>
>>>> [root@tux ~]# dmesg -t | sort | uniq | grep 'em28xx IR' | grep handle
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 0, count: 2,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: 6em28xx_ir_handle_key: toggle: 1, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 0, count: 2,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 1,
>>>> key 0x61d6
>>>> em28xx IR (em28xx #0)/ir: em28xx_ir_handle_key: toggle: 1, count: 2,
>>>> key 0x61d6
>>> I pressed all the buttons on the remote (40 buttons).
>> Did you cut the dmesg output ? Or do you really get these messages for
>> key 0x61d6 only ?
>>
>> It seems like things are working different with reg 0x50 = 0x01. Taking
>> a look into the datasheet might help, but I don't have it. ;)
> Setting that bit turns off NEC parity checking.  I don't think we've
> ever had a need for it before, which is why it isn't exposed as
> configurable functionality in the driver.
>
> No clear answer on how this should be fixed, if that's what is really
> required.  I guess in theory we could introduce some new board config
> option, but that would likely interfere with the ability to
> reconfigure the RC protocol at runtime.  An alternative would be a new
> property of the RC profile, but that would pollute the definition of
> the struct presumably to work around some bug in a crappy remote
> control.

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...

Regards,
Frank
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com

--
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
  

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.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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
  

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.

regards
Antti
  

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 ?

Regards
Frank
--
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
  

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.


regards
Antti
  

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 ?

Regards,
Frank


>
> regards
> Antti
>
>

--
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
  

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 ?

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. 
What I understand David Härdeman has done some work toward that too, but 
it is not ready.
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
  

Am 11.12.2012 21:59, schrieb Antti Palosaari:
> 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 ?
>
> 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. What I understand David Härdeman has done some work toward that
> too, but it is not ready.
> 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.

Yes, checking for inverted address and key code bytes would be a
possibility...
OTOH it's a kind of hack and I think this issue should be fixed in th rc
core.

A possible solution would be to add three new RC_TYPEs (e.g.
RC_TYPE_NEC_STD, RC_TYPE_NEC_EXT, RC_TYPE_NEC_FULL).
RC_TYPE_NEC can be kept for compatibility but should be marked as
deprecated.

Hmmm... thinking about it for some minutes... Why the hell do we bind rc
maps to protocols ?
A key map consists of pairs of a scan code and the corresponding key
code. But that's common to all protocols, right ?
So why do we restrict a keymap to a specific protocol ?
Ok, rc_type is a bit field, so a key map can be bound to multiple protocols.
But then we can't use it to configure the hardware driver, which is
exactly out problem here...

> I am quite sure em28xx hardware supports reading all 4 bytes, but if
> not, you will need to do some other tricks.

Yes, reading 4 bytes form the hardware seems to supported.

Devin, how does it works with reg 0x50=0x01 ?
Have I understood you right that it means the 32bit NEC protocol variant
is used ?
Can the key code be read as usual from regs 0x52-0x55 ?
Any changes in reg 0x51 ?
And for that matter - what's the meaning of bit 1 in reg 0x50 ? ;)

Regards,
Frank

>
> regards
> Antti
>

--
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
  

Am 12.12.2012 22:25, schrieb Frank Schäfer:

...
> Am 11.12.2012 21:59, schrieb Antti Palosaari:
>> 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.
> Yes, checking for inverted address and key code bytes would be a
> possibility...

The problem here is of course, that we have to configure the device first.
So we need to know the protocol variant before getting any bytes from
the device...

Frank
--
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
  

On 12/12/2012 11:34 PM, Frank Schäfer wrote:
> Am 12.12.2012 22:25, schrieb Frank Schäfer:
>
> ...
>> Am 11.12.2012 21:59, schrieb Antti Palosaari:
>>> 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.
>> Yes, checking for inverted address and key code bytes would be a
>> possibility...
>
> The problem here is of course, that we have to configure the device first.
> So we need to know the protocol variant before getting any bytes from
> the device...

No, you now don't see the point correctly. If you read 4 byte "full NEC" 
code from the hardware, you will not need to know which variant it is 
for configure hardware. 4 byte, full NEC, presents all the variants.

Think it like NEC code is always 4 byte long as lower layer. All NEC 
remotes sends 4 byte codes regardless which variant. In receiver side, 
after decoding there is also 4 byte always. Variants are done very upper 
layer after decoding.

Let me take some existing examples:
------------------
rc-trekstor.c:	{ 0x0084, KEY_0 },
This is actually 1 byte NEC, which is device id == 0.
4 byte real code is: 00 ff 84 7b
------------------
rc-terratec-slim-2.c:	{ 0x800d, KEY_0 },
This is normal, traditional, oldest, most common, 2 byte NEC.
4 byte real code is: 80 7f 0d f2
------------------
rc-terratec-slim.c:	{ 0x02bd09, KEY_0 },
Extended NEC, quite common, 3 byte NEC.
4 byte real code is: 02 bd 09 f6
------------------
rc-tivo.c:	{ 0xa10c8c03, KEY_NUMERIC_0 },
"full" NEC, 4 byte NEC.
Not very common, but coming slowly more popular.
4 byte real code is: a1 0c 8c 03


As you can see all NEC variants could be presented as 4 byte NEC. Even 
the "one byte NEC", which comes in that case (rc-trekstor.c) "00 ff 84 
7b" as 4 byte real notation.


regards
Antti
  

Am 13.12.2012 16:09, schrieb Antti Palosaari:
> On 12/12/2012 11:34 PM, Frank Schäfer wrote:
>> Am 12.12.2012 22:25, schrieb Frank Schäfer:
>>
>> ...
>>> Am 11.12.2012 21:59, schrieb Antti Palosaari:
>>>> 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.
>>> Yes, checking for inverted address and key code bytes would be a
>>> possibility...
>>
>> The problem here is of course, that we have to configure the device
>> first.
>> So we need to know the protocol variant before getting any bytes from
>> the device...
>
> No, you now don't see the point correctly. If you read 4 byte "full
> NEC" code from the hardware, you will not need to know which variant
> it is for configure hardware. 4 byte, full NEC, presents all the
> variants.
>
> Think it like NEC code is always 4 byte long as lower layer. All NEC
> remotes sends 4 byte codes regardless which variant. In receiver side,
> after decoding there is also 4 byte always. Variants are done very
> upper layer after decoding.
>
> Let me take some existing examples:
> ------------------
> rc-trekstor.c:    { 0x0084, KEY_0 },
> This is actually 1 byte NEC, which is device id == 0.
> 4 byte real code is: 00 ff 84 7b
> ------------------
> rc-terratec-slim-2.c:    { 0x800d, KEY_0 },
> This is normal, traditional, oldest, most common, 2 byte NEC.
> 4 byte real code is: 80 7f 0d f2
> ------------------
> rc-terratec-slim.c:    { 0x02bd09, KEY_0 },
> Extended NEC, quite common, 3 byte NEC.
> 4 byte real code is: 02 bd 09 f6
> ------------------
> rc-tivo.c:    { 0xa10c8c03, KEY_NUMERIC_0 },
> "full" NEC, 4 byte NEC.
> Not very common, but coming slowly more popular.
> 4 byte real code is: a1 0c 8c 03
>
>
> As you can see all NEC variants could be presented as 4 byte NEC. Even
> the "one byte NEC", which comes in that case (rc-trekstor.c) "00 ff 84
> 7b" as 4 byte real notation.

Sure, we always get 4 bytes from the hardware.
But there must be a difference on the hardware level, otherwise the
em2874 wouldn't use different values for reg 0x50 (and Matthew should
see messages for ALL keys).

Regards,
Frank

>
>
> regards
> Antti
>

--
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
  

Em Mon, 10 Dec 2012 20:24:23 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> 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.

It is not the current NEC implementation at the driver; it is, instead,
a hardware issue. At least on the tests I did in the past with em28xx
and remote controllers capable of producing 32 bit keycodes, the NEC
hardware decoder inside em28xx were only providing 16 bits.

Regards,
Mauro
--
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
  

Em Mon, 10 Dec 2012 11:13:07 -0500
Devin Heitmueller <dheitmueller@kernellabs.com> escreveu:

> 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.

Hmm... that explains why em28xx weren't working properly with NEC extended
codes ;)

IMO, the better is to set it for NEC, and let the driver to do the parity
check, in order to properly handle the variants of the NEC protocol (16, 24
or 32 bits).

Due to the way the RC keycode is stored, there's no risk on keeping it
disabled, as a keycode generated by a 16-bit NEC remote with a parity
error will produce a 24 or 32 bits keycode. Such keycode will be discarded
for a keytable with 16 bits keycodes.

Regards,
Mauro.
--
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
  

Em Tue, 11 Dec 2012 21:51:34 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> 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

Actually, on both above, AFAIKT, instead of "key code", the last 8
bits are called as "command code" at the specs.
> >
> > 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.

On all 32-bits NEC IR's I tested, this is mapped as:

address code = AABBCC
command code = DD

Regards,
Mauro
--
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
  

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
--
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
  

Em Thu, 13 Dec 2012 18:07:16 -0200
Mauro Carvalho Chehab <mchehab@redhat.com> escreveu:

> Em Tue, 11 Dec 2012 21:51:34 +0100
> Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:
> 
> > 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
> 
> Actually, on both above, AFAIKT, instead of "key code", the last 8
> bits are called as "command code" at the specs.
> > >
> > > 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.
> 
> On all 32-bits NEC IR's I tested, this is mapped as:
> 
> address code = AABBCC
> command code = DD

Hmm... actually, tivo NEC IR seems to be, instead:

address code = AABB
command code = CCDD

       	{ 0xa10c900f, KEY_MEDIA },      /* TiVo Button */
        { 0xa10c0807, KEY_POWER2 },     /* TV Power */
       	{ 0xa10c8807, KEY_TV },         /* Live TV/Swap */
        { 0xa10c2c03, KEY_VIDEO_NEXT }, /* TV Input */
        { 0xa10cc807, KEY_INFO },
        { 0xa10cfa05, KEY_CYCLEWINDOWS }, /* Window */
        { 0x0085305f, KEY_CYCLEWINDOWS },
        { 0xa10c6c03, KEY_EPG },        /* Guide */

(I guess that the second KEY_CYCLEWINDOWS is likely due to some different
IR device - the same 0x0085 pattern with duplicated keycode also happens
on key '8' on this table).

It should be noticed that those 24/32 bit "extended-NEC" aren't part of the
NEC protocol specs, AFAIKT. It is just some manufacturer's decision to use
a NEC chip to produce non-parity scancodes.

The manufacturer can obviously do whatever it wants with the protocol 
keycode, either using some standard, or to inventing their own way.
That's one of the reasons why we don't split the code into address/command
inside the RC core. Tthe other one is that a table lookup is simpler than
if this were broken into two separate fields.

Regards,
Mauro
--
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
  

Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
> 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:
>>>>> 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
> 	...

So 0x6143 is not the same as 0x006143 and 0x00006143 ???

And even when assuming that 00 bytes are unused: do you really think the
driver should parse the whole rc map and check all scancodes to find out
which sub-protocol is used ?


> 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.

No, if AA != ~BB it can't be 16 bit, but if AA == ~BB, it can still be
16, 24 or 32bit !

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

Right, if CC != ~DD it must be 32 bit.


So what if we get 52 AD 76 89 from the hardware ? This can be 32, 24 or
16 bit !


Anyway, first we have to GET the bytes from the hardware. That's our
current problem !
And the hardware seems to need a different setup for reg 0x50 for the
different NEC sub protocols.
Which means that the we need to know the sub protocol BEFORE we get any
bytes from the device.

Regards,
Frank


--
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
  

Em Fri, 14 Dec 2012 16:33:34 +0100
Frank Schäfer <fschaefer.oss@googlemail.com> escreveu:

> Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
> > 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:
> >>>>> 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
> > 	...
> 
> So 0x6143 is not the same as 0x006143 and 0x00006143 ???
> 
> And even when assuming that 00 bytes are unused: 

I never seen that.

> do you really think the
> driver should parse the whole rc map and check all scancodes to find out
> which sub-protocol is used ?

Scancode search can use a b-tree (I think it currently does).

In any case, the typical usage is that the IR table will match the
IR device in usage. So, a not-found scancode just means that some
error happened during the transmission.

> > On a 24-bit NEC table: AA is always different than ~BB, otherwise, it would
> > be a 16-bit NEC.
> 
> No, if AA != ~BB it can't be 16 bit, but if AA == ~BB, it can still be
> 16, 24 or 32bit !

Have you ever seen any remote using something like that??? 

The hole point of the IR address is to distinguish a given IR device from the
others. The specs define specific addresses for VCR, TV Set, DVD, etc.

So, no, if AA == ~BB it must be a 16 or 24 bits NEC protocol, as there's just 8
bits (or 16 bits) to differentiate the IR address for a given remote 
from other NEC IR addresses.

> > On a 32-bit NEC table: CC is always different than ~DD, otherwise, it would be
> > a 24-bit NEC.
> 
> Right, if CC != ~DD it must be 32 bit.
> 
> 
> So what if we get 52 AD 76 89 from the hardware ? This can be 32, 24 or
> 16 bit !

It is 16 bits, except if someone at the manufacturer is completely
senseless, and explicitly wants to cause troubles to their customers
by using an IR address and IR commands that could be produced by
some other vendor's remotes.

In any case, the RC core will still support such crappy device, as the
IR keytable can have a mix of 16 bits/24 bits/32 bits NEC codes inside
it.

We do have some tables with multiple IR's inside. For example, the
Hauppauge RC5 table contains keycodes for 3 different types of Hauppauge
controls. The same happens to one NEC's terratec table, where we're
storing there both the codes of different IR models.

The rationale is that the same board may be sold with different remotes.

> Anyway, first we have to GET the bytes from the hardware. That's our
> current problem !
> And the hardware seems to need a different setup for reg 0x50 for the
> different NEC sub protocols.
> Which means that the we need to know the sub protocol BEFORE we get any
> bytes from the device.

No. All em28xx needs is to make sure that the NEC protocol will return
the full 32 bits scancode.

Regards,
Mauro
--
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
  

On Tue, Dec 11, 2012 at 10:59:06PM +0200, Antti Palosaari wrote:
>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. What I understand David Härdeman has done some work toward that
>too, but it is not ready.

Correct. Still working on it. The main problem is providing it in
a sensibly backwards-compatible manner. I will post patches to the ML
again once it is ready.