Lirc not yet functional in 11.4

Hi Lizard friends,

Has anyone got LIRC up and running on 11.4? There are some basic built-in remote functions from imbedded IR drivers in kernel but no specific LIRC functionality. Will 11.4 need lirc-kmp-desktop etc?

Thank-you,
Wessel

Hi,

I’ve not got LIRC working on 11.4 either. I’ve got an iMon PAD USB receiver and remote and mouse movement and cursor arrows emulation work fine (even when uninstallint LIRC with zypper), however I do not get a /dev/lirc0 device that would pick up IR signals, thus I can not control/start applications.
I’ve read quite a few topics on setting up LIRC with udev (which replaced HAL in 11.4, IIRC), but none of the suggestions there work.
I’ve also tried to compile LIRC from sources with settings previously working (I think that was in 11.1) but still no device and thus no IR signals received.

I’d be very interested if anyone has got this working.

Cheers
Martin

Hi Martin,

Apparently from 2.6.37 onward popular IR drivers will start to be included in the kernel. I believe that this is something that Jerrod Wilson, the Red Hat engineer and Mythtv guru, is taking the lead on and from what I understand will one day make LIRC obsolete in Linux. And just like your remote, my lirc_mceusb based system also has some basic activity without LIRC installed so for both of us that must be coming from what’s now included standard in the kernel. The problem for me is only a few buttons work right now: arrows, volume up/down. The OK and Back button don’t work so it’s not enough as it is now for MythTV. I was hoping that maybe SUSE 11.4 would run without LIRC with a 2.6.37 kernel but since it doesn’t, I’m hoping the dev’s at SUSE will still build functional LIRC modules (lirc-kmp-desktop, lirc-kmp-default, ect) for the time being. I’m assuming that’s still possible but I don’t know. I haven’t tried to compile LIRC yet for 11.4. I haven’t ever been successful in building LIRC.

I’m going to try to search other forums as well for 2.6.37 kernel and LIRC, and not just SUSE, and see what I come up with.

Hi Wessel,

that sounds reasonable. I tried re-installing HAL but that made no difference.
I’ve found some information that LIRC 0.9 will be able to provide IR support for some remotes with the changes in the kernel, but I could not get my hand on that version, the git clone failed to compile as it was missing some scripts.
I’m afraid, we’ll have to wait a couple of weeks, until these issues are resolved.
Building LIRC is a bit of a PITA, but I usually get it working after some trial and error :slight_smile:

Cheers

Martin

Hi friends,

here not working lirc with 11.4. thinking to downgrade to 11.3.
i build lirc 0.9 but not working for me.

I apologize for my mistakes in English, I’m Basque, and you know how bad we are in foreign languages.

Hi all,

I’ve got this working now, with kernel 2.6.37.1-1.2-desktop

Here’s my short manual:

This is on a fresh installation of openSUSE 11.4 - LIRC has been installed!

DO NOT UNINSTALL THE OLD LIRC - we will use some of its scripts and config files later on! If you don’t have lirc installed, open a shell and type

sudo zypper in lirc lirc-remotes

1. Install new LIRC

1.1. Install additionally required packets.
In a shell type:

sudo zypper in gcc make

Note: This may or may not be neccessary, depending on your system

1.2. Download new LIRC
Download lirc-0.9.0-pre1 from Index of /software/snapshots

1.3. Extract and configure LIRC
Assuming you downloaded the file to /home/YOURUSERNAME/Downloads (the Firefox default), in a shell type:

cd ~/Downloads
bunzip2 lirc-0.9.0-pre1.tar.bz2
tar -xf lirc-0.9.0-pre1.tar
cd lirc-0.9.0-pre1
./configure --with-driver=userspace

This should run without errors and result in the lines

Your hardware does not require a special LIRC module.

Now enter 'make' and 'make install' to compile and install the package

1.4. Compile LIRC
In a shell, go to the directory where you extracted LIRC and type:

make

This might give a few warnings but should not give any errors. The last five lines should be similar to:

make[3]: Leaving directory '/home/YOURUSERNAME/Downloads/lirc-0.9.0-pre1/doc'
make[2]: Leaving directory '/home/YOURUSERNAME/Downloads/lirc-0.9.0-pre1/doc'
make[2]: Entering directory '/home/YOURUSERNAME/Downloads/lirc-0.9.0-pre1'
make[2]: Leaving directory '/home/YOURUSERNAME/Downloads/lirc-0.9.0-pre1'
make[1]: Leaving directory '/home/YOURUSERNAME/Downloads/lirc-0.9.0-pre1'

