Linux Infrared Remote Control

On Apr 1, 2011, at 5:35 AM, john.99.doe wrote:

> Hi.
> 
> ubuntu 10.04.2
> 
> uname -a
> Linux jd-note 2.6.38-02063801-generic #201103241244 SMP Thu Mar 24 12:47:57 UTC 2011 x86_64 GNU/Linux
> 
> lsmod | grep ir
> ir_lirc_codec          12898  0 
> ir_sony_decoder        12549  0 
> ir_jvc_decoder         12546  0 
> lirc_dev               19314  1 ir_lirc_codec
> ir_rc6_decoder         12579  0 
> ir_rc5_decoder         12546  0 
> ir_nec_decoder         12546  0 
> rc_core                26978  9 ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,rc_rc6_mce,ir_nec_decoder,mceusb
> 
> cat /proc/bus/input/devices
> I: Bus=0003 Vendor=0471 Product=0815 Version=0000
> N: Name="Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)"
> P: Phys=usb-0000:00:13.2-1
> S: Sysfs=/devices/pci0000:00/0000:00:13.2/usb4/4-1/4-1:1.0/rc/rc1/input12
> U: Uniq=
> H: Handlers=kbd event8 
> B: PROP=0
> B: EV=100013
> B: KEY=fff 0 200108fc326 237605100000000 0 700158000 419200100001 9e968000000000 10000000
> B: MSC=10
> 
> #/etc/udev/rules.d/85-lirc.rules
> #These rules are currently only adapted for a single lirc device.
> #They are mainly used for hotplugability of the USB devices
> #So that the user won't have to restart the lircd process.
> #
> #If a user has multiple lirc devices, and removes one of them
> #The other will stop working as well.  This is a side effect
> #of both this udev script as well as the lirc architecture
> #Of chaining lircd processes.
> ACTION=="add", KERNEL=="lirc[0-9]", RUN="/etc/init.d/lirc restart udev"
> ACTION=="remove", KERNEL=="lirc[0-9]", RUN="/etc/init.d/lirc stop udev"
> 
> 
> 1. remove lirc 0.8.6
> 2. compile and install lirc-0.9.0.tar.bz2 
> 3. copy /contrib/lirc.debian to /etc/init.d/lirc
> 4. copy /remotes/devinput/lircd.conf.devinput to /etc/lirc/lircd.conf
> 5. 
> # /etc/lirc/hardware.conf
> #
> #Chosen Remote Control
> REMOTE="Windows Media Center Transceivers/Remotes (all)"
> REMOTE_MODULES=""
> #REMOTE_MODULES="lirc_dev lirc_mceusb"
> REMOTE_DRIVER="devinput"
> #REMOTE_DEVICE="/dev/lirc0"
> REMOTE_DEVICE="/dev/input/by-id/usb-Philips_eHome_Infrared_Transceiver_PH00FSHo-event-if00"
> #REMOTE_DEVICE="/dev/input/event7"
> REMOTE_SOCKET=""
> #REMOTE_LIRCD_CONF="mceusb/lircd.conf.mceusb"
> REMOTE_LIRCD_CONF="/etc/lirc/lircd.conf"
> REMOTE_LIRCD_ARGS=""
> 
> #Chosen IR Transmitter
> TRANSMITTER="None"
> TRANSMITTER_MODULES=""
> TRANSMITTER_DRIVER=""
> TRANSMITTER_DEVICE=""
> TRANSMITTER_SOCKET=""
> TRANSMITTER_LIRCD_CONF=""
> TRANSMITTER_LIRCD_ARGS=""
> 
> #Enable lircd
> START_LIRCD="true"
> 
> #Don't start lircmd even if there seems to be a good config file
> #START_LIRCMD="false"
> 
> #Try to load appropriate kernel modules
> LOAD_MODULES="true"
> #LOAD_MODULES="false"
> 
> # Default configuration files for your hardware if any
> LIRCMD_CONF=""
> 
> #Forcing noninteractive reconfiguration
> #If lirc is to be reconfigured by an external application
> #that doesn't have a debconf frontend available, the noninteractive
> #frontend can be invoked and set to parse REMOTE and TRANSMITTER
> #It will then populate all other variables without any user input
> #If you would like to configure lirc via standard methods, be sure
> #to leave this set to "false"
> FORCE_NONINTERACTIVE_RECONFIGURATION="false"
> START_LIRCMD=""
> 6. 
> evtest /dev/input/event8
> Input driver version is 1.0.1
> Input device ID: bus 0x3 vendor 0x471 product 0x815 version 0x0
> Input device name: "Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)"
> Supported events:
>  Event type 0 (Sync)
>  Event type 1 (Key)
>    Event code 28 (Enter)
>    Event code 103 (Up)
>    Event code 105 (Left)
>    Event code 106 (Right)
>    Event code 108 (Down)
>    Event code 111 (Delete)
>    Event code 113 (Mute)
>    Event code 114 (VolumeDown)
>    Event code 115 (VolumeUp)
>    Event code 116 (Power)
>    Event code 119 (Pause)
>    Event code 128 (Stop)
>    Event code 148 (Prog1)
>    Event code 161 (EjectCD)
>    Event code 164 (PlayPause)
>    Event code 167 (Record)
>    Event code 168 (Rewind)
>    Event code 174 (Exit)
>    Event code 207 (Play)
>    Event code 208 (Fast Forward)
>    Event code 210 (Print)
>    Event code 212 (Camera)
>    Event code 224 (Brightness down)
>    Event code 225 (Brightness up)
>    Event code 226 (Media)
>    Event code 352 (Ok)
>    Event code 356 (Power2)
>    Event code 358 (Info)
>    Event code 365 (EPG)
>    Event code 366 (PVR)
>    Event code 368 (Language)
>    Event code 369 (Title)
>    Event code 370 (Subtitle)
>    Event code 372 (Zoom)
>    Event code 373 (Mode)
>    Event code 377 (TV)
>    Event code 385 (Radio)
>    Event code 386 (Tuner)
>    Event code 389 (DVD)
>    Event code 392 (Audio)
>    Event code 393 (Video)
>    Event code 398 (Red)
>    Event code 399 (Green)
>    Event code 400 (Yellow)
>    Event code 401 (Blue)
>    Event code 402 (ChannelUp)
>    Event code 403 (ChannelDown)
>    Event code 407 (Next)
>    Event code 412 (Previous)
>    Event code 425 (?)
>    Event code 512 (?)
>    Event code 513 (?)
>    Event code 514 (?)
>    Event code 515 (?)
>    Event code 516 (?)
>    Event code 517 (?)
>    Event code 518 (?)
>    Event code 519 (?)
>    Event code 520 (?)
>    Event code 521 (?)
>    Event code 522 (?)
>    Event code 523 (?)
>  Event type 4 (Misc)
>    Event code 4 (ScanCode)
>  Event type 20 (Repeat)
> Testing ... (interrupt to exit)
> Event: time 1301506625.166664, type 4 (Misc), code 4 (ScanCode), value 800f0416
> Event: time 1301506625.166695, type 1 (Key), code 207 (Play), value 1
> Event: time 1301506625.166699, -------------- Report Sync ------------
> Event: time 1301506625.273672, type 4 (Misc), code 4 (ScanCode), value 800f0416
> Event: time 1301506625.521935, type 1 (Key), code 207 (Play), value 0
> 7. sudo /etc/init.d/lirc restart
> Stopping lirc daemon: lircmd lircd
> Starting lirc daemon: lircdlircd: can't open or create /var/run/lirc/lircd.pid
> lircd: No such file or directory
> lircmdlircmd: could not connect to socket
> lircmd: No such file or directory
> .
> 8.  /usr/local/sbin/lircd --nodaemon --output=/var/run/lirc/lircd --device=/dev/input/event8

