[mythtv-users] Help - Lirc broken after upgrade to 0.9.0

Douglas Clowes dclowes1 at optusnet.com.au
Mon Aug 8 23:02:32 UTC 2011


On 2011-07-24 02:02, Duncan Brown wrote:
> On 23/07/2011 15:07, Eric Sharkey wrote:
>> I don't use emerge or Gentoo, so I can't speak to that. The driver
>> that an mceusb receiver needs to use is called "default". You should
>> be able to run: lircd --driver=list to get a list of supported drivers
>> for your compiled lircd. You won't see mceusb there, but you must see
>> "default" if you want this to work. That's the driver you need to use.
>> If you don't see that, you'll need to recompile with appropriate
>> options to get that driver enabled. Eric
>> ______________________________________________
> Are you sure about that?
>
> Not sure if its just because I'm using the media_build drivers, but I
> have to use devinput for my mceusb receiver
>
> In fact if I start lirc with default set, it wont start and suggests I
> should be using devinput..
>
> Dunc
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://www.mythtv.org/mailman/listinfo/mythtv-users
So I am currently working through this same sort of issue. I know what 
to do, but the hot-to-do-it will be distribution dependent.

Yes, lirc seems to have been going the way of devinput, which is nice, 
but it, as the name suggests, *input* orientated. It seems that devinput 
does not support sending, hence the message that it does not support 
sending.

So there appear to be two choices. Forget the in-kernel decode and key 
mapping and set up the good old bidirectional lircd like before or run 
up a reverse channel lircd to complement the devinput one. I have chosen 
to follow the latter path.

My standard lircd has the devinput device and connects to the standard 
/var/run/lirc/lircd and, by setting keymaps and protocols with 
ir-keytable I can decode and respond to my old remote and the one that 
came with my mceusb device. There is a bit of mucking about to find the 
correct dynamic rc# and /dev/input/event# because I have three 
receivers, but basically:

# lircd --driver=devinput --device=/dev/input/event12 
--pid=/var/run/lirc/lircd_recv.pid
# ir-keytable -s rc2 -c -w /etc/rc_keymaps/rc6_mce -w 
/etc/rc_keymaps/leadtek_y04g0051 -p LIRC

The keytables set their protocols (or you could add -p RC-6 -p NEC) and 
allows decoding of the key presses and output on /var/run/lirc/lircd for 
mythtv etc. The magic "-p LIRC" adds a bi-directional lirc bridge and 
creates the /dev/lirc0 which is needed for the next step.

I also start (manually at the moment) a second lircd instance:

# lircd --output=/var/run/lirc/lircd_send --pid=/var/run/lirc/lircd_send.pid

This connects /dev/lirc0 and /var/run/lirc/lircd_send with a 
bi-directional connection. It uses a separate pid file. By using ir_send 
with the appropriate device and remote definition, I can also control my 
external tuner.

lircd.conf:
include "/etc/lirc/lircd.conf.devinput"
include "/etc/lirc/Digital_Cable_STB"

channel_change.sh
#!/bin/sh
   REMOTE_NAME=Foxtel_Digital_Cable_STB
   DEVICE_NAME=--device=/var/run/lirc/lircd_send
   logger -t "$REMOTE_NAME" "func: $0"
   logger -t "$REMOTE_NAME" "args: $*"
   irsend $DEVICE_NAME SET_TRANSMITTERS 1
   sleep 0.5
   irsend $DEVICE_NAME SEND_ONCE $REMOTE_NAME FOXTEL
   sleep 0.5
   for digit in $(echo $1 | sed -e 's/./& /g'); do
     logger -t "$REMOTE_NAME" "send: $digit"
     irsend $DEVICE_NAME SEND_ONCE $REMOTE_NAME $digit
     # note, you may have to tweak the interdigit delay up a bit, 
depending on your STB model
     sleep 0.4
   done
   logger -t "$REMOTE_NAME" "send: SELECT"
   irsend $DEVICE_NAME SEND_ONCE $REMOTE_NAME SELECT
   exit 0

The logger stuff is for debug and it may come out.

YMMV,

Douglas



More information about the mythtv-users mailing list