Posts by Phil2011

So after some playing about I've managed to make a patch that:

1) Outputs YCbCr 4:2:0 @ 36-bit for 4K resolution

2) Outputs YCbCr 4:4:4 @ 36-bit for 1920x1080

It should still fall back to RGB if those modes are not supported. To detect if the resolution is 4K and to switch to 4:2:0 I've used the clock value and if over 500MHz assume it must be 4K, maybe a better way of doing that but it works.

Odd but for some reason Intel has no support for YCbCr 4:2:2 in the i915 driver.

The patch file created against the source 12.0.1 is below in case anyone finds it useful.

diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index bc975918e0..066a056a54 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2011,12 +2011,13 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
    if (clock > 600000)
        return MODE_CLOCK_HIGH;

-    ycbcr_420_only = drm_mode_is_420_only(&connector->display_info, mode);
+    ycbcr_420_only = drm_mode_is_420_only(&connector->display_info, mode) || clock > 500000;
+    

    if (ycbcr_420_only)
        sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
    else
-        sink_format = INTEL_OUTPUT_FORMAT_RGB;
+        sink_format = INTEL_OUTPUT_FORMAT_YCBCR444;

    status = intel_hdmi_mode_clock_valid(connector, clock, has_hdmi_sink, sink_format);
    if (status != MODE_OK) {
@@ -2199,7 +2200,7 @@ intel_hdmi_sink_format(const struct intel_crtc_state *crtc_state,
    if (connector->base.ycbcr_420_allowed && ycbcr_420_output)
        return INTEL_OUTPUT_FORMAT_YCBCR420;
    else
-        return INTEL_OUTPUT_FORMAT_RGB;
+        return INTEL_OUTPUT_FORMAT_YCBCR444;
}

static enum intel_output_format
@@ -2217,8 +2218,9 @@ static int intel_hdmi_compute_output_format(struct intel_encoder *encoder,
    const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
    const struct drm_display_info *info = &connector->base.display_info;
    struct drm_i915_private *i915 = to_i915(connector->base.dev);
-    bool ycbcr_420_only = drm_mode_is_420_only(info, adjusted_mode);
-    int ret;
+    int clock = adjusted_mode->clock;
+    bool ycbcr_420_only = drm_mode_is_420_only(info, adjusted_mode) || clock > 500000;
+    int ret;    

    crtc_state->sink_format =
        intel_hdmi_sink_format(crtc_state, connector, ycbcr_420_only);
@@ -2298,7 +2300,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder,
        adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
        return -EINVAL;

-    pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
+    pipe_config->output_format = INTEL_OUTPUT_FORMAT_YCBCR444;

    if (pipe_config->has_hdmi_sink)
        pipe_config->has_infoframe = true;

Quote from chewitt

That sounds like a textbook case of not using 4K60 "certified" cables. Resulting in insufficient bandwidth and sync problems.

That may well be the case although they are certified, or at least they say they are . However I still have the issue of RGB keeps making the TV switch to PC mode, and it only seems to run in RGB 8bit @ 4K when playing 10 bit video files. Given there is no advantage to using RGB for video and that RGB @ 4K is pushing the HDMI data rate to the max (where anything less than optimal can cause problems), I'm hoping all the issues resolve by outputting YCbCr 4:2:0. I've yet to test it on the TV but when I do I will report back.

The Amlogic box currently being used with CoreElec defaults to YCbCr 4:4:4 at HD and drops to 4:2:2 10 bit for 4K video and has had no issues.

I've never seen video playing devices default to RGB before with no option to change it, usually if they have the option of RGB its in the menus somewhere and never on by default. Using RGB for video is not the best for compatibility, and a shame the option isn't given to allow the user to choose the output format.

I've now tested the change and 4K playback issues are resolved. It now outputs YCbCr 4:2:0 36bit in 4K and perfect picture, no drop outs.

However.... on switching Kodi to 1920x1080 I just get a picture that is corrupted and unwatchable. I'm wondering if this is because HDMI doesn't support 1920x1080 at 4:2:0 and it needs to be 4:2:2?

Quote from smp

My Samsung TV would switch to PC mode only if the device icon is named "PC". It does not matter if the signal is RGB or YCbCr.

My TV switched itself to PC mode, I could select another source type for it, but every now and then it would switch back and identify itself as a PC, I assumed this was because of the RGB input.

The main issue though is at 4K in RGB the display loses sync constantly, so I'm hoping the drop to YCbCr at 4:2:0 will work as it does currently from all other sources.

I couldn't use the patch file linked to above, I think the source has changed so that the patch no longer works, so I made a new patch file and simply set in two places, ycbcr_420_only = true which follows after the call to 'drm_mode_is_420_only' to override that and force it into YcbCr, and made a did a new build image and on my computer monitor it is now outputting YCbCr 4:2:0, I will test on the TV tomorrow.

Many thanks for your help and point me in the write direction.

Many thanks, I've just setup a build environment and running a test build now, then will give those changes a try.

Super, thank you.

I have an issue with RGB output via my AV amp to Samsung TV, using Libreelec on an Intel N97 mini-PC.

1) HD 1920x1080 content plays to the TV as RGB 32bit - plays okay but see point 3.

2) 4K content plays to the TV as RGB 8bit which keeps losing sync (display keeps going black for several seconds and audio can drop in and out), so I'm guessing the data rate is too high, I get the same issue with Windows running as RGB 8bit @ 4K from the same box.

3) Because the output is in RGB, the TV wants to keep switching to PC mode (which isn't good for video/films)

Coreelec on an older AmLogic box always outputs YCbCr 4:2:0 at 10bit, this works perfectly with 4K 10bit and all other content. All other devices (NVidia shield, Blu-ray player etc) always defaults to YCbCr and have no issues either.

So questions is: How can I get Libreelec to output YCbCr for all content so I'm not having issues with the TV treating the input as a gaming or PC device and resolve the issues of the HDMI dropping out.

I do understand internally RGB is what is being used, and it stays as RGB on the output simply because there is no difference in quality to be gained by the conversion back, however this ignores compatibility. Many video editing processes use RGB internally, for example video editing software, but for compatibility and by convention, we encode the video back to YUV, yes it might be a waste of time doing that, but convention for video is to have it in that format. RGB output from video playing devices is not the norm.

Using Kodi with Windows gives me the option to set Windows to output YCbCr @ 10 bit, and this works perfectly, however if possible I'd like to use Libreelec for just enough OS for Kodi, I don't need the complications of Windows doing updates etc, but think the push to RGB on the output, despite best intentions, is causing some of us real headaches.

Just wondering if this can be added into the source to help others in the future, following on from this thread

Thread

Fix for Xiaomi bluetooth remote with nonworking button.

Hi,

Wanted to report a incorrect configuration for a Xiaomi remote and a fix for it. Documenting this fairly detailed to assist anyone else that may have a similar issue.

This is a guide on how to remap this invalid keycode. See "70-local-keyboard.hwdb" part for what should be added to libreelec's defaults.

# cat /proc/bus/input/devices

I: Bus=0005 Vendor=2717 Product=32b9 Version=4a4c

N: Name="Xiaomi RC Consumer Control"

P: Phys= ......................

S:…

patric

November 9, 2022 at 11:28 PM

I've created and added the following to the 70-local-keyboard.hwdb file to get the OK button working.

evdev:input:b0005v1D5ApC080e0000*
 KEYBOARD_KEY_c0041=enter