1.5. Install new LIRC
In a shell, still in the directory you extracted LIRC, type:

sudo make install

You might see some messages like “nothing to do for install-data-am” . this is OK!

You should now have an executable in ‘/usr/local/sbin’ called ‘lirc’. To check, type:

ll /usr/local/sbin/lir*

1.6. Set-up LIRC for futher usage
In a shell, still in the directory you extracted LIRC, type:
(You might want to backup your custom lircd.conf file from /etc/lirc/lircd.conf before doing this!)

sudo cp remotes/devinput/lircd.conf.devinput /etc/lirc/lircd.conf

1.7. Test installation
1.7.1. Start LIRC
In a shell, type:
(Note: YOURREMOTENAME is the name of your remote controller, i.e. iMON)

lsusb | grep -i YOURREMOTENAME

and note the ID (i.e. 15c2:ffdc). If you don’t know your remote controller name, try ‘lsusb’ and scroll through the output and try to find your remote controller.
Now, from a shell, start LIRC by typing:

/usr/local/sbin/lircd --nodaemon --output=/var/run/lirc/lircd --driver=devinput --device=/dev/input/by-id/usb-**15c2_ffdc**-event-if00

See how the device parameter holds the values from the ID above. So the ‘–device’ parameter will be a bit different for you depending on your remote.
The output from this command should be:

lircd: lircd(devinput) ready, using /var/run/lirc/lircd

Press CTRL+C to quit LIRC AFTER you have checked the installation with irw (see 1.7.2)

1.7.2. Check remote CODEs showing up
Now, open a new shell and type:

sudo irw

… and press some buttons on your remote. This should result in the remote CODEs showing up (including their “translations”)
Don’t forget to quit LIRC and irw with CTRL+C

1.8. Troubleshooting
If this does not work, it could be, that your ‘–device’ parameter is wrong (in my case, for example, I had two iMON devices, though I don’t really know, where the second one comes from and it doesn’t pick up any IR Codes). Try unplugging and re-plugging your IR-receiver and type ‘dmesg’ in a shell - you will see in the last lines the pci adress of your IR-receiver (i.e. pci0000:00/0000:00:12.1 …)
This means, quit LIRC (by pressing CTRL+C) and then try

/usr/local/sbin/lircd --nodaemon --output=/var/run/lirc/lircd --driver=devinput --device=/dev/input/by-path/pci-**0000\:00\:12.1**-usb-0\:1\:1.0-event

Again, the path will most likely be a bit different for you - just make sure that you use the closest match and the ‘event’ at the end.
Go to step 1.7.2. and try again.

2. Configure LIRC and scripts to start correct
2.1. Configure /etc/sysconfig/lirc
Press ALT+F2 and type ‘kdesu doplhin’ and navigate to ‘/etc/sysconfig’ and edit the file ‘lirc’ to hold the following values (of course, substitute the values for LIRCD_DEVICE with your own path!) :

LIRCD_DRIVER="devinput"
LIRCD_DEVICE="/dev/input/by-id/usb-15c2_ffdc-event-if00"
# OR - if you use the device 'by-path':
LIRCD_DEVICE="/dev/input/by-path/pci-0000:00:12.1-usb-0:1:1.0-event

NOTE: Use only one LIRCD_DEVICE entry!
NOTE2: If you use the input ‘by-path’ there is no need to escape the colons with a backslash (i.e. do not type ‘pci-0000:00’ but ‘pci-0000:00’). This was different in step 1.8

2.2. Configure /etc/init.d/lirc
Press ALT+F2 and type ‘kdesu doplhin’ and navigate to ‘/etc/init.d’ and edit the file ‘lirc’ to hold the following values:

lircd_BIN=/usr/local/sbin/lircd

2.3. Make LIRC start on boot
Press ALT+F2 and type ‘yast’ and go to ‘System->Runlevel’
Switch to Expert Mode, find ‘lirc’ and select the checkboxes ‘2’, ‘3’ and ‘5’. Press OK, reboot and

HAVE A LOT OF FUN

