Re: Lirc damon running but no output in Fedora 14

[Krister H. <kr...@ha...>]

Thanks Jarod, but I still get no output after commenting out the lines at 
the end of the start() function:
#    if [ $retval -eq 0 ]; then
#        rcs=$(find -L /sys/class/rc/ -maxdepth 2 -name protocols 2> 
/dev/null)
#        for rc in $rcs
#        do
#           echo lirc > ${rc}
#        done
#    fi
#    return $retval
Did I missunderstand the hack?
Cheers
Krister
--------------------------------------------------
From: "Jarod Wilson" <ja...@wi...>
Sent: Tuesday, April 19, 2011 8:16 PM
To: "Krister Hallergard" <kr...@ha...>
Cc: <dcl...@op...>; <lir...@li...>
Subject: Re: Lirc damon running but no output in Fedora 14

> On Apr 19, 2011, at 2:43 PM, Krister Hallergard wrote:
>
>>
>> Jarod, I am afraid I do not know how to tweak /etc/init.d/lirc to not 
>> disable the native in-kernel decoders, nor how to switch to using the 
>> lirc interface.
>> I would rather wait for your fix of the initscript .
>
> Its actually pretty straight-forward to disable the disabling,
> just comment out the bits at the tail end of the start() function,
> which do the 'echo lirc > ${rc}'. It'll be a bit before I can sit
> down and fully flesh out a complete fix here, too many other tasks
> at hand right now...
>
>
>> --------------------------------------------------
>> From: "Jarod Wilson" <ja...@wi...>
>> Sent: Tuesday, April 19, 2011 7:17 PM
>> To: "Krister Hallergard" <kr...@ha...>
>> Cc: <dcl...@op...>; <lir...@li...>
>> Subject: Re: Lirc damon running but no output in Fedora 14
>>
>>> On Apr 19, 2011, at 12:25 PM, Krister Hallergard wrote:
>>>
>>>> Thanks Douglas and Jarod.  Yes this seems to be my problem.
>>>
>>> Close, but not quite...
>>>
>>>> [root@DESKTOP /]# dmesg | grep keymap
>>>> [    6.916127] Registered IR keymap rc-hauppauge-new
>>>>
>>>> [root@DESKTOP /]# ps -ef | grep lircd
>>>> root      1527     1  0 17:00 ?        00:00:00 
>>>> /usr/sbin/lircd --driver=dev/input --device=/dev/input/irremote
>>>> root      2772  2724  0 17:03 pts/3    00:00:00 grep --color=auto lircd
>>>>
>>>> No output - my /etc/lirc/lirc.conf is not recognized Have tried 
>>>> renaming is lirc.conf.devinput - no change.  Have tried to copy over 
>>>> the file /usr/share/lirc-remotes/devinput/lirc.conf.devinput -no 
>>>> change.  Should I generate my own lirc.conf.devinput?
>>>>
>>>> [root@DESKTOP mnt]# ir-keytable
>>>> Found /sys/class/rc/rc0/ (/dev/input/event5) with:
>>>>      Driver cx88xx, table rc-hauppauge-new
>>>>      Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
>>>>      Enabled protocols: LIRC
>>>>      Repeat delay = 500 ms, repeat period = 33 ms
>>>>
>>>> There is not output with ir-keytable -t or ir-keytable -s rc0 -t
>>>
>>> Yeah, per the ir-keytable output, the in-kernel decoders are all
>>> disabled, only the lirc bridge (which feeds data out to userspace
>>> via /dev/lirc0) is active. That's due to some bits in the latest
>>> Fedora lirc initscript, which obviously needs some fine-tuning so
>>> that its not doing that in the devinput case...
>>>
>>> So what's happening here is that you're trying to use devinput mode,
>>> but devinput mode won't ever yield any data, because the in-kernel
>>> decoders are disabled, so the IR is never decoded and matched against
>>> the in-kernel lookup tables to map to input events. For the moment,
>>> you'll need to either tweak /etc/init.d/lirc to not disable the native
>>> in-kernel decoders, or switch to using the lirc interface.
>>>
>>> I'll try to get the initscript fixed up so that it doesn't do such
>>> brain-dead things. Heh. So the IR *code* is all correct, but the
>>> initscript is doing something less-than-helpful in this case... :)
>>>
>>>
>>>> [root@DESKTOP /]# evtest /dev/input/event5
>>>> Input driver version is 1.0.0
>>>> Input device ID: bus 0x1 vendor 0x70 product 0x9002 version 0x1
>>>> Input device name: "cx88 IR (Hauppauge Nova-T DVB-T"
>>>> Supported events:
>>>> Event type 0 (Sync)
>>>> Event type 1 (Key)
>>> ....
>>>> Event type 4 (Misc)
>>>>  Event code 4 (ScanCode)
>>>> Event type 20 (Repeat)
>>>> Testing ... (interrupt to exit)
>>>> ***********************************************
>>>> This device is grabbed by another process.
>>>> No events are available to evtest while the
>>>> other grab is active.
>>>> In most cases, this is caused by an X driver,
>>>> try VT-switching and re-run evtest again.
>>>> ***********************************************
>>>> Wonder what the above means??
>>>
>>> lircd has probably already grabbed it.
>>>
>>>
>>> -- 
>>> Jarod Wilson
>>> ja...@wi...
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 10.0.1321 / Virus Database: 1500/3583 - Release Date: 04/19/11
>>>
>
> -- 
> Jarod Wilson
> ja...@wi...
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1321 / Virus Database: 1500/3583 - Release Date: 04/19/11
>
>