[mythtv-users] Calling all lirc gurus

[Doug Scoular (dscoular)]

Hi All,

On 23/12/18, 9:41 pm, Alec quoth thusly:
> lirc.org is fine. However, have you found 
> /usr/share/doc/lirc/README.Debian, the official migration docs?

	Actually, I think I consulted both lirc.org and the 
	README.Debian (the .gz version):

		http://www.lirc.org/html/configuration-guide.html 

	I initially used the advice in the README to run the 
	/usr/share/lirc/lirc-old2new script but I vaguely recall it
	needed care and feeding so I went the more manual
	route when it failed to parse something.

On 23/12/18, 9:41 pm, Alec quoth thusly:
> If you used to use the default driver i. e. if you had a working 
> lircd.conf file it might make sense to use the default driver instead. 
> This way you should completely bypass the kernel decoding and could only 
> blame lirc. 

	Thanks for confirming that the "default" lirc driver should
	bypass the kernel decoding. I think that is what I want.
	However, when I do this by changing the lirc_options.conf
	file and reboot:

/etc/lirc/lirc_options.conf:
[lircd]
nodaemon        = False
#driver          = devinput
driver          = default # Changed from devinput to default.
device          = auto

	I still receive X events for certain keys including the volume 
	keys but the repeat loop, perhaps, has gone. I then decided 
	to disable and stop lirc-uinput and lircmd, then reboot:

# systemctl stop lircmd
# systemctl disable lircmd
Synchronizing state of lircmd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable lircmd
insserv: warning: current start runlevel(s) (empty) of script `lircmd' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `lircmd' overrides LSB defaults (0 1 6).
# systemctl disable lircd-uinput
Removed /etc/systemd/system/multi-user.target.wants/lircd-uinput.service.
# systemctl stop lircd-uinput

	After the reboot I still see x events, the volume keys
	the up, down, left, right, play, pause, etc. 
	Many keys are unmapped e.g. here's me hitting volume up:

KeymapNotify event, serial 37, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

	The mceusb driver is being loaded and lirc, rc-5 and rc-6 
	are enabled:

$ ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event6) with:
        Name: Media Center Ed. eHome Infrared Remote Transceiver (0471:060c)
        Driver: mceusb, table: rc-rc6-mce
        lirc device: /dev/lirc0
        Supported protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
        Enabled protocols: lirc rc-5 rc-6
        bus: 3, vendor/product: 0471:060c, version: 0x0101
        Repeat delay = 500 ms, repeat period = 125 ms

	For some reason xinput is still seeing the infrared device:

$ xinput
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Logitech K400                             id=10   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Power Button                              id=7    [slave  keyboard (3)]
    ↳ C-Media Electronics Inc.       USB PnP Sound Device       id=8    [slave  keyboard (3)]
    ↳ Media Center Ed. eHome Infrared Remote Transceiver (0471:060c)    id=9    [slave  keyboard (3)]
    ↳ Logitech K400                             id=11   [slave  keyboard (3)]

	The remote's power key no longer sends the system to sleep. However, 
	this may or may not be due to me remapping KEY_SLEEP with ir-keytables 
	but I don't understand what ir-keytables role is under the "default" driver
	or if that is the right thing to use.

	Since I can't see irw events I'm not sure what mappings are being used but
	ir-keytables seems to show the new mapping is present:

Before remapping:
# ir-keytable -r|grep KEY_SLEEP
scancode 0x1d1c = KEY_SLEEP (0x8e)
scancode 0x800f040c = KEY_SLEEP (0x8e)

After remapping:
# ir-keytable -r|grep KEY_SLEEP
Enabled protocols: lirc rc-5 rc-6 
# ir-keytable -r|grep KEY_TV
Enabled protocols: lirc rc-5 rc-6
scancode 0x001f = KEY_TV (0x179)
scancode 0x0026 = KEY_TV (0x179)
scancode 0x1d1c = KEY_TV (0x179)
scancode 0x1e1c = KEY_TV (0x179)
scancode 0x800f040c = KEY_TV (0x179)
scancode 0x800f0446 = KEY_TV (0x179)

	So, now I need help in understanding why irw isn't working,
	why my old key map isn't working for the majority of remote
	buttons and why X is seeing some remote button events?

	I've discovered I need to shutdown the lircd and lircd.socket services
	to get mode2 to work. However, irw just sits there without echoing
	any remote button presses whether I kill processes associated with
	/dev/lirc0 (like mythfrontend.real etc) or have lircd and lircd.socket
	running or not.

	I can run irrecord to create a mapping file.

	Again, what is ir-keytables role in all this? When everything
	was working under 16.04 I used the following in rc.local to map keys:

ir-keytable -s $MYRC -p rc-6 -p rc-5 -p lirc -w /mnt/store1/lirc/dugs-hacked-hauppauge -v >> /tmp/rc.local

	I'm not sure whether this is devinput related and therefore, now, the
	wrong thing to be doing when the "default" driver is in play?

	Still confused but at least problem 1) looping, appears to be resolved.

On 23/12/18, 9:41 pm, Stephen quoth thusly:
> I would recommend that you run my script that fixes all the 18.04 lirc 
> problems I know about, including getting the Python config programs to 
> work: 
> http://www.jsw.gen.nz/mythtv/lirc-ubuntu-18.04-install.sh

	I should probably have looked at this first, I will look at it
	next but I really wanted to understand the new manual
	configuration of lirc rather than rely on a script.

	Merry Christmas and I'll report back on how I get on
	with Stephen's recommendation of using the script.

	Any more clues and hints much appreciated!

Cheers,

Doug Scoular

-- 
“The big print giveth and the small print taketh away.”