How to switch to second lirc device

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

How to switch to second lirc device

Anthony Desmarais
Hi I have a myth TV combined frontend/backend running Fedora 21 in my living room. This runs 24/7 and has a DVB-T2 card (TBS 6220) in it which has it's own ir receiver using the proprietry TBS drivers.

 Because of an upgrade to a new skylake mainboard I had to upgrade from my previously working Fedora 19 build to Fedora 21. Currently the IR receiver has a interesting quirk where it just stops working after about 3-4 days (or lirc stops I have not yet figured it out). Before I got the tuner working on this new configuration I was using my USB MCE remote receiver which worked 100% without any issues so I am now trying to go back to using the MCE receiver. Problem is that I cannot remove the DVB_T2 card because I need it as a tuner so I am trying to make lirc use my MCE receiver and ignore the DVB-T2 card's IR receiver.

Currently the kernel is detecting both receivers and they each have a entry in /dev:
# ls -l /dev/lir*
crw-rw---- 1 root lirc 244, 0 May  9 17:39 /dev/lirc0
crw-rw---- 1 root lirc 244, 1 May  9 17:39 /dev/lirc1
#

and ir-keytable shows them both present:
# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event8) with:
        Driver saa716x, table rc-tbs-nec
        Supported protocols: lirc rc-5 jvc sony nec mce-kbd rc-6
        Enabled protocols: lirc
        Name: saa716x IR (TurboSight TBS 6220)
        bus: 1, vendor/product: 6220:0002, version: 0x0001
        Repeat delay = 500 ms, repeat period = 125 ms
Found /sys/class/rc/rc1/ (/dev/input/event17) with:
        Driver mceusb, table rc-rc6-mce
        Supported protocols: lirc rc-5 jvc sony nec mce-kbd rc-6
        Enabled protocols: lirc
        Name: Media Center Ed. eHome Infrared
        bus: 3, vendor/product: 0471:0815, version: 0x0000
        Repeat delay = 500 ms, repeat period = 125 ms

And this is the contents of my lirc_options.conf file:

# cat /etc/lirc/lirc_options.conf
# These are the default options to lircd, if installed as
# /etc/lirc/lirc_options.conf. See the lircd(8) and lircmd(8)
# manpages for info on the different options.

[lircd]
nodaemon        = False
driver          = default
device          = /dev/lirc0
output          = /var/run/lirc/lircd
pidfile         = /var/run/lirc/lircd.pid
plugindir       = /usr/lib64/lirc/plugins
permission      = 666
allow-simulate  = No
repeat-max      = 600
effective-user  = lirc
#listen         = [address:]port
#connect        = host[:port]
#debug          = 6
#uinput         = ...
#release        = ...
#logfile        = ...

[lircmd]
uinput          = False
nodaemon        = False

[modprobe]
#modules        = [lircd_dev, lirc_sir...]



I though it would be as simple as changing the device to /dev/lirc1 but when I restart the lircd.service the remote will not work,  looking at the system log I see the following:

lircd-0.9.3a[1097]: Info: Initial device: /dev/lirc1
lircd-0.9.3a[1097]: Notice: 'lirc' written to protocols file /sys/class/rc/rc1/protocols
lircd-0.9.3a[1097]: Info: Initial device: /dev/lirc1
lircd-0.9.3a[1097]: Notice: 'lirc' written to protocols file /sys/class/rc/rc1/protocols
lircd-0.9.3a[1097]: Notice: Running as user lirc
lircd: lircd-0.9.3a[1097]: Notice: Running as user lirc
lircd: lircd-0.9.3a[1097]: Debug: Groups: [976]: 976 18 54 999
lircd-0.9.3a[1097]: Info: Using remote: mceusb.
lircd: lircd-0.9.3a[1097]: Info: Using remote: mceusb.
lircd-0.9.3a[1097]: Notice: lircd(default) ready, using /var/run/lirc/lircd
lircd-0.9.3a[1097]: Notice: accepted new client on /var/run/lirc/lircd
lircd-0.9.3a[1097]: Info: Cannot configure the rc device for /dev/lirc1
lircd: lircd-0.9.3a[1097]: Notice: lircd(default) ready, using /var/run/lirc/lircd
lircd: lircd-0.9.3a[1097]: Notice: accepted new client on /var/run/lirc/lircd
lircd: lircd-0.9.3a[1097]: Debug: No device found: /sys/class/rc/rc0/lirc1
lircd: lircd-0.9.3a[1097]: Debug: Cannot open protocol file: /sys/class/rc/rc1/protocols
lircd: lircd-0.9.3a[1097]: Info: Cannot configure the rc device for /dev/lirc1

