Hi all, I've been waiting a while for this upgrade because I anticipated trouble. Turns out I was correct. I've been running successfully with the lirc-0.8.7 lirc_mceusb on gentoo-sources-2.6.35 for a few months now on two amd64 machines, one also using blaster capability. I'm tackling the single purpose system first (mythfrontend).

My current suspiciions are:
- too many modules compiled with the kernel - not sure which (if any) are the bare-bones requirements for mceusb.
- I've seen mention of accessing the remote device at different input layers, maybe I've got something cross-configured in that regard?
- I've wrongly set my LIRC_DEVICE="none" in make.conf

vitals:

kernel config

Code:

linux # grep LIRC .config
CONFIG_LIRC=m
CONFIG_IR_LIRC_CODEC=m
linux # grep _IR_ .config
CONFIG_IR_NEC_DECODER=m
CONFIG_IR_RC5_DECODER=m
CONFIG_IR_RC6_DECODER=m
CONFIG_IR_JVC_DECODER=m
CONFIG_IR_SONY_DECODER=m
CONFIG_IR_RC5_SZ_DECODER=m
CONFIG_IR_LIRC_CODEC=m
# CONFIG_IR_ENE is not set
# CONFIG_IR_IMON is not set
CONFIG_IR_MCEUSB=m
# CONFIG_IR_NUVOTON is not set
# CONFIG_IR_STREAMZAP is not set
# CONFIG_IR_WINBOND_CIR is not set
CONFIG_VIDEO_IR_I2C=m

The lirc modules have been moving into the input system of the kernel. Where both exist, the lirc_* modules are deprecated in favor of using "devinput" and the in-kernel driver. In fact, the lirc developers plan on removing those lirc_* drivers on the next iteration. Incidentally, mceusb was one of the first drivers moved in-kernel.

It's time to migrate to from lirc_mceusb to devinput and the in-kernel driver.

Which is why my Mythbox is still sitting at lirc-0.8.7 and kernel 2.6.37. I just haven't had time to do the migration. I've found one guide on how to do it, so far. Plus I picked up at some point that the in-kernel drivers with 2.6.37 aren't so hot, and it's better to start this whole exercise with 2.6.38.

But more to the point, if you really want to be using the new kernel with lirc_mceusb. I suspect you need to look into the "input" or "hid" subsystem menus and find the right stuff to turn off. I'm not sure if it will even be called "lirc", but I believe it will have the familiar-looking device names._________________.sigs waste space and bandwidth

I keep wanting to make the jump to devinput myself, but it's just been a matter of time. The basement is finally drying out, though we really haven't started repairs yet or moving back in. (I live near Lake Champlain, and had water in my basement once before - when the lake was at it's previous record high level, in 1993.) Maybe I'll have time soon.

I have seen some sort of migration guide for moving to devinput. I don't remember where, but it was a fairly simple search._________________.sigs waste space and bandwidth

CONFIG_IRQ_WORK=y
CONFIG_IRQ_FORCED_THREADING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_IRDA is not set
CONFIG_LIRC=m
# CONFIG_IR_NEC_DECODER is not set
# CONFIG_IR_RC5_DECODER is not set
CONFIG_IR_RC6_DECODER=m
# CONFIG_IR_JVC_DECODER is not set
# CONFIG_IR_SONY_DECODER is not set
CONFIG_IR_RC5_SZ_DECODER=m
CONFIG_IR_LIRC_CODEC=m
CONFIG_IR_ENE=m
# CONFIG_IR_IMON is not set
CONFIG_IR_MCEUSB=m
# CONFIG_IR_ITE_CIR is not set
# CONFIG_IR_NUVOTON is not set
# CONFIG_IR_STREAMZAP is not set
# CONFIG_IR_WINBOND_CIR is not set

I've got some sort of /etc/lircd.conf that tells how to decode the raw IR stuff, emitting a "key name", and then I've got another configuration file under ~mythtv that maps those "key names" to some sort of action, usually a keypress.

It sounds to me as if the former is now handled in-kernel, and the latter should be usable as-is. That presumes of course that I just grabbed the stanzas for /etc/lircd.conf out of /usr/share/lirc-* and didn't encode/name my own keys. Does this square with your experiences?

You're giving me the courage to go devinput on my mythfrontend. I was stuck at 2.6.32 for the longest time because I couldn't get wake-on-USB to work on any later kernels. I finally solved that one, and have let myself get stuck at 2.6.37 because of the devinput thing._________________.sigs waste space and bandwidth

As I understand it, that should still work. I'll be honest in that I haven't tried it since I switched over. I keep meaning to try it again, but finding time, alone, where either of the frontends aren't in use is a challenge with kids. _________________What's the worst that can happen?

Hi Russell5,
Yes, I had exactly the same issue at one point. I resolved it by stopping any processes for lirc and then unmerging lirc. Then search for any *lirc* files and remove them. This includes /dev/lirc*

Then emerge lirc. version 0.9.0 should be ok.. no need to bother with the pre1.

Once you've started lirc, if you run "lircd -n -H help" (which is invalid), it should list all the drivers. Before I did the above, this command only listed "default" as the available driver even though they were compiled into the kernel._________________# touch cock
touch: cannot touch `cock': Permission denied

Hi Russell5,
Yes, I had exactly the same issue at one point. I resolved it by stopping any processes for lirc and then unmerging lirc. Then search for any *lirc* files and remove them. This includes /dev/lirc*

Then emerge lirc. version 0.9.0 should be ok.. no need to bother with the pre1.

Once you've started lirc, if you run "lircd -n -H help" (which is invalid), it should list all the drivers. Before I did the above, this command only listed "default" as the available driver even though they were compiled into the kernel.

Thanks. I did this and still the same. When i ran lircd -n -H help i got the devinput driver before and after. I did add CONFIG_LIRC_STAGING=y which i didnt have before.
Here is part of my dmesg | grep mceusb

Hmmm.. the good news is that the driver IS working from the kernel, what isn't working is that lirc is not using it. There will be something that is interfering with it. A few things to check:

1) stop lircd, delete the /dev/lirc* files then restart udev (this will restart X). Check that /dev/lirc0 has been created. Start lirc if it has. If /dev/lircd appears then lirc is starting correctly. test with irw. If it's still not working then I guarantee that "lircd -n -H help" won't list the available drivers as before.

2) enable the option in /etc/conf.d/lircd LIRCD_OPTS="-d /dev/lirc0"

3) if you're still not working trying adding logging to /etc/conf.d/lircd LIRCD_OPTS="-L /var/log/lircd.log -d /dev/lirc0"

4) Stop lircd and then start a lircd instance lircd -n -H mceusb -d /dev/lirc0. test with irw. If that works [it pains me to say it] turn it off then on again _________________# touch cock
touch: cannot touch `cock': Permission denied

heh.. the devinput drivers are in lirc but the mceusb drivers are only on the kernel now. I have no idea why the need to split the drivers up._________________# touch cock
touch: cannot touch `cock': Permission denied

I believe it's a support issue. If they kept the drivers in lirc and in the kernel the support load would double. Add to that the fact that at the driver level things have diverged and you get a real maintenance mess.

That said, I still haven't made the jump to devinput yet, and have pegged my MythBox to kernel-2.6.37 and lirc-0.8.7 until I do._________________.sigs waste space and bandwidth