James,
I have also had problems bridging from the in-kernel mceusb driver to userspace for using lircd to decode signals (I'm using a non-media center remote with a media center receiver for which there is yet no keymap, so I need to get lircd to decode it for the time being). It looks like you're about the same place as I am, with lircd not complaining, but not saying anything else either. Try pointing mode2 to your /dev/lirc0 and comparing the pulse/space output with your lircd.conf file to ensure that mceusb is sending something that looks like it should be decoded properly.
I haven't had time to get lircd under a debugger to take a look yet, but I will in the next couple of days and let you know if anything turns up.
Simon.


On 14 April 2011 10:14, James Sumners <james.sumners@gmail.com> wrote:
On 2011-04-11 14:40:32 -0400, Jarod Wilson
<jarod@wilsonet.com> said:
>> On 4/8/2011 09:48, Jarod Wilson wrote:
>>> # echo lirc> /sys/class/rc/rc0/protocols
> There's another problem I've encountered. A bug in v4l-utils'
> ir-keytable, which in recent releases, is auto-run on boot via
> udev, is screwing up the key mapping table. If you disable the
> rule in 70-ir-properties.rules (iirc), you should get better
> results...

Okay, here's what I have done. First, I blacklisted the following modules:

rc_rc6_mce
ir_sony_decoder
ir_jvc_decoder
ir_rc6_decoder
ir_rc5_decoder
ir_nec_decoder
lirc_mceusb

Then I commented out the following line in my
/etc/udev/rules.d/70-infrared.rules:

ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a
/etc/rc_maps.cfg -s $name"

After rebooting:

[root] ~/ # cat /sys/class/rc/rc0/protocols
[rc-5] [nec] [rc-6] [jvc] [sony] [lirc]

[root] ~/ # lsmod
Module Size Used by
lirc_dev 11671 1 ir_lirc_codec
ir_sony_decoder 2171 0
ir_jvc_decoder 2265 0
ir_rc6_decoder 2777 0
rc_rc6_mce 1396 0
ir_rc5_decoder 2265 0
ir_nec_decoder 2681 0
mceusb 12191 0
rc_core 15487 9
ir_lirc_codec,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,rc_rc6_mce,ir_rc5_decoder,ir_nec_decoder,mceusb
usbcore

139496 6 mceusb,xpad,ohci_hcd,ehci_hcd,usbhid
...

I don't know why all of these decoder modules have loaded. I have them
explicitly disabled.

Anyway, at this point I tried irw and received no output. Which lead me to:

[root] /etc/udev/rules.d/ # cat /var/run/lirc/lircd
cat: /var/run/lirc/lircd: No such device or address

So I did:

[root] ~/ # echo lirc > /sys/class/rc/rc0/protocols
[root] ~/ # cat /sys/class/rc/rc0/protocols
rc-5 nec rc-6 jvc sony [lirc]

Still no device at /var/run/lirc/lircd. Checking dmesg:

...
WARNING: You are using an experimental version of the media stack.
As the driver is backported to an older kernel, it doesn't offer
enough quality for its usage in production.
Use it with care.
Latest git patches (needed if you report a bug to linux-media@vger.kernel.org):
0b1b920610a4d41c584e97d38b5ce497c4a303d7 [media] drxd: use
mutex instead of semaphore
a8e8541bc7af59ec07e810bd29aa827878389d82 Remove the now
obsolete drx397xD
9b2dd144435e397b6ed2a75d522b49868aef98a5 [media] drxd:
CodingStyle cleanups
mceusb 3-2:1.0: mceusb_dev_probe called
mceusb 3-2:1.0: acceptable outbound endpoint found
mceusb 3-2:1.0: acceptable inbound endpoint found
IR NEC protocol handler initialized
IR RC5(x) protocol handler initialized
Registered IR keymap rc-rc6-mce
input: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008)
as /devices/pci0000:00/0000:00:13.1/usb3/3-2/3-2:1.0/rc/rc0/input7
rc0: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008) as
/devices/pci0000:00/0000:00:13.1/usb3/3-2/3-2:1.0/rc/rc0
mceusb 3-2:1.0: receive request called (size=0x20)
mceusb 3-2:1.0: receive request FAILED! (res=-22)
mceusb 3-2:1.0: receive request called (size=0x20)
mceusb 3-2:1.0: receive request FAILED! (res=-22)
mceusb 3-2:1.0: receive request called (size=0x2)
mceusb 3-2:1.0: receive request complete (res=0)
mceusb 3-2:1.0: receive request called (size=0x20)
mceusb 3-2:1.0: receive request complete (res=0)
mceusb 3-2:1.0: receive request called (size=0x2)
mceusb 3-2:1.0: receive request complete (res=0)
mceusb 3-2:1.0: receive request called (size=0x20)
mceusb 3-2:1.0: receive request FAILED! (res=-22)
mceusb 3-2:1.0: receive request called (size=0x2)
mceusb 3-2:1.0: receive request complete (res=0)
mceusb 3-2:1.0: receive request called (size=0x20)
mceusb 3-2:1.0: receive request FAILED! (res=-22)
mceusb 3-2:1.0: receive request called (size=0x2)
mceusb 3-2:1.0: receive request complete (res=0)
mceusb 3-2:1.0: receive request called (size=0x20)
mceusb 3-2:1.0: receive request FAILED! (res=-22)
mceusb 3-2:1.0: Registered Topseed Technology Corp. eHome Infrared
Transceiver on usb3:2
usbcore: registered new interface driver mceusb
mceusb 3-2:1.0: callback called (status=0 len=2)
mceusb 3-2:1.0: callback called (status=0 len=2)
mceusb 3-2:1.0: setup answer received 4 bytes
mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle
mceusb 3-2:1.0: callback called (status=0 len=2)
mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle
mceusb 3-2:1.0: callback called (status=0 len=2)
mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle
mceusb 3-2:1.0: processed IR data, calling ir_raw_event_handle
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
lirc_dev: IR Remote Control driver registered, major 61
lirc_dev: lirc_register_driver: sample_rate: 0
IR LIRC bridge handler initialized
...

Next, I did:

[root] ~/ # /etc/rc.d/lircd stop
:: Stopping LIRC Daemon
[DONE]
[root] ~/ # cat /dev/lirc0
���Z#0XX��%
��X�XX�X�X��X&&&X��<X�
X�XGX��X���X�X&X�X�X&X�X>XCX�!X�(#�#X^C

That's a single button press on my remote. I also verified that my lirc
config is setup to read from /dev/lirc0, and it is. So I started lircd
again and re-tried irw. I got the same results -- nothing.

~ James



------------------------------------------------------------------------------
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev