Ubuntu 19.10 and MCE Remote
#1
Starting from Ubuntu 18.04 MCE Remote doesn't work anymore in Kodi.
Only Enter, Up, Down, Left, Right work.
Already read all the guides and tried ir-keytable and lirc.
It seems that xorg is intercepting all mce remote keystrokes (all commands are recognized with irw and ir-keytable -t).
Kodi log doesn't show any onkey events.
I'm the only one to have this problem?
Thank you,
sdf
Reply
#2
What did you use before ?  ir-keytable or lirc ? My custom lirc remotes work fine in 18.04 with Kodi 18.4 and lirc 0.10.0-2.  I did have to point it to /dev/lirc1 rather than /dev/lirc.

From memory, that was the only change I had to make.
Learning Linux the hard way !!
Reply
#3
Before I didn't change nothing from default config, and remote worked out of the box, so don't know if it was using lirc or ir-keytable.
Also in Libreelec old and latest version remote works perfectly.
What I can't understand is that with ir-keytable -t I can see all the keypresses, but they aren't recognized by kodi (no onkey event).
So it seems to me that there's something that intercepts that keystrokes.
I'm not an expert, but seems that ir-keytable translates remote buttons into keyboard keypresses: the problem is that remote button "1" (that should be translated into key_1 or key_numeric_1 depending on config) is not recognized by kodi, but key 1 and numeric key 1 on keyboard are perfectly seen!
Anyway, thank you for your answer.
Bye,
sdf
Reply
#4
Found solution, but it took three days, because I'm no expert.
My system is Ubuntu 19.10.
Searching everywhere, I found that xorg intercepts all keyboard keystrokes (why?).
The problem is that mce remote is seen as a a keyboard, so also all his keystrokes are intercepted.
Don't know how, but all (real) keyboard keystrokes work, but not remote buttons.
Nobody has a wiki, a doc page that show how all this is managed by xorg/Ubuntu.
Anyway found that the solution was to exclude mce remote from devices recognized by xorg, and let the remote be managed by lirc.
So, at first, added my remote to the /usr/share/X11/xorg.conf.d/10-quirks.conf.
More precisely, as I found somewhere in a site, I added this to that file:
# Disable the MCE remote from acting like a keyboard.  (We use lirc instead.)
Section "InputClass"
    Identifier   "MCE USB Keyboard mimic blacklist"
    Driver       "mceusb"
    MatchProduct "Media Center Ed. eHome Infrared Remote Transceiver (1934:5168)"
    Option       "Ignore" "on"
EndSection
So, after a reboot, my mce remote was not seen by xorg.
Now I installed lirc.
Lirc package in Ubuntu 19.10 is defective.
When you first try to install, it terminates with an error because it doesn't find a file: /etc/lirc/lirc_options.conf.
So you have to copy (an empty text file is enough) a file with that name in that location, and install the package again.
After that, you have to edit lirc_options.conf and lircd.conf depending on your configuration.
I followed instructions on lirc site: http://www.lirc.org/html/configuration-guide.html.
Reboot, and after lircd is started, all is working now!
I don't know other distributions, but kodi and mce remote is a really common hardware-software config.
How is it possible that a normal user has to do all that?
There's a complete lack of information.
I couldn't find anywhere how keystrokes are managed in ubuntu (or xorg).
Bye,
sdf
Reply
#5
This didn't seem to work for me "out of the box" so far (I think). Test was to see that, at the desktop, my remote was doing things like line-up and down in response to the arrow up/down buttons on like a web page or edited document. Then I put this into 10-quirks.conf, reboot, and see if I still get it...and I do. I'm thinking I need to specify MatchProduct differently? When I do an lsusb command, my mceusb receiver comes in with:

Bus 003 Device 002: ID 0471:0815 Philips (or NXP) eHome Infrared Receiver