If you're using an input event device, you need to also tell lircd
to use devinput mode. (lircd --driver=devinput).

> lircd: can't open or create /var/run/lirc/lircd.pid
> lircd: No such file or directory
> 9. create /var/run/lirc
> sudo /etc/init.d/lirc restart
> Stopping lirc daemon: lircmd lircd
> Starting lirc daemon: lircd lircmd.
> in other console irw has no reaction to press button
> 10. in /etc/X11/xorg.conf write section
> 
> Section "InputClass"
>   Identifier "Ignore MCE Remote" # произвольное название
>   MatchProduct "Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)"
>   MatchIsKeyboard "true"
>   Option "Ignore" "true"
> Endsection
> 
> I want to use ~/.lircrc not as the keyboard.
> 
> What have I missed? Thanks.

# echo lirc > /sys/class/rc/rc0/protocols

That will disable in-kernel decode, and leave only the device's lirc
interface receiving data. Or feed the right options to lircd to use
devinput mode.

-- 
Jarod Wilson
jarod@...

On Apr 5, 2011, at 1:11 AM, john.99.doe wrote:

> lircd 0.9.0 configured devinput
> 
> why not exist /var/run/lirc after restart? witch script must create this?
> 
> /usr/local/sbin/lircd --nodaemon --driver=devinput 
> --output=/var/run/lirc/lircd --device=/dev/input/event5
> lircd: lircd(devinput) ready, using /var/run/lirc/lircd
> 
> in other console start irw
> 
> in first console answer
> lircd: accepted new client on /var/run/lirc/lircd
> lircd: initializing '/dev/input/event5'
> lircd: WARNING: can't get exclusive access to events coming from 
> `/dev/input/event5' interface
> 
> irw has no reaction to key press

Are you sure event5 is the right device? Your prior mail had event8.
I suggest using the /dev/input/by-id/<foo> symlink instead.

-- 
Jarod Wilson
jarod@...

> On Apr 5, 2011, at 1:11 AM, john.99.doe wrote:
>
>> lircd 0.9.0 configured devinput
>>
>> why not exist /var/run/lirc after restart? witch script must create this?
>>
>> /usr/local/sbin/lircd --nodaemon --driver=devinput
>> --output=/var/run/lirc/lircd --device=/dev/input/event5
>> lircd: lircd(devinput) ready, using /var/run/lirc/lircd
>>
>> in other console start irw
>>
>> in first console answer
>> lircd: accepted new client on /var/run/lirc/lircd
>> lircd: initializing '/dev/input/event5'
>> lircd: WARNING: can't get exclusive access to events coming from
>> `/dev/input/event5' interface
>>
>> irw has no reaction to key press
>
> Are you sure event5 is the right device? Your prior mail had event8.
> I suggest using the /dev/input/by-id/<foo>  symlink instead.
>
Yes. /dev/input/event5 and /dev/input/event8 right device.
At first to adjust a chain.(lircd+irw=reactions ) Then correctly to 
specify options in hardware.conf.

