[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