I'm not sure how much of the MatchProduct line makes a difference, but my tendency would be to say the line could look like:

    MatchProduct "Philips (or NXP) eHome Infrared Receiver (0471:0815)"

But I have no idea at this point whether that makes sense or if I should keep the match words to a minimum.... 

I'd assume the Identifier line is pretty much arbitrary, but if it has to somehow mach with something else...I'm not sure what that would be. 

For now, it doesn't cost much to try my alternate MatchPProduct line, but any feedback would be appreciated...

Tnx
b
Reply
#6
(2020-05-18, 22:07)bluesight Wrote:     MatchProduct "Philips (or NXP) eHome Infrared Receiver (0471:0815)"

I would say that that looks correct to me.  Try it, you can only end up in the same situation you are in now, or better if it works!
Learning Linux the hard way !!
Reply
#7
No joy...

In keeping with other InputClass entries, I used this format (MatchDriver rather than Driver...could be a problem I suppose) and also tried with leaving out the (0471:0815) detail:

Section "InputClass"
    Identifier   "MCE USB Keyboard mimic blacklist"
    MatchProduct "Philips (or NXP) eHome Infrared Receiver (0471:0815)"
    MatchDriver  "mceusb"
    Option       "Ignore" "on"
EndSection

Verified the drive name really is mceusb (Port 2: Dev 2):

m@m-G6:~$ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=mceusb, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 5: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
        |__ Port 5: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 2: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
        |__ Port 2: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M

and even verified with Xorg  pages that "on" is a valid boolean:

Boolean options may optionally have a value specified. When no value is specified, the option’s value is TRUE. The following boolean option values are recognised as TRUE:
1, on, true, yes

So, short of starting to pour through reams of logs, I'm stumped...maybe my test isn't valid...?

b
Reply
#8
No joy...

In keeping with other InputClass entries, I used this format (MatchDriver rather than Driver...could be a problem I suppose) and also tried with leaving out the (0471:0815) detail:

Section "InputClass"
    Identifier   "MCE USB Keyboard mimic blacklist"
    MatchProduct "Philips (or NXP) eHome Infrared Receiver (0471:0815)"
    MatchDriver  "mceusb"
    Option       "Ignore" "on"
EndSection

Verified the drive name really is mceusb (Port 2: Dev 2):

m@m-G6:~$ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
    |__ Port 2: Dev 2, If 0, Class=Vendor Specific Class, Driver=mceusb, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 5: Dev 3, If 0, Class=Video, Driver=uvcvideo, 480M
        |__ Port 5: Dev 3, If 1, Class=Video, Driver=uvcvideo, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 2: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
        |__ Port 2: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M

and even verified with Xorg  pages that "on" is a valid boolean:

Boolean options may optionally have a value specified. When no value is specified, the option’s value is TRUE. The following boolean option values are recognised as TRUE:
1, on, true, yes

So, short of starting to pour through reams of logs, I'm stumped...maybe my test isn't valid...?

b
Reply
#9
Someone can please remove the duplicate post. I can't edit/remove myself...

 I did fully stop my mce remote from affecting the xfce desktop by adding "blacklist mceusb" to the /etc/modprobe.d/blacklist.conf file. Hopefully that is a safe thing to do. But now it will be the question of whether lirc will be able to access the receiver when the driver isn't in the kernel. I'll probably wait a bit before making the (laborious) attempt to see if there is any feedback here on this approach...

b
Reply
#10
Pretty sure this won't work...my functioning 18.04 system with 0.9.0 Lirc still has the mceusb driver installed (as seen with lsusb -t). There is no driver on this (20.04) system per the lsusb -t line:

    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=, 12M

So, for now, I'm not going to proceed with current (10.x or higher) lirc

I'll continue to look for advice on blacklisting within X(org)....

b
Reply
#11
Odd.  After checking my logs I see that my receiver is exactly the same as yours @bluesight but I don't recall having to blacklist it anywhere.  Indeed, I can see it identified in my Xorg.0.log

