On 2011-04-27 14:28, Jarod Wilson wrote:
> On Apr 25, 2011, at 5:06 PM, Heiko Baums wrote:
>
>> Am Mon, 25 Apr 2011 14:34:35 -0400
>> schrieb Jarod Wilson<jarod@...>:
>>
>>> Ah, okay, sorry. Have you tried enabling all of them at once, and then
>>> run ir-keytable in test mode? (ir-keytable -t). It *should* spit out
>>> at least some scancode data, if not keycode data, if any of the
>>> in-kernel decoders are actually able to decode the signals.
>> How do I enable all protocols at once?
>>
>> # cat "lirc rc-5 rc-6 ..."> /sys/class/rc/rc0/protocols
>> only activates the last protocol in this list.
> Prefix each proto with a "+" to add them to the active protocol list.
>
>> But I activated every protocol one after another and tried ir-keytable
>> -t for every protocol, but it didn't spit out anything.
> Hrm, not so good... May need to enable rc-core debugging, and/or hit
> up the linux-media list to find folks more familiar with this hardware
> and the IR support for it.
>
>>> If none of the in-kernel decoders are working, then this is entirely
>>> expected. Lets back up a step and see if we can figure out why the
>>> in-kernel decoders apparently aren't functional.
>> Can this have something to do with this line in /proc/bus/input/devices?
>> H: Handlers=kbd event3
>> I mean, that the kernel or whatever is using the kbd handler instead of
>> event3?
> Not sure.
>
>
>>>> irw doesn't do anything and my keyboard also
>>>> doesn't work anymore with this config.
>>> Keyboard? Which keyboard?...
>> This funny, flat item with all the letters and numbers, on which you
>> always tap your fingers to e.g. write your e-mails. ;-)
> Heh. I can't see that I've ever seen a keyboard stop working due to any
> of the IR subsystem changes, thus my confusion... :)
>
>
>>>> No, it's not Fedora, it's Arch Linux.
>>> Okay, good to know. Their latest 2.6.38.x-based kernel? Also, on boot,
>>> am I understanding you correctly, that the initial state for the
>>> decoders is that *all* are disabled?...
>> The latest kernel is 2.6.38.3. Today - right now - it was updated to
>> 2.6.38.4.
>>
>> You're understanding me correctly. The initial state on boot for the
>> protocols - I guess this is what you mean with decoders - is that *all*
>> are disabled.
> Yeah, sorry, the "IR protocol decoders", which I routinely shorten to either
> just "protocols" or just "decoders". Anyway, all being disabled is... Odd.
>
>
>> There's a feature request for enabling lirc on boot:
>> https://bugs.archlinux.org/task/23673
> Setting it as the only active protocol decoder when starting lircd makes
> sense when using the receiver via /dev/lircX. But its rather odd to me
> that all protocols are disabled on boot.
>
> Okay, dug a bit more... The default map for the 1400 should be NEC proto.
> I'd enable rc-core debugging (options rc-core debug=1) and it looks like
> the cx88 IR interrupt handler should spew some relevant interesting data.
> However, I'm definitely leaning towards this discussion moving over to
> the linux-media list, as the issue is somewhere in drivers/media/video/cx88/.
>
My cx88 card also has no protocols enabled. They're not supported either.
Found /sys/class/rc/rc0/ (/dev/input/event11) with:
Driver imon, table rc-imon-pad
Supported protocols: RC-6
Enabled protocols:
Repeat delay = 500 ms, repeat period = 33 ms
Found /sys/class/rc/rc1/ (/dev/input/event12) with:
Driver cx88xx, table rc-winfast
Supported protocols:
Enabled protocols:
Repeat delay = 500 ms, repeat period = 33 ms
evtest says, in part:
/dev/input/event10: iMON Panel, Knob and Mouse(15c2:0038)
/dev/input/event11: iMON Remote (15c2:0038)
/dev/input/event12: cx88 IR (WinFast DTV1000-T)
suggesting that this is not a raw IR device and not in need of protocol
decoders.
I still get keycodes from event12, which lircd maps through
lircd.conf.devinput successfully.
FWIW,
Douglas
|