Posts by HiassofT

  • Important change in LE13 remote handling

    Ah, likely you had media and exit buttons in a remote section - that won't work.

    The lirc/ir remote handler is quite limited, it only supports a handful button codes - see https://github.com/xbmc/xbmc/blob…slator.cpp#L161

    You had to map linux input codes (like KEY_MENU) to those kodi remote button codes via a Lircmap.xml and then map the kodi remote buttons to kodi actions in remote.xml.

    Quite annoying, especially if you had a remote with lots of buttons.

    Fortunately all this is gone now :)

    so long,

    Hias

  • Important change in LE13 remote handling

    Create a keyboard.xml with a keyboard instead of a remote section.

    The key/button codes are a bit different (remote had special remote button codes), eg instead of mute you likely have to use volume_mute - if in doubt check the HandleKey lines in kodi.log in debug mode.

    so eg this should work:

    Code
    <keymap>
  <global>
    <keyboard>
      <volume_mute>RunScript(/storage/.config/BTconnect.py)</volume_mute>
      <record>ToggleWatched</record>
    </keyboard>
  </global>
</keymap>

    Have a look at the system keyboard.xml for current default mappings and available key codes.

    Edit: kodi log shows it's tripping over the media and exit button/keycodes in your xmls.

    so long,

    Hias

  • Nightly Builds

    Quick heads up:

    We've now finally retired Generic-legacy and won't provide any updated LE13 image and addon builds for it anymore.

    If you were still using Generic-legacy please switch to Generic.

    so long,

    Hias

  • Development Support [RetroAchievements]

    I'd recommend building kodi, game.libretro and rcheevos with debug info and also enable the address sanitizer.

    You can pass in the needed options as environment variables when building LE, but personally I prefer to create a .libreelec/options file with them. eg:

    Code
    DEBUG="kodi game.libretro rcheevos"