From: Simon Haines <simon.haines@......> - 2011-04-12 09:27

Attachments: Message as HTML     

Try using 'evtest' to get diagnostic information on what driver is providing
the events to /dev/input/event5, and what events are being generated.
Simon.


On 10 April 2011 16:42, John Doe <john.99.doe@...> wrote:

> Доброе время суток, Jarod Wilson.
> Вы писали 08.04.2011 23:56
> > On Apr 5, 2011, at 1:11 AM, john.99.doe wrote:
> >
> >> lircd 0.9.0 configured devinput
> >>
> >> why not exist /var/run/lirc after restart? witch script must create
> this?
> >>
> >> /usr/local/sbin/lircd --nodaemon --driver=devinput
> >> --output=/var/run/lirc/lircd --device=/dev/input/event5
> >> lircd: lircd(devinput) ready, using /var/run/lirc/lircd
> >>
> >> in other console start irw
> >>
> >> in first console answer
> >> lircd: accepted new client on /var/run/lirc/lircd
> >> lircd: initializing '/dev/input/event5'
> >> lircd: WARNING: can't get exclusive access to events coming from
> >> `/dev/input/event5' interface
> >>
> >> irw has no reaction to key press
> >
> > Are you sure event5 is the right device? Your prior mail had event8.
> > I suggest using the /dev/input/by-id/<foo>  symlink instead.
> >
> Yes. /dev/input/event5 and /dev/input/event8 right device.
> At first to adjust a chain.(lircd+irw=reactions ) Then correctly to
> specify options in hardware.conf.
>
>
> ------------------------------------------------------------------------------
> Forrester Wave Report - Recovery time is now measured in hours and minutes
> not days. Key insights are discussed in the 2010 Forrester Wave Report as
> part of an in-depth evaluation of disaster recovery service providers.
> Forrester found the best-in-class provider in terms of services and vision.
> Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo

On Apr 14, 2011, at 12:35 AM, john.99.doe wrote:

> The device is chosen correctly. At first in mc I look to what 
> /dev/input/eventX there corresponds the receiver, then check commands in 
> the console. Correcting if it is necessary. evtest sees the data from the 
> receiver normally.

If evtest works, then I haven't a clue why lircd in devinput mode
wouldn't work.

> Has described in the first message.

I don't have the first message handy anymore, and you've omitted
too much context for me to recall what it contained. Currently,
I don't even recall what hardware you're using.

-- 
Jarod Wilson
jarod@...

Please keep the list cc'd.

On Apr 25, 2011, at 6:41 PM, Stephen E. Baker wrote:

> On Mon, Apr 25, 2011 at 10:55 AM, Jarod Wilson <jarod@...> wrote:
>> On Apr 24, 2011, at 8:55 AM, Stephen E. Baker wrote:
>> 
>>> My Antec Veris Multimedia Station Basic (15c2:0043) was functioning in
>>> the past.  At some upgrade (I'm not sure if it was kernel or lirc or
>>> which version) the buttons stopped responding.  I am now on linux
>>> 2.6.38.3 and lirc 0.9 (Arch Linux)
>>> 
>>> I read that the drivers are built into the kernel now and that I
>>> should be using devinput, and setting the device explicitely, which
>>> I've done, setting the device to:
>>> /dev/input/by-id/usb-15c2_0043-event-if00.
>>> 
>>> After this setting the protocol to 'lirc' in ir-keytable allows some
>>> of the buttons to work:
>> 
>> Setting protocol to 'lirc' makes no sense at all on this hardware.
>> The valid options are RC-6 and Other. The 'lirc' protocol is only
>> for raw IR hardware, and it passes along raw IR samples via a
>> /dev/lircX device node.
>> 
>>> Up/Down/Left/Right, Volume Up/Down/Mute, and Channel Up register in
>>> irw, none of the others seem to respond.
>>> 
>>> I tried writting the keycodes for the RM100 from the lirc keymap file
>>> to an rc_keymap file and loading it with ir-keytable -w, with no
>>> improvement.  No buttons register in ir-keytable -t in rc-6 mode.
>> 
>> The RM-100 remote is protocol "Other", not RC-6. You should probably
>> not be using ir-keytable for anything at all with this hardware, it
>> should actually get the protocol and keymap correct right out of the
>> box by default.
>> 
> Tried:
> [root@... family]# echo Other > /sys/class/rc/rc0/protocols
> bash: echo: write error: Invalid argument
> 
> Same with "other"

Yeah, other is not valid right now, that's a kernel bug. I have a patch
that should fix it. You shouldn't need to echo anything though.

> I saw "Unknown" elsewhere which works and seems to be the default
> state. Using Unknown no button presses are registered in irw or
> ir-keytable -t.
> 
> "Driver imon, table rc-imon-pad" does not indicate a problem then?  I
> was suspicous of the rc-imon-pad line.

No. The signals for the RM-100 are the same as the signals for the
iMON Pad remote (aka RM-200), its all one keytable. I suppose the
keytable could stand to be renamed, but eh.


>>> Possibly unrelated but the following shows up in messages:
>>> Apr 19 16:33:20 localhost kernel: WARNING: at kernel/mutex-debug.c:78
>>> debug_mutex_unlock+0xdb/0xe0()
>> 
>> Hm. Just a warning from the lock debugger, and one which I can't
>> yet make heads or tails of. On the bright side, this shouldn't
>> happen if you don't unnecessarily run ir-keytable. :)
>> 
> Still seeing:
> Apr 25 18:28:41 localhost kernel: [    9.726307] Pid: 2499, comm:
> ir-keytable Not tainted 2.6.38-ARCH #1
> 
> I'm not sure how that is coming up, ir-keytable is not part of init;
> so unless it's being pulled in by a kernel hook?

Its a udev hook, see /etc/udev/rules.d/70-infrared.rules (at least,
that's where the rule file winds up on Fedora). Just comment it out.
I still need to try to reproduce the problem here...

-- 
Jarod Wilson
jarod@...