I forgot one more thing: If you want to use kremotecontrol, you have to copy /usr/local/sbin/lircd to /usr/sbin/lircd (replacing the “old” lircd file there). Backup the original file before doing so!

Edit: This doesn’t work reliably for me. So far, I have not found a solution to use kremotecontrol. I’ll keep you updated.

Hello everyone, perhaps I can shed some light here.

Your remotes have some basic functionality because there are rudimentary drivers for your remote built into the kernel. I would assume things like power, mouse, arrows, numbers, letters and volume function. My remote has had some functionality like this for a bit now too. This is great in that it would be nice to not have to set up LIRC to get a remote functioning, but at the moment there is no way (AFAIK) to configure these drivers in ways that you can with LIRC. Basically with these drivers, the remotes are functioning like another keyboard and if you want to change the behavior of the keys, you have to use xmodmap. While this may suffice if you have no real keyboard attached to the computer, if you do have a keyboard, then xmodmap also affects the keyboard. Therefore, if you have an “A” key on your remote and you map it to some other key, so to will your keyboard be changed while xmodmap is in effect. Furthermore, you have to run xmodmap for each application you want the remote to function with, which IMO is unacceptable.

Now the problem some are having using LIRC in 11.4 is that the lirc-kmp-desktop (et al.) packages are (as yet) unavailable. I don’t know if this is by accident or design, but I don’t see any bugs or openfate entries about this currently; I imagine a bug could be raised to investigate. These packages provide kernel modules that are needed for some devices that can be configured with LIRC. If you look at the list of supported devices at lirc.org, you can see the kernel modules and lircd drivers required by each supported remote. The lirc_dev module is required for all remotes that need a kernel module, usually in addition to a more specific module for that remote. This is what you pu in the “LIRC_MODULE” entry of /etc/sysconfig/lirc. The “lircd driver” entry in this table is what goes in “LIRCD_DRIVER”. If the driver is “default”, then that entry can be left blank. The “LIRCD_DEVICE” entry can contain the path to the device to read from, which is only necessary for some configurations. The other sysconfig entries I have been able to leave as is.

The good news is that many of the remotes listed in this table require no kernel modules, and thus these remotes can be configured in LIRC without the lirc-kmp-* packages. Also good news is that some of the LIRC kernel modules are stable enough to be in the “staging” area of the kernel: you can see a list of them in the directory “/lib/modules/[kernel version]/kernel/drivers/staging/lirc”. The lirc_dev module is also included in the kernel.

wdirksen: The bad news here is that the lirc_mceusb module is not in staging, so you would need the lirc-kmp-foo package to configure your remote in LIRC. Alternatively, you can try to build LIRC from source with the kernel module you need. This is fraught with potential problems though: the instructions at lirc.org list many possible complications. At the very least you will need to install gcc and the kernel sources, and probably make, autoconf and automake, and possibly some other build dependencies.

tartalo: Let us know what kind of remote you are trying to set up and perhaps we can help.

ripper17: While your efforts at compiling and installing lirc-0.9.0-pre1 are heroic, I believe they are unnecessary. The lircd driver you are using (devinput) does not require any kernel modules and is built into the stock 11.4 LIRC. You should be able to configure your remote with the lirc-0.8.7 included in 11.4 by completing only steps 1.6 and 2.1 of your instructions. Then you can do “rclirc start” as root, and test your setup with irw as you were before. Furthermore, kremotecontrol should work with this setup.

Hi Poorboy and Martin,
I appreciate the work and advice from both of you. But no luck yet. Since the lirc-kmp-foo module doesn’t come with Suse and I’m not sure how Foobar or WinLirc relates to all of this, I tried to do it Martin’s way and have got somewhat further in this than before. I compiled with the -mceusb option enabled instead of -userspace because it requires it. Also I apparently need the default driver and not devinput. Everything seems to compile fine. Because I previously have prepared the kernel to compile Nvidia drivers, I’m assuming that kernel headers etc are good. I tried it with different options in /etc/sysconfig/lirc.

LIRCD_DEVICE="/dev/lirc0"
LIRCD_DEVICE="/dev/input/by-path/pci-0000:00:04.0-usb-0:1:1.0-event"

But still no luck. Both options give the same info in dmesg:

4.966274] input: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:04.0/usb4/4-1/4-1:1.0/rc/rc1/input7
4.966322] rc1: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:04.0/usb4/4-1/4-1:1.0/rc/rc1
4.966353] mceusb 4-1:1.0: Registered Philips eHome Infrared Transceiver on usb4:2
4.966374] usbcore: registered new interface driver mceusb
5.009989] lirc_mceusb: disagrees about version of symbol lirc_dev_fop_poll
5.009994] lirc_mceusb: Unknown symbol lirc_dev_fop_poll (err -22)
5.010225] lirc_mceusb: disagrees about version of symbol lirc_dev_fop_open
5.010228] lirc_mceusb: Unknown symbol lirc_dev_fop_open (err -22)
5.010307] lirc_mceusb: disagrees about version of symbol lirc_get_pdata
5.010309] lirc_mceusb: Unknown symbol lirc_get_pdata (err -22)
5.010399] lirc_mceusb: disagrees about version of symbol lirc_dev_fop_close
5.010401] lirc_mceusb: Unknown symbol lirc_dev_fop_close (err -22)
5.010588] lirc_mceusb: disagrees about version of symbol lirc_dev_fop_read
5.010590] lirc_mceusb: Unknown symbol lirc_dev_fop_read (err -22)
5.010720] lirc_mceusb: disagrees about version of symbol lirc_register_driver
5.010722] lirc_mceusb: Unknown symbol lirc_register_driver (err -22)
5.011092] lirc_mceusb: disagrees about version of symbol lirc_dev_fop_ioctl
5.011094] lirc_mceusb: Unknown symbol lirc_dev_fop_ioctl (err -22)

So the lirc_mceusb module seems to attempt to load but fails. Any ideas?

Poorboywilliy: If you don’t see an easy fix above. Could you expound a little more on the lirc_kmp_foo option.

Thanks.
Wessel

I have lirc working with my mceusb remote. You do not have to install anything, you simply need to configure it. You don’t have to add anything, you don’t need lirc-kmp

The module is simply mceusb not lirc_mceusb.

You need to put a working lircrc in /etc/lirc

Then in /etc/sysconfig/lirc

edit the lines so they look like

LIRCD_DEVICE="/dev/lirc0"

LIRC_MODULE=“mceusb”

Then modprobe mceusb

/etc/init.d/lirc restart

No problem.

I compiled with the -mceusb option enabled instead of -userspace because it requires it. Also I apparently need the default driver and not devinput. Everything seems to compile fine. Because I previously have prepared the kernel to compile Nvidia drivers, I’m assuming that kernel headers etc are good.

Correct–the lircd driver is “default” and you need the “lirc_dev” and “lirc_mceusb” kernel modules, so it sounds like you’ve got the correct options here. Good sign that it compiles at least.

I tried it with different options in /etc/sysconfig/lirc.

LIRCD_DEVICE=“/dev/lirc0”
LIRCD_DEVICE=“/dev/input/by-path/pci-0000:00:04.0-usb-0:1:1.0-event”

Did you try to leave LIRCD_DEVICE blank? I would try it blank first, I think that might work. At any rate, the kernel module is loaded before lircd is run in the /etc/init.d/lirc script, so the kernel module failing to load below is definitely the bigger problem right now.

But still no luck. Both options give the same info in dmesg:

4.966274] input: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:04.0/usb4/4-1/4-1:1.0/rc/rc1/input7
4.966322] rc1: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:04.0/usb4/4-1/4-1:1.0/rc/rc1
4.966353] mceusb 4-1:1.0: Registered Philips eHome Infrared Transceiver on usb4:2
4.966374] usbcore: registered new interface driver mceusb
5.009989] lirc_mceusb: disagrees about version of symbol lirc_dev_fop_poll
5.009994] lirc_mceusb: Unknown symbol lirc_dev_fop_poll (err -22)
5.010225] lirc_mceusb: disagrees about version of symbol lirc_dev_fop_open


So the lirc_mceusb module seems to attempt to load but fails. Any ideas?

Yes, it looks like the lirc_mceusb is having trouble finding functions in the lirc_dev module. Why this is I’m not sure…do you have more than one kernel installed? Are you trying to compile lirc-0.9.0-pre1? If so, I would try lirc-0.8.7 instead and see if that helps.

Poorboywilliy: If you don’t see an easy fix above. Could you expound a little more on the lirc_kmp_foo option.

