Hi,
I recently did a clean install of F20 on a new system, and now I'm trying to get a remote control working. The remote is a Harmony 670 emulating a Hauppage 350, talking to a Phillips (but Microsoft-branded) receiver. This remote works beautifully on my old F14 system (and has since 2007 going all the way back to Fedora Core 6) but I've been utterly unable to get it to work on F20. I've tried a combination of approaches outlined on a host of sites, including MythTV, LIRC, ArchLinux, and FedoraProject.
The mceusb kernel module loads just fine.
=== start relevant lsmod ir_lirc_codec 13021 0 lirc_dev 19504 1 ir_lirc_codec mceusb 28026 0 rc_core 27490 13 ir_sharp_decoder,lirc_dev,ir_lirc_codec,ir_rc5_decoder,ir_nec_decoder,ir_sony_decoder,mceusb,ir_mce_kbd_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_sanyo_decoder,rc_rc6_mce === end relevant lsmod
When I plug it in, I see this in dmesg:
=== start dmesg [1363994.259561] usb 3-7: USB disconnect, device number 9 [1364061.976061] usb 3-7: new full-speed USB device number 10 using xhci_hcd [1364062.141766] usb 3-7: New USB device found, idVendor=0471, idProduct=0815 [1364062.141768] usb 3-7: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [1364062.141769] usb 3-7: Product: eHome Infrared Transceiver [1364062.141770] usb 3-7: Manufacturer: Philips [1364062.141771] usb 3-7: SerialNumber: PH00QtmD [1364062.143239] Registered IR keymap rc-rc6-mce [1364062.143310] input: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.0/rc/rc0/input30 [1364062.143422] rc0: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815) as /devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.0/rc/rc0 [1364062.143568] input: MCE IR Keyboard/Mouse (mceusb) as /devices/virtual/input/input31 [1364062.143960] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 [1364062.276018] mceusb 3-7:1.0: Registered Philips eHome Infrared Transceiver with mce emulator interface version 1 [1364062.276021] mceusb 3-7:1.0: 2 tx ports (0x0 cabled) and 2 rx sensors (0x0 active) === end dmesg
I see these entries in /proc/bus/input/devices:
=== start 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:14.0-7 S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.0/rc/rc0/input34 U: Uniq= H: Handlers=kbd event5 B: PROP=0 B: EV=100013 B: KEY=fff 0 200108fc32e 237605100000000 0 700158000 419200004001 8e968000000000 10000000 B: MSC=10
I: Bus=0000 Vendor=0000 Product=0000 Version=0000 N: Name="MCE IR Keyboard/Mouse (mceusb)" P: Phys=/input0 S: Sysfs=/devices/virtual/input/input35 U: Uniq= H: Handlers=sysrq kbd mouse2 event16 B: PROP=0 B: EV=100017 B: KEY=30000 7 ff87207ac14057ff febeffdfffefffff fffffffffffffffe B: REL=3 B: MSC=10 === end devices
Running 'ir-keytable' gives me this:
=== start ir-keytable Found /sys/class/rc/rc0/ (/dev/input/event5) with: Driver mceusb, table rc-rc6-mce Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other Enabled protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other Name: Media Center Ed. eHome Infrared bus: 3, vendor/product: 0471:0815, version: 0x0000 Repeat delay = 500 ms, repeat period = 125 ms === end ir-keytable
Yet running 'ir-keytable -t' and hitting buttons on the remote gives me nothing. I see the light on the receiver light up, but nothing shows up.
When I unplug the IR receiver from the new computer and plug it back into the old one, and press some buttons, I see the old computer receive and process them just fine, so it's clearly not a remote/receiver/battery issue.
I've been messing around with this on and off for about 15 hours now with no success. I'd be happy to provide more info on what I've tried, but can anyone give me tips on what I might be overlooking and/or missing. I'm sure it's something stupid but I'm about to pull my hair out over this (and don't get me started about a host of other stuff in F20).
I'll be happy to let you know what other documentation I've read/approaches I've tried, but this email is long enough as-is.
Thanks, -jdm
On Mon, Dec 8, 2014 at 1:04 PM, Justin Moore justin.nonwork@gmail.com wrote:
=== start relevant lsmod ir_lirc_codec 13021 0 lirc_dev 19504 1 ir_lirc_codec mceusb 28026 0 rc_core 27490 13 ir_sharp_decoder,lirc_dev,ir_lirc_codec,ir_rc5_decoder,ir_nec_decoder,ir_sony_decoder,mceusb,ir_mce_kbd_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_sanyo_decoder,rc_rc6_mce === end relevant lsmod
Assuming you are trying to use LIRC to process the remote signals: what does "cat /sys/class/rc/rc0/protocols" show? If more than one item is enclosed in square brackets, then something other than LIRC is getting those signals. There is now an in-kernel IR driver, this started sometime around F18. In order to get my remote to work with my MythTV system, I have to execute
# echo lirc > /sys/class/rc/rc0/protocols
After that, the above "cat" command shows only lirc bracketed, and then LIRC works fine.
--Greg
On Mon, 8 Dec 2014 15:04:41 -0500 Justin Moore wrote:
but can anyone give me tips on what I might be overlooking and/or missing
Total speculation: Have you checked to see if some "helpful" new feature is grabbing control of the remote? (Though I'm not sure how to check for such a thing). Maybe look through release notes for something about wonderful new and improved remote support?
On 12/08/2014 12:15 PM, Greg Woods wrote:
In order to get my remote to work with my MythTV system, I have to execute
# echo lirc > /sys/class/rc/rc0/protocols
If you need to do that every time you boot, you can simplify things by putting that into /etc/rc.d/rc.local and making sure that rc-local.service is enabled. My understanding is that systemctl automatically enables it if the file exists, but it never hurts to make sure.
On Mon, Dec 8, 2014 at 1:25 PM, Joe Zeff joe@zeff.us wrote:
If you need to do that every time you boot, you can simplify things by putting that into /etc/rc.d/rc.local and making sure that rc-local.service is enabled. My understanding is that systemctl automatically enables it if the file exists, but it never hurts to make sure.
Good point, because it is likely that, if this is in fact the OP's issue, he will have to do it at every boot. I ended up adding an ExecStartPre line to the unit file for the service that is using LIRC to accomplish the same thing, since it was a locally-created unit file anyway.
--Greg
-
Greg Woods -
Joe Zeff -
Justin Moore -
Tom Horsley