It looks like for some reason lirc wants to use /sys/class/rc/rc0/lirc1 when in fact it should be using sys/class/rc1/lirc1

How do I go about changing to this??

Thanks

Anthony


------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
Reply | Threaded
Open this post in threaded view
|

Re: How to switch to second lirc device

Alec Leamas



On 09/05/16 20:20, Anthony Desmarais wrote:
Hi I have a myth TV combined frontend/backend running Fedora 21 in my living room. This runs 24/7 and has a DVB-T2 card (TBS 6220) in it which has it's own ir receiver using the proprietry TBS drivers.

 Because of an upgrade to a new skylake mainboard I had to upgrade from my previously working Fedora 19 build to Fedora 21. Currently the IR receiver has a interesting quirk where it just stops working after about 3-4 days (or lirc stops I have not yet figured it out). Before I got the tuner working on this new configuration I was using my USB MCE remote receiver which worked 100% without any issues so I am now trying to go back to using the MCE receiver. Problem is that I cannot remove the DVB_T2 card because I need it as a tuner so I am trying to make lirc use my MCE receiver and ignore the DVB-T2 card's IR receiver.

Currently the kernel is detecting both receivers and they each have a entry in /dev:
# ls -l /dev/lir*
crw-rw---- 1 root lirc 244, 0 May  9 17:39 /dev/lirc0
crw-rw---- 1 root lirc 244, 1 May  9 17:39 /dev/lirc1
#

The problem here is that e. g. lirc0 could be either the USB MCE receiver or the DVB card;  the kernel device allocation is essentially random. Furthermore, it might very well change after a reboot.

and ir-keytable shows them both present:

OK...

And this is the contents of my lirc_options.conf file:

device          = /dev/lirc0

Since the allocation is random this is problematic
hanging the device to /dev/lirc1 but when I restart the lircd.service the remote will not work,  looking at the system log I see the following:

lircd-0.9.3a[1097]: Info: Initial device: /dev/lirc1
lircd-0.9.3a[1097]: Notice: 'lirc' written to protocols file /sys/class/rc/rc1/protocols

This looks good: lircd initializes the device to use the correct protocol

lircd-0.9.3a[1097]: Info: Cannot configure the rc device for /dev/lirc1

I. e., lircd (now running as regular user) cannot write the protocol. This is not a problem, the protocol is already set by  lircd as can be seen using ir-keytable.

lircd: lircd-0.9.3a[1097]: Notice: lircd(default) ready, using /var/run/lirc/lircd
lircd: lircd-0.9.3a[1097]: Notice: accepted new client on /var/run/lirc/lircd
lircd: lircd-0.9.3a[1097]: Debug: No device found: /sys/class/rc/rc0/lirc1

Not  a problem. lircd just probes all devices it can find.
lircd: lircd-0.9.3a[1097]: Debug: Cannot open protocol file: /sys/class/rc/rc1/protocols
lircd: lircd-0.9.3a[1097]: Info: Cannot configure the rc device for /dev/lirc1

Again,  not a problem since the device is already configured.

It looks like for some reason lirc wants to use /sys/class/rc/rc0/lirc1 when in fact it should be using sys/class/rc1/lirc1


Long story short: No, it does not, at least not looking at this log.

How do I go about changing to this??

The problem is probably something else, but  right now I have no clue...


What is the lirc version?

Have you tried to debug this using  mode2?



Cheers!

--alec

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j