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

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

Hi Matthew,

Em 17-12-2012 09:17, Matthew Gyurgyik escreveu:
> On 12/17/2012 06:08 AM, Antti Palosaari wrote:
>> On 12/17/2012 11:33 AM, Antti Palosaari wrote:
>>> On 12/17/2012 03:37 AM, Matthew Gyurgyik wrote:
>>>> On 12/16/2012 08:26 PM, Antti Palosaari wrote:
>>>>> On 12/17/2012 03:09 AM, Matthew Gyurgyik wrote:
>>>>>> On 12/15/2012 06:21 PM, Frank Schäfer wrote:
>>>>>>>> Matthew, could you please validate your test results and try Mauros
>>>>>>>> patches ? If it doesn't work, please create another USB-log.
>>>>>>>>
>>>>>>
>>>>>> Sorry it took me so long to test the patch, but the results look
>>>>>> promising, I actually got various keycodes!
>>>>>>
>>>>>> dmesg: http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>
>>>>>> evtest was also generating output
>>>>>>
>>>>>> Event: time 1355705906.950551, type 4 (EV_MSC), code 4 (MSC_SCAN),
>>>>>> value
>>>>>> 61d618e7
>>>>>> Event: time 1355705906.950551, -------------- SYN_REPORT ------------
>>>>>>
>>>>>> This is the current patch I'm using:
>>>>>> http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt
>>>>>>
>>>>>> What needs to be done to generate a keymap file?
>>>>>>
>>>>>> Is there anything I can collect or try to do, to get channel scanning
>>>>>> working?
>>>>>>
>>>>>> Just let me know what you need me to do. I really appreciate all the
>>>>>> help!
>>>>>
>>>>> You don't need to do nothing as that remote is already there. Just
>>>>> ensure buttons are same and we are happy.
>>>>> http://lxr.free-electrons.com/source/drivers/media/IR/keymaps/rc-msi-digivox-iii.c?v=2.6.37
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> RC_MAP_MSI_DIGIVOX_III should be added to your device profile in order
>>>>> to load correct keytable by default. You could test it easily, just add
>>>>> following definition
>>>>>
>>>>> .ir_codes = RC_MAP_MSI_DIGIVOX_III,
>>>>>
>>>>> to em28xx-cards.c board config and it is all.
>>>>>
>>>>> regards
>>>>> Antti
>>>>>
>>>> Maybe I'm missing something but these are different key codes and
>>>> lengths.
>>>>
>>>> tux:~ $ echo 0x61d643bc | wc -c  # my dmesg dump
>>>> 11
>>>> tux:~ $ echo 0x61d601 | wc -c  # DIGIVOX mini III
>>>> 9
>>>
>>> 0x61d643bc == 0x61d643
>>> 0x61d601fe == 0x61d601
>>>
>>> Those are same codes, other (debug) is just 32bit full format. Last byte
>>> in that case is dropped out as it is used for parity check - formula: DD
>>> == ~DD
>>>
>>>> As I understand it, this was the whole reason for the patches that
>>>> Mauros wrote.
>>>
>>> Nope, the reason was it didn't support 32bit at all.
>>
>> I looked the patch and it seems like it should store and print 24bit
>> scancode for your remote. Maybe you didn't set default remote end it
>> fall back to unknown remote protocol which stores all bytes. Or some
>> other bug. Test it with default keytable (RC_MAP_MSI_DIGIVOX_III) and if
>> it does not output numbers there must be a bug. I am too lazy to test it
>> currently.
>>
>> regards
>> Antti
>>
>>
> I am using the RC_MAP_MSI_DIGIVOX_III mapping
>
> + .ir_codes     = RC_MAP_MSI_DIGIVOX_III,
> http://pyther.net/a/digivox_atsc/dec16/msi_digivox_atsc.patch

 From this log:
	http://pyther.net/a/digivox_atsc/dec16/dmesg_remote.txt

You clearly have a "standard" NEC-extended IR - e. g. 24 bits per scancode,
16 bits for address, 8 bits for command.

Instead of using evtest, I really recomend you to use ir-keytable
(part of v4l-utils package). You can compile it directly from our
git tree: http://git.linuxtv.org/v4l-utils.git with:
	$ autoreconf -vfi
	$ ./configure
	$ make
	# make install

The version there has a few updates to provide a more complete report.

In order to use it in test mode, you can just do:
	# ir-keycode -t

If your IR is at rc0 (otherwise, you'll need to use the "-s rc1" parameter).

It should print all events produced by an input device, including
the scancodes (EV_MSC) and keystrokes (EV_KEY).

One question: are you compiling a 32 bits or a 64 bits kernel? The is/were
a bug with gcc and switch() when a 64 bits int is used on switch. Maybe
we'll need to change the switch at the nec handling by a series of IFs
due to such bug.

Regards,
Mauro


>
> Matthew