search

clontarfx / kodi-rc6-mce-nolirc

Files required to use most RC6 MCE remotes with Kodi and Ubuntu 17, without LIRC
29 stars 6 forks source link

Confirmed working: MCE receiver/remote combo on Kodi 19.3. #5

Closed ErnstNeger closed 2 years ago

ErnstNeger commented 2 years ago

Hi,

used to work perfectly on a RaspberryPi 3 with an old Microsoft MCE remote (Model: 1039) and Media Center Edition eHome Infrared Remote Transceiver.

Now (Linux kodi 5.10.89-2-rpi-legacy-ARCH #1 SMP Mon Jan 3 13:08:24 UTC 2022 armv7l GNU/Linux) running kodi-rpi-19.3-3, the back button is not mapped correctly anymore.

Full name: "Media Center Ed. eHome Infrared Remote Transceiver (0471:0815)"

BR

Martii commented 2 years ago

Probably related to #3 . A lot there to read and check to see for sure but high probability.

ErnstNeger commented 2 years ago

@Martii, I did check #3 before, that wasn't the issue. Turns out a simple replug/reboot did the trick (in my case), don't know what went wrong initially. The discussed kernel bug in ir-keytable as well as the incorrect behaviour on booting seem to be solved, at least in my kernel (5.10.90-1-rpi-ARCH #1 SMP Wed Jan 5 14:52:56 UTC 2022 armv7l GNU/Linux).

Ref.: My (unneccessary) post on Kodi forums

My /etc/rc_keymaps/rc6_mce.toml for a Microsoft Model: 1039 (RC1534612/00) remote (46 buttons):

[[protocols]] name = "rc6_mce" protocol = "rc-6" variant = "rc-6-mce" [protocols.scancodes] 0x800f0400 = "KEY_NUMERIC_0" 0x800f0401 = "KEY_NUMERIC_1" 0x800f0402 = "KEY_NUMERIC_2" 0x800f0403 = "KEY_NUMERIC_3" 0x800f0404 = "KEY_NUMERIC_4" 0x800f0405 = "KEY_NUMERIC_5" 0x800f0406 = "KEY_NUMERIC_6" 0x800f0407 = "KEY_NUMERIC_7" 0x800f0408 = "KEY_NUMERIC_8" 0x800f0409 = "KEY_NUMERIC_9" 0x800f040a = "KEY_DELETE" 0x800f040b = "KEY_ENTER" 0x800f040c = "KEY_SLEEP" 0x800f040d = "KEY_MEDIA" 0x800f040e = "KEY_MUTE" 0x800f040f = "KEY_INFO" 0x800f0410 = "KEY_VOLUMEUP" 0x800f0411 = "KEY_VOLUMEDOWN" 0x800f0412 = "KEY_CHANNELUP" 0x800f0413 = "KEY_CHANNELDOWN" 0x800f0414 = "KEY_FASTFORWARD" 0x800f0415 = "KEY_REWIND" 0x800f0416 = "KEY_PLAY" 0x800f0417 = "KEY_RECORD" 0x800f0418 = "KEY_PAUSE" 0x800f0419 = "KEY_STOP" 0x800f041a = "KEY_NEXT" 0x800f041b = "KEY_PREVIOUS" 0x800f041c = "KEY_NUMERIC_POUND" 0x800f041d = "KEY_NUMERIC_STAR" 0x800f041e = "KEY_UP" 0x800f041f = "KEY_DOWN" 0x800f0420 = "KEY_LEFT" 0x800f0421 = "KEY_RIGHT" 0x800f0422 = "KEY_ENTER" #was KEY_OK before 0x800f0423 = "KEY_BACKSPACE" #was KEY_EXIT before 0x800f0424 = "KEY_DVD" 0x800f0425 = "KEY_TUNER" 0x800f0426 = "KEY_EPG"

0x800f0427 = "KEY_ZOOM"

0x800f0432 = "KEY_MODE"

0x800f0433 = "KEY_PRESENTATION"

0x800f0434 = "KEY_EJECTCD"

0x800f043a = "KEY_BRIGHTNESSUP"

0x800f0446 = "KEY_TV"

0x800f0447 = "KEY_AUDIO"

0x800f0448 = "KEY_PVR"

0x800f0449 = "KEY_CAMERA"

0x800f044a = "KEY_VIDEO"

0x800f044c = "KEY_LANGUAGE"

0x800f044d = "KEY_TITLE"

0x800f044e = "KEY_PRINT"

0x800f0450 = "KEY_RADIO"

0x800f045a = "KEY_SUBTITLE" 0x800f045b = "KEY_RED" 0x800f045c = "KEY_GREEN" 0x800f045d = "KEY_YELLOW" 0x800f045e = "KEY_BLUE" 0x800f0465 = "KEY_POWER2"

0x800f0469 = "KEY_MESSENGER"

0x800f046e = "KEY_PLAYPAUSE"

0x800f046f = "KEY_PLAYER"

0x800f0480 = "KEY_BRIGHTNESSDOWN"

0x800f0481 = "KEY_PLAYPAUSE"

Martii commented 2 years ago

@ErnstNeger

Glad you found a solution. :+1:

I wonder if it's a USB dropout issue. I've been seeing more and more of those even on Linux boxes. Usually a BIOS firmware update, if available, has helped on some of the machines but not all.

I've also seen some platforms that have too much on the USB hub (internally on mobo or discrete card) so I usually check with lsusb -t to ensure the bandwidth is not maxed out. Unfortunately I am unaware of how much power (mA) is used overall and available without dropping in a bunch of USB ammeters... and of course max usage on all devices.

ErnstNeger commented 2 years ago

I've also seen some platforms that have too much on the USB hub (internally on mobo or discrete card) so I usually check with lsusb -t to ensure the bandwidth is not maxed out. Unfortunately I am unaware of how much power (mA) is used overall and available without dropping in a bunch of USB ammeters... and of course max usage on all devices.

lsusb -t

/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=mceusb, 12M
        |__ Port 5: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 5: Dev 6, If 1, Class=Human Interface Device, Driver=, 1.5M

I'd argue the bandwith should be okay, note that port 1 is the onboard ethernet adapter of the RaspberryPi, apparently connected internally via USB. Port 3 and 5 are my actual peripherals (receiver and mouse/keyboard).

Martii commented 2 years ago

I'd argue the bandwith should be okay...

Hmmm your hub is 480M and Port 1 Dev 3 If 0 says it's allocating 480M right off the bat for that driver... then you have more on it. Not every device will use the full allocation 100% of the time but I'm guessing from a quick search that your smsc95xx driver which appears to be USB network adapter could max it out and break your receiver (connection... even if temporarily).

Just my 2 cent thoughts. :smile_cat:

ErnstNeger commented 2 years ago

Hmmm your hub is 480M and Port 1 Dev 3 If 0 says it's allocating 480M right off the bat for that driver... then you have more on it. Not every device will use the full allocation 100% of the time but I'm guessing from a quick search that your smsc95xx driver which appears to be USB network adapter could max it out and break your receiver (connection... even if temporarily).

Like I said, that's the RaspberryPi's onboard ethernet adapter, can't do much about that anyways.