[mythtv-users] Help me find the magic combo (remote/lirc)

[Jarod Wilson]

On Dec 30, 2009, at 6:49 PM, Jan Johansson wrote:

>> I suppose a better response is 'why do you need to blacklist lirc_imon
>> to get lirc to work?
> 
> Because else it seem to load lirc_imon no matter what I put in lirc's
> hardware-conf, and that means lirc_mce does not bind with lirc.

Bull. You wind up with /dev/lirc0 for the imon, /dev/lirc1 for the mce.

>> I had one of the iMon devices but I've retired it since the VFD kept
>> freezing up on me.
> 
> Yeah, I have had my fair share of garbage/lockups with the screen, but
> it _mostly_ worked with mythbuntu.

I *might* finally have some idea what's going on there... The driver uses some atomic_set() calls that don't guarantee what I think the original author of that bit of code thought they'd guarantee -- setting a tx busy var in a way that another reader would always see the correct value. Needs to have an smp_rmb() call in there (read memory barrier) to prevent caching from hosing things up. I'm thinking perhaps the display was already being written to, and we tried sending more data before it was ready because we weren't properly seeing the tx busy value due to cache effects. This is fixed in my pure input layer imon driver being reviewed on the upstream linux-input mailing list right now, will need some testers though, since my own devices were unaffected by the garbage/lockup issue some have seen (I think it may be specific to the older 0xffdc devices, my LCD and VFD are both the newer gen stuff).

>> What does your /etc/lirc/hardware.conf look like?
> 
> 
> mythtv at MythBox:~$ cat /etc/lirc/hardware.conf
> # /etc/lirc/hardware.conf
> #
> #Chosen Remote Control
> REMOTE="Windows Media Center Transceivers/Remotes (all)"
> REMOTE_MODULES="lirc_dev lirc_mceusb"
> REMOTE_DRIVER=""
> REMOTE_DEVICE="/dev/lirc0"

Just change that to /dev/lirc1 and the mce transceiver will magically work.

-- 
Jarod Wilson
jarod at wilsonet.com