I installed lirc-0.9.4 from the gentoo tree and after the update, using lirc to control my CommandIR II device failed to work. Running irsend shows the error "irsend: hardware does not support sending". For now, I have reverted to lirc-0.9.0-r6. I looked at the ebuild and it would appear the new versions ebuild doesn't have an option to enable transmitter support. It also seems to build all device drivers as support for LIRC_DEVICES seems to have been removed. The lirc-0.9.0-r6 ebuild has a warning when building support for more than one device at a time that says "When selecting multiple devices for lirc to be supported, it can not be guaranteed that the drivers play nice together." Because of that, building all device drivers seems like a bad idea. If I recall right, I have encountered this as a problem before when trying to merge support for commandir and iguanaIR. I think only one of the devices worked when I did that.
(In reply to Justin from comment #0) > I installed lirc-0.9.4 from the gentoo tree and after the update, using lirc > to control my CommandIR II device failed to work. > Running irsend shows the error "irsend: hardware does not support sending". > For now, I have reverted to lirc-0.9.0-r6. It appears you have lirc misconfigured - that error usually means you don't have lirc set to use the right plugin. Can you double check your configuration in /etc/lirc ? Do you have multiple /dev/lirc* devices, and if so, are you specifying the correct one in your "irsend -d /dev/lircX" invocation? (The version upgrade may have changed the order of the devices or something similar.) CommandIR has some troubleshooting steps at http://commandir.com/content/view/41/62/index.html which may be helpful as well. I'm very curious to find out how you solved the problem, but I'm not sure how else to help (as I don't have comparable hardware and cannot reproduce the issue) - I'm sorry for the trouble. You can also contract upstream. > I looked at the ebuild and it would appear the new versions ebuild doesn't > have an option to enable transmitter support. The "transmitter" use flag used to enable lirc's "transmitter" configure option which simply build a driver for an ir-diode-based transmitter. lirc removed this driver. It's not for enable general transmitter support. > It also seems to build all device drivers as support for LIRC_DEVICES seems > to have been removed. > The lirc-0.9.0-r6 ebuild has a warning when building support for more than > one device at a time that says "When selecting multiple devices for lirc to > be supported, it can not be guaranteed that the drivers play nice together." > Because of that, building all device drivers seems like a bad idea. > If I recall right, I have encountered this as a problem before when trying > to merge support for commandir and iguanaIR. I think only one of the devices > worked when I did that. It should be okay to build all drivers - I believe the warning is just that if you use multiple drivers (at run time), you can get conflicts, so be careful.
> The "transmitter" use flag used to enable lirc's "transmitter" configure > option which simply build a driver for an ir-diode-based transmitter. lirc > removed this driver. It's not for enable general transmitter support. It appears you are correct, which means the transmitter flag probably should been part of LIRC_DEVICES in the old ebuilds but it doesn't matter now. > It should be okay to build all drivers I looked at the lirc.org documentation including the changelog. It appears in lirc 0.9.1 and higher, the drivers are loaded dynamically so building all drivers is fine. In lirc 0.9.0 and lower the drivers were all built-in so building all the drivers could cause conflicts. It appears to load the specific driver I needed, I had to add 'LIRCD_OPTS="-H commandir"' to /etc/conf.d/lircd It seems that the issues I listed in this bug are not actually problems and I should have looked into the issue more before filing this bug. Though I did find another problem with the 0.9.4 ebuild that does need to be fixed. The ebuild builds lirc with a device socket path of "/var/lib/run/lirc/lircd" while the openrc init script still uses a device socket path of "/var/run/lirc/lircd". This means the path irsend and other lirc programs use by default is not the one used by lircd when run via the openrc init script. At the moment I just created the symlink in /var/lib/run/lirc to the correct location and everything works just fine with lirc 0.9.4 like 0.9.0-r6 did.
(In reply to Justin from comment #2) > > The "transmitter" use flag used to enable lirc's "transmitter" configure > > option which simply build a driver for an ir-diode-based transmitter. lirc > > removed this driver. It's not for enable general transmitter support. > It appears you are correct, which means the transmitter flag probably should > been part of LIRC_DEVICES in the old ebuilds but it doesn't matter now. > > > > It should be okay to build all drivers > I looked at the lirc.org documentation including the changelog. > It appears in lirc 0.9.1 and higher, the drivers are loaded dynamically so > building all drivers is fine. > In lirc 0.9.0 and lower the drivers were all built-in so building all the > drivers could cause conflicts. > > It appears to load the specific driver I needed, I had to add > 'LIRCD_OPTS="-H commandir"' to /etc/conf.d/lircd > > It seems that the issues I listed in this bug are not actually problems and > I should have looked into the issue more before filing this bug. > Though I did find another problem with the 0.9.4 ebuild that does need to be > fixed. > The ebuild builds lirc with a device socket path of > "/var/lib/run/lirc/lircd" while the openrc init script still uses a device > socket path of "/var/run/lirc/lircd". > This means the path irsend and other lirc programs use by default is not the > one used by lircd when run via the openrc init script. > > At the moment I just created the symlink in /var/lib/run/lirc to the correct > location and everything works just fine with lirc 0.9.4 like 0.9.0-r6 did. That path issue ended up being really interesting. Let's handle it in a separate bug - bug 589246. I'm glad everything else has worked out!