xml:
22.591] (**) Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): always reports core events
[    22.591] (**) Option "Device" "/dev/input/event8"
[    22.591] (**) Option "_source" "server/udev"
[    22.593] (II) event8  - Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): is tagged by udev as: Keyboard Pointingstick
[    22.593] (II) event8  - Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): device is a pointer
[    22.593] (II) event8  - Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): device is a keyboard
[    22.593] (II) event8  - Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): device removed
[    22.594] (II) libinput: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): needs a virtual subdevice
[    22.594] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0/usb8/8-1/8-1.1/8-1.1:1.0/rc/rc0/input10/event8"
[    22.594] (II) XINPUT: Adding extended input device "Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)" (type: MOUSE, id 8)
[    22.594] (**) Option "AccelerationScheme" "none"
[    22.594] (**) Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): (accel) selected scheme none/0
[    22.594] (**) Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): (accel) acceleration factor: 2.000
[    22.594] (**) Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): (accel) acceleration threshold: 4
[    22.595] (II) event8  - Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): is tagged by udev as: Keyboard Pointingstick
[    22.596] (II) event8  - Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): device is a pointer
[    22.596] (II) event8  - Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): device is a keyboard
~~~~
22.712] (**) Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): Applying InputClass "libinput keyboard catchall"
[    22.712] (II) Using input driver 'libinput' for 'Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)'
[    22.712] (II) systemd-logind: returning pre-existing fd for /dev/input/event8 13:72
[    22.712] (**) Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): always reports core events
[    22.712] (**) Option "Device" "/dev/input/event8"
[    22.712] (**) Option "_source" "_driver/libinput"
[    22.712] (II) libinput: Media Center Ed. eHome Infrared Remote Transceiver (0471:0815): is a virtual subdevice
[    22.712] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:04.0/0000:02:00.0/usb8/8-1/8-1.1/8-1.1:1.0/rc/rc0/input10/event8"
[    22.712] (II) XINPUT: Adding extended input device "Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)" (type: KEYBOARD, id 16)
[    22.712] (**) Option "xkb_model" "pc105"
[    22.712] (**) Option "xkb_layout" "gb"

Are you sure you haven't got irxevent or irexec running as well, as either of those could be intercepting the remote presses and converting them to X events?
Learning Linux the hard way !!
Reply
#12
I'll try the regular lirc install (10.x?) and see if it gets anywhere. Otherwise, back again to 0.9.0...it's just time and effort....

b
Reply
#13
It appears that lirc 10 will not install in 20.04 (at least I can't do it). The  /etc/lirc/lirc_options.conf issue does not seem to be resolved with a re-install. And there is now a version that supposedly addresses the problem, lirc 0.10.1-6.1ubuntu1.1 , that I don't think is available for a simple install from a repository. I'm not at the point of doing a manual compile/install (though I wasted time trying). So...cut bait and retrograde to lirc 0.9.0 (hope that really still works). If someone has success with this corrected version of lirc and can find it or get it into a repository, please help me (us all)...

b
Reply
#14
(2020-05-19, 22:42)bluesight Wrote: I don't think is available for a simple install from a repository.

Do you mean this version (that I have installed on 20.04)?

xml:
apt-cache policy lirc
lirc:
  Installed: 0.10.1-6.1
  Candidate: 0.10.1-6.1
  Version table:
 *** 0.10.1-6.1 500
        500 http://gb.archive.ubuntu.com/ubuntu focal/universe amd64 Packages
        100 /var/lib/dpkg/status

That's in the universe repo as you can see.
Learning Linux the hard way !!
Reply
#15
Messed up links:
Statement of error:

https://bugs.launchpad.net/ubuntu/+sourc...ug/1874130

Corrected version:

https://launchpad.net/ubuntu/+source/lir...1ubuntu1.1

Not sure if 0.10.1.6.1 is the same...?? 

b
Reply

Logout Mark Read Team Forum Stats Members Help
Ubuntu 19.10 and MCE Remote0