Thanks.
Wessel

Apoligies, by lirc-kmp-foo I was talking about the kernel module packages called “lirc-kmp-default” or “lirc-kmp-desktop” where the last word matches which OpenSUSE kernel you have installed. “foo” is commonly used like a wildcard in certain circles. At any rate, these packages include the lirc kernel modules (like lirc_mceusb) compiled for each particular kernel. These packages are not found in 11.4, which is basically the root problem you are running in to.

Sorry, I’m not really well versed in compiling/debugging kernel modules so not sure how much I can help here if your problem is with the kernel module.

Thanks for the input Bruce, I made the adjustments to /etc/sysconfig/lirc as you indicate, also did a “modprobe mceusb”, yet it doesn’t work for me as it did in earlier SUSE versions.

Just for clarification, I assume you mean a lircd.conf file in /etc/lirc? If so, I have a functional lircd.conf file in /etc/lirc. The lircrc file is usually in /home/username/.username

Dmesg looks the same except without the . . .
lirc_mceusb: disagrees about version of symbol errors

I’m still only getting the basic kernel commands which are not enough. Bummer.>:(

I’ve slowly been coming to find that the lirc kernel modules are being merged into the kernel sources. Frustratingly, this is not documented in any easy to find source. I even read the weekly kernel logs linked on opensuse news, and don’t recall seeing anything about this. Between browsing kernel source, lirc source, lirc mailing lists, google, opensuse bugs I’ve pieced together some basic info but haven’t found the simple conclusion that the string needed for LIRC_MODULE is now just “mceusb”. Thanks for the input.

Whoa, jumped the gun on that last reply. Bruce your input was good!

I’m using another 11.4 machine and I did what you said. Afterwards I did a irw and it does work there now. So LIRC is up and going! Only MythTV doesn’t act correctly yet but I think that I will have to adjust things differently in MythTV.

Thanks everyone.

If you are still getting messages about “lirc_mceusb” then that means the kernel module you compiled is still loading. You should uninstall this (I think “make uninstall” in the directory where you compiled lirc should do the trick) and make sure that LIRC_MODULE=“mceusb” in /etc/sysconfig/lirc

The ~/.lircrc file is what you will need to set up to get the controls right in mythtv. Once you have lirc and the remote set up with the key codes and such in /etc/lirc/lircd.conf, then you control all the applications with ~/.lircrc. There’s ample documentation around about the format of this file and how to set it up for MythTV, but let us know if you need help with it.

wdirksen

The problem with mythtv is your remote is trying to act like a keyboard, and that confuses mythtv.

My remedy was.

To create a text file called 10-quirks.conf and placed it it in /etc/X11/xorg.conf.d

In it the it should be

Section “InputClass”
Identifier “Ignore IR remote as keyboard”
MatchProduct “Media Center Ed. eHome Infrared Remote Transceiver”
Option “Ignore” “on”
EndSection

Or you can download mine here

http://itsyourpc.org/bruce/files/10-quirks.conf

Just put that file in /etc/X11/xorg.conf.d

Reboot and your remote should work perfectly in mythtv.

OK, last request I hope.

The settings MythTV had changed somewhat and is now fixed. It works too good now. Every key command is issued twice. See below:

mythtv@woonkamer:~> irw
000000037ff07bdd 00 OK mceusb
000000037ff07bdd 01 OK mceusb
000000037ff07bde 00 Right mceusb
000000037ff07bde 01 Right mceusb
000000037ff07be0 00 Down mceusb
000000037ff07be0 01 Down mceusb
000000037ff07bdf 00 Left mceusb
000000037ff07bdf 01 Left mceusb

Any ideas why LIRC is now twice as ambitious?

See my post above.

Hi all, it’s me again.

So far LIRC is working as per Bruce’s instructions on “stock” 0.8.7 LIRC. Problem is there are double command signals only for the few commands that also work directly out of the kernel. So arrows, volume, enter give double key commands, the other buttons do not and work as intended.

Bruce: Your 10-quirks.conf seems to just kill LIRC altogether such that only the basic “kernel” arrow, volume, enter commands function. The specific wording for the MCE IR hardware is slightly different and tried to exacly match that of mine but still no help.

So hopefully my final question would be: Is there a way to turn off the very basic kernel IR functionality and only let the true LIRC IR functionality run?