DEBUG_SANITIZER_CFLAGS="-fsanitize=address -fno-omit-frame-pointer"

    Then do a full clean image and game.libretro addon build.

    The undefined behavior sanitizer can also be helpful - see the gcc docs https://gcc.gnu.org/onlinedocs/gcc…on-Options.html

    Another possibility is to run kodi with valgrind - it's a lot slower than the address sanitizer but may give additional info.

    To include valgrind in the image you need to enable it:

    Code
    VALGRIND="yes"

    and then manually start kodi with valgrind kodi --standalone -fs --audio-backend=alsa+pulseaudio

    Depending on where exactly it's crashing you may need to enable debug info for additional packages.

    so long,

    Hias

  • Nightly LE13: remote.xml not loaded

    Thanks for the info!

    This remote is a bit of a bitch (I have the Gmyle branded version here in a box), both the "i" button and the "right mouse" button generate the same button/keycode (BTN_RIGHT - right mouse button - which will bring up the context menu when you place the cursor at some entry).

    Previously we had remapped those two buttons to KEY_INFO via eventlircd, and I guess I should include the same mapping in LE13 - that remote was somewhat popular in the past.

    For now, please create a /storage/.config/hwdb.d/99-remote.hwdb file with the following content, then reboot.

    Code
    evdev:input:b0003v05A4p9881*
 KEYBOARD_KEY_90002=info

    Please report back if this works for you, too.

    so long,

    Hias

  • Nightly LE13: remote.xml not loaded

    Your remote seems to be generating a BTN_ instead of a KEY_ code for that button - that's problematic.

    What kind of remote is this? Is it an IR remote where you configured a ir-keytable in rc_maps.cfg? Or is it a remote with a USB / RF dongle or bluetooth?

    If it's an IR remote with ir-keytable/rc_maps.cfg config then the easiest solution is to just change that single code to a KEY_... keycode (look at /usr/lib/udev/rc_keymaps/rc6_mce.toml for the well supported KEY codes of the MCE remote).

    If it's an USB / RF / BT hid remote then you/we can remap that via a hwdb file:

    Install the System Tools addon from the LE repository, ssh in and post the content of /proc/bus/input/devices.

    Now stop kodi with "systemctl stop kodi".

    Then run "evtest", select the device matching your remote, push the button that didn't work in kodi and also post the full output. Some remotes expose multiple input devices, in that case go through them one-by-one and see which of them generates output on the button press.

    Please post the full output you got from evtest, including all the details it printed before waiting for the button press.

    Also please run "pastekodi" and post the URL you got.

    I'm currently collecting as much info as possible about all the remotes in use by our users to further improve kodi / LE - and that info will help me to decide if it's best to try to improve it in Kodi, or in LE, or if it's too special and it's best to guide users how they can fix it on their own.

    so long,

    Hias

  • Important change in LE13 remote handling

    Thanks to long-time joint effort work Kodi now has significantly improved input handling.

    This allowed us to finally drop the eventlircd workaround and use standard linux (lib)input handling for remotes, too.

    Currently LE13 images are building and the next nightlies will contain this change.

    One of the benefits is that Kodi now supports a lot more buttons/keys and the majority of the remotes should now work out-of-the-box.

    Another benefit of standard Kodi input handling is that you no longer need to fiddle around with Lircmap.xml or remote.xml to remap the buttons but can use the keymap editor addon from the kodi repo (or modify keyboard.xml).

    And this finally brings long-press support to remotes, too - which helps a lot if your remote has very few buttons. eg longpress-OK will open the context menu.

    As with every big change there will be some minor disruptions:

    If you previously adjusted the button mapping with remote.xml you'll now have to redo it.

    Even if you didn't change it the mapping may now be a bit different - just use the keymap editor addon to adjust it to your preferences.

    And although kodi now supports a lot more buttons it could be that your remote uses some keycodes that kodi doesn't support (yet).

    In this case we need your help so we can further improve Kodi and LibreELEC:

    Please tell us about the vendor and model of your remote and which buttons are not working and also post a kodi debug log:
    Enable debug logging in the kodi settings, then reboot, then just press the non-working keys and then upload the log - either by running "pastekodi" over ssh or with the log upload function in the LibreELEC settings - and post the URL to the log.

    so long,

    Hias

  • [x86-64] After switching from HDMI 2.0 TV to HDMI 2.1 no HDR anymore

    sebden no worries, you seem to have uncovered and interesting bug that likely existed for a long time but no-one noticed so far - and your logs and info were very helpful!

    Better go back to official nightlies, the washed-out colors are with HDR enabled are expected as your gen9 intel can't transmit the HDR infoframe.

    With HDR disabled (so kodi tonemaps HDR->SDR) the output should be identical in nightlies and smp's build.

    But signalling BT2020 for a HDR->SDR tonemapped image is still wrong, so the colors won't be correct, maybe oversaturated (likely both on your Sony and Samsung TVs) - that's something that needs to be fixed in kodi.

    While BT2020 colorspace with SDR gamma would be technically possible it's not a standard combination and it's hard to tell how TVs react to that - especially when the TV doesn't receive a HDR infoframe which would explicitly tell it the used EOTF - that's a bit of undefined territory.

    Your Sony seems to have received the (incorrect) BT2020 colorspace info correctly and shown "BT2020" to you and likely intepreted the BT709 data as BT2020. Not sure which EOTF it used, but if it had used PQ you'd likely have gotten over-bright white and in general a way to high contrast.

    Not sure about the Samsung, maybe it just didn't show you the BT2020 (or it's buried somewhere in deeper info pages).

    Nevertheless, if your PC didn't transmit the HDR infoframe and indicate PQ (or HLG) EOTF it's correct that the TV doesn't show "HDR".

    so long,

    Hias

  • [x86-64] After switching from HDMI 2.0 TV to HDMI 2.1 no HDR anymore

    I think I know now what's going on and it does look like a kodi bug to me:

    Even with a SDR display connected (which doesn't report support for BT2020) kodi sets the Colorspace connector property to BT2020 - and my HDFury also shows that in the received AVI infoframe.

    Code
    2026-06-15 19:59:50.957 T:935     debug <general>: virtual void KODI::WINDOWING::GBM::CWinSystemGbm::SetColorimetry(const VideoPicture*): setting connector colorspace to BT2020_RGB (source BT2020_YCC)

    But as the connector doesn't have the HDR_OUTPUT_METADATA property kodi it detects it as a SDR display and performs tonemapping:

    Code
    2026-06-15 19:59:50.957 T:935     debug <general>: LinuxRendererGLES::Configure: HDR passthrough: off
...
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: Requested render method: 0
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using shader format: NV12 red/red/green
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using tonemap method: reinhard
2026-06-15 19:59:51.210 T:935      info <general>: GLES: Selecting YUV 2 RGB shader
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using shader format: NV12 red/red/green
2026-06-15 19:59:51.210 T:935     debug <general>: GLES: using tonemap method: reinhard

    I'm not familiar with the inner details of kodi's tonemapping implementation but I highly suspect that will do both PQ->gamma EOTF transformation and also BT2020->BT709 colorspace transformation.

    So I guess kodi outputs a standard BT709/gamma SDR image, but signals BT2020 colorspace which doesn't quite match.

    smp could you have a closer look at the kodi code?

    so long,

    Hias

  • [x86-64] After switching from HDMI 2.0 TV to HDMI 2.1 no HDR anymore

    Quote from smp

    The log shows that HDR passthrough is now enabled. If the TV does doesn't switch to HDR mode then the theory that HDMI 1.4 can output HDR metadata is wrong.

    Just for the kicks I gave your build a try on an ancient gen6 system and got the same result:

    The HDR_OUTPUT_METADATA connector property now appears on the HDMI connector, and kodi set it, but I get the same kernel splat as in the OP's log and my HDFury Vrroom didn't report any HDR metadata - so the infoframe wasn't generated (as expected from the kernel splat)

    so long,

    Hias