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

[Antti Palosaari <crope@iki.fi>]

On 12/17/2012 01:17 PM, Matthew Gyurgyik wrote:
> 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

I tested Mauros patch with nanoStick T2 290e, using 24bit NEC remote - 
worked fine. Your patch is hard to read as it contains that remote patch 
too. But what I looked one difference which look suspicious - it is that:
.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,

could you remove and test?

If it is really that one, then there is a bug in Mauros patches and it 
breaks all devices having NEC remote mapped currently.

regards
Antti

-- 
http://palosaari.fi/