Bug 1183001 - i915 graphics driver fails to auto-detect correct RGB colors range on 24 bit LCD monitor connected via HDMI
i915 graphics driver fails to auto-detect correct RGB colors range on 24 bit ...
Status: NEW
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 15.2
x86-64 openSUSE Leap 15.2
: P5 - None : Minor (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2021-03-04 00:57 UTC by David Kačerek
Modified: 2022-02-28 15:26 UTC (History)
4 users (show)

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Taken right after boot to desktop, with "drm.debug=0x1e" & "log_buf_len=4M" kernel parameters set in GRUB2. (440.00 KB, text/plain)
2021-03-04 00:57 UTC, David Kačerek
Details
"xrandr --verbose" output (10.20 KB, text/plain)
2021-03-04 01:00 UTC, David Kačerek
Details
Monitor Asset Manager (121.62 KB, image/png)
2021-03-08 19:05 UTC, David Kačerek
Details
dmesg output (5.72 KB, text/plain)
2021-03-09 21:08 UTC, David Kačerek
Details
kernel.log (1.66 KB, text/x-log)
2022-02-25 22:24 UTC, David Kačerek
Details
kernel2.log (15.83 KB, text/x-log)
2022-02-25 22:25 UTC, David Kačerek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Kačerek 2021-03-04 00:57:01 UTC
Created attachment 846731 [details]
Taken right after boot to desktop, with "drm.debug=0x1e" & "log_buf_len=4M" kernel parameters set in GRUB2.

Overview:
At the start of OS booting, colors are fine (black is deep). During booting, at the moment the Intel driver i915 is loaded, screen flickers once and colors get degraded (black gets grey). Note I'm not using Plymouth so I'm looking at the black tty. After the boot, when executing 'xrandr --output DP-1 --set "Broadcast RGB" Full', I can confirm the colors get immediately fixed up (white is light, black is deep, colors are more saturated). The issue is related to another bug report in upstream and is resolved for some people but not for me: https://bugs.freedesktop.org/show_bug.cgi?id=107476.

Steps to reproduce:
1) Start the PC.
2) Watch the boot console with Plymouth disabled.
3) Pay attention to the moment the screen flickers and the graphics driver is loaded.

Actual results:
Step 3) is the moment colors get degraded. And stay that way.

Expected results:
After the screen flickering during the step 3), colors should stay the same.

Affected Linux kernel versions:
The standard Linux version in openSUSE Leap 15.2: 5.3.18
The newest stable Linux from the Kernel:stable repo: 5.11.2

Affected hardware:
GPU: Intel Iris Plus Graphics 640 (Which uses the i915 kernel module = the common denominator of the problem reported by other people.)
LCD monitor: Iiyama ProLite XB2483HSU-B3 (Supports 24 bit colors, like other reported affected monitors.)
Comment 1 David Kačerek 2021-03-04 01:00:26 UTC
Created attachment 846732 [details]
"xrandr --verbose" output

Note xrandr detects the connected monitor as "DP-1" even though it's connected via HDMI. Maybe it's part of the problem since is affects monitors connected via DisplayPort and HDMI should be fine according to the upstream bug.
Comment 2 David Kačerek 2021-03-04 01:05:09 UTC
Comment on attachment 846731 [details]
Taken right after boot to desktop, with "drm.debug=0x1e" & "log_buf_len=4M" kernel parameters set in GRUB2.

dmesg output
Comment 3 Takashi Iwai 2021-03-08 16:37:02 UTC
Maybe EDID bpp is advertised wrongly, as the line shows:
[   93.155581] [drm:intel_atomic_check [i915]] [CONNECTOR:86:DP-1] Limiting display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp 36

It's the connector's display_info, and EDID seems missing the color depth info.
Comment 4 David Kačerek 2021-03-08 19:05:13 UTC
Created attachment 846905 [details]
Monitor Asset Manager

Output from the Windows app: Monitor Asset Manager.
Comment 5 David Kačerek 2021-03-08 19:13:34 UTC
(In reply to Takashi Iwai from comment #3)
> Maybe EDID bpp is advertised wrongly, as the line shows:
> [   93.155581] [drm:intel_atomic_check [i915]] [CONNECTOR:86:DP-1] Limiting
> display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp
> 36
> 
> It's the connector's display_info, and EDID seems missing the color depth
> info.

I checked the EDID information with the Windows app "Monitor Asset Manager" and indeed, it reports: "Color bit depth... undefined" (see the "Monitor Asset Manager" attachment. Is it something you can do anything about? E.g. patch the auto-detection logic so it automatically sets the full color range (0-255) for cases like this or for this specific monitor?
Comment 6 Takashi Iwai 2021-03-09 16:16:27 UTC
(In reply to David Kačerek from comment #5)
> (In reply to Takashi Iwai from comment #3)
> > Maybe EDID bpp is advertised wrongly, as the line shows:
> > [   93.155581] [drm:intel_atomic_check [i915]] [CONNECTOR:86:DP-1] Limiting
> > display bpp to 24 instead of EDID bpp 24, requested bpp 36, max platform bpp
> > 36
> > 
> > It's the connector's display_info, and EDID seems missing the color depth
> > info.
> 
> I checked the EDID information with the Windows app "Monitor Asset Manager"
> and indeed, it reports: "Color bit depth... undefined" (see the "Monitor
> Asset Manager" attachment. Is it something you can do anything about? E.g.
> patch the auto-detection logic so it automatically sets the full color range
> (0-255) for cases like this or for this specific monitor?

You can patch your kernel by yourself, of course :)

It should be possible to provide EDID externally via the firmware file, too.  This can override the missing bits.

The DRM core contains a quirk list for the some known badly working devices.  The workaround could be put there to enforce 12BPC there, too.  But I'm not sure whether that's the best fix.  You'd better to ask upstream.
Comment 7 Takashi Iwai 2021-03-09 16:32:37 UTC
Is the xrandr output in comment 1 after you set Broadcast RGB Full?  The log showed it's Auto.
Comment 8 Takashi Iwai 2021-03-09 16:42:26 UTC
Also, does the dmesg output contain the state after xrandr setup to change the Broadcast RGB?  That is, I'd like to see what xrandr actually does in the kernel side in this regard.

FWIW, the upstream bug tracker for LSPCON-HDMI setup was closed as fixed:
  https://gitlab.freedesktop.org/drm/intel/-/issues/32
Comment 9 David Kačerek 2021-03-09 19:10:58 UTC
(In reply to Takashi Iwai from comment #7)
> Is the xrandr output in comment 1 after you set Broadcast RGB Full?  The log
> showed it's Auto.

No, I took the xrandr output after the boot to the desktop, but BEFORE setting the "Broadcast RGB" property to Full. When I change the property to Full and take the xrandr output again, all that is changed there are the "Timestamp" lines and the "Broadcast RGB" line which then reports "Full" instead of "Automatic".
Comment 10 David Kačerek 2021-03-09 20:11:54 UTC
(In reply to Takashi Iwai from comment #8)
> Also, does the dmesg output contain the state after xrandr setup to change
> the Broadcast RGB?  That is, I'd like to see what xrandr actually does in
> the kernel side in this regard.
> 
> FWIW, the upstream bug tracker for LSPCON-HDMI setup was closed as fixed:
>   https://gitlab.freedesktop.org/drm/intel/-/issues/32

I rebooted the PC and waited for new dmesg output with "dmesg -w" while setting the "Broadcast RGB" to Full with xrandr but dmesg didn't put out anything new during that moment.

Regarding the LSPCON-HDMI bug report, it looks like it was closed due to inactivity rather than being fixed - see the last post. But thanks to that I've learnt that my computer (Intel NUC NUC7i5BNB) has this LSPCON converter on the motherboard so that is probably why xrandr detects the connected monitor as "DP-1" even though from the outside view it's a straight-through HDMI-to-HDMI connection.
Comment 11 David Kačerek 2021-03-09 21:08:28 UTC
Created attachment 846965 [details]
dmesg output

Result of:
sudo dmesg -C; xrandr --output DP-1 --set "Broadcast RGB" Full; dmesg > dmesg.txt
Comment 12 David Kačerek 2021-03-09 21:18:25 UTC
(In reply to David Kačerek from comment #10)
> (In reply to Takashi Iwai from comment #8)
> > Also, does the dmesg output contain the state after xrandr setup to change
> > the Broadcast RGB?  That is, I'd like to see what xrandr actually does in
> > the kernel side in this regard.
> > 
> > FWIW, the upstream bug tracker for LSPCON-HDMI setup was closed as fixed:
> >   https://gitlab.freedesktop.org/drm/intel/-/issues/32
> 
> I rebooted the PC and waited for new dmesg output with "dmesg -w" while
> setting the "Broadcast RGB" to Full with xrandr but dmesg didn't put out
> anything new during that moment.

Actually, there is a new dmesg output, I just forgot run the kernel with the drm.debug parameter before. But there's a little problem now with the parameter in that the dmesg output populates very fast and repeats some stuff in a short interval even when the PC is in idle state so "dmesg -w" is unreadable and scrolls very fast and endlessly. So to isolate the new output, I first cleared the kernel ring buffer, then set the "Broadcast RGB" to Full with xrandr and after that I finally exported the new dmesg output to a text file - see the new "dmesg output" attachment.
Comment 13 David Kačerek 2021-03-09 21:22:08 UTC
Comment on attachment 846965 [details]
dmesg output

Result of:
sudo dmesg -C; xrandr --output DP-1 --set "Broadcast RGB" Full; dmesg > dmesg.txt
Comment 14 Takashi Iwai 2021-03-10 14:53:40 UTC
Thanks.  Is the lot from Leap 15.2 kernel?  And, if I understand correctly, the problem is reproduced with 5.11.2 kernel, right?
Comment 15 Takashi Iwai 2021-03-10 14:59:26 UTC
Also, could you check 5.12-rc2 kernel in OBS Kernel:HEAD?  There are a few changes that look relevant with LSPCON and Colorimetry.
Comment 16 David Kačerek 2021-03-10 18:53:09 UTC
(In reply to Takashi Iwai from comment #14)
> Thanks.  Is the lot from Leap 15.2 kernel?  And, if I understand correctly,
> the problem is reproduced with 5.11.2 kernel, right?

I'm not sure what you mean by "lot", but if it means the 2 dmesg outputs I attached to the bug report then yes - they were produced on Leap 15.2 with its stock 5.3.18 kernel.

The problem was reproduced with the 5.11.2 kernel as well as with the latest 5.11.5 from the Kernel:stable repo.
Comment 17 David Kačerek 2021-03-10 18:55:14 UTC
(In reply to Takashi Iwai from comment #15)
> Also, could you check 5.12-rc2 kernel in OBS Kernel:HEAD?  There are a few
> changes that look relevant with LSPCON and Colorimetry.

I've checked and the problem persists.
Comment 18 Takashi Iwai 2021-03-11 07:41:12 UTC
(In reply to David Kačerek from comment #16)
> (In reply to Takashi Iwai from comment #14)
> > Thanks.  Is the lot from Leap 15.2 kernel?  And, if I understand correctly,
> > the problem is reproduced with 5.11.2 kernel, right?
> 
> I'm not sure what you mean by "lot",

Sorry for a typo, I meant "log" :)

> but if it means the 2 dmesg outputs I
> attached to the bug report then yes - they were produced on Leap 15.2 with
> its stock 5.3.18 kernel.
> 
> The problem was reproduced with the 5.11.2 kernel as well as with the latest
> 5.11.5 from the Kernel:stable repo.

OK, then the problem wasn't addressed at all, so we should report this to upstream.  Since the working case (after the RGB Broadcast Full) still shows the error message about limiting bpp, this might be a red herring, and the issue is rather something else (e.g. the limited RGB broadcast isn't properly implemented).

As a last shot, there is a kernel-vanilla package in OBS home:tiwai:kernel:drm-tip repo.  This is built from the very latest drm-tip tree, and that's often the upstream devs ask to try at first in a bug report.  Please give it a try, too.
Comment 19 David Kačerek 2021-03-11 21:59:57 UTC
> OK, then the problem wasn't addressed at all, so we should report this to
> upstream.  Since the working case (after the RGB Broadcast Full) still shows
> the error message about limiting bpp, this might be a red herring, and the
> issue is rather something else (e.g. the limited RGB broadcast isn't
> properly implemented).
> 
> As a last shot, there is a kernel-vanilla package in OBS
> home:tiwai:kernel:drm-tip repo.  This is built from the very latest drm-tip
> tree, and that's often the upstream devs ask to try at first in a bug
> report.  Please give it a try, too.

I've given a try to the drm-tip branch and the problem persists so I'll be reporting it upstream. But first, I've found a similar and opened bug report where I asked first whether to continue there or create a new bug report:
https://gitlab.freedesktop.org/drm/intel/-/issues/378

Let's keep this report open in case the upstream devs manage to produce a working patch so I could ask here to backport it to Leap.
Comment 20 Miroslav Beneš 2022-02-25 17:27:12 UTC
No development in the upstream bug reports. Unfortunately.

David, I suppose it still does not work for you. What about the latest stable kernel (OBS Kernel:stable)? Could you try it, please?
Comment 21 David Kačerek 2022-02-25 22:22:47 UTC
(In reply to Miroslav Beneš from comment #20)
> No development in the upstream bug reports. Unfortunately.
> 
> David, I suppose it still does not work for you. What about the latest
> stable kernel (OBS Kernel:stable)? Could you try it, please?

I have dependencies problem when installing the kernel. Either zypper complains about a lower version of filesystem pkg, or when using "--force-resolution" option during installation, it wants to remove half my system.
Comment 22 David Kačerek 2022-02-25 22:24:15 UTC
Created attachment 856589 [details]
kernel.log

Generated with:
LANG=C sudo zypper -p https://download.opensuse.org/repositories/Kernel:/stable/standard in kernel-default | tee Plocha/kernel.log
Comment 23 David Kačerek 2022-02-25 22:25:07 UTC
Created attachment 856590 [details]
kernel2.log

Generated with:
LANG=C sudo zypper -p https://download.opensuse.org/repositories/Kernel:/stable/standard in --force-resolution kernel-default | tee Plocha/kernel2.log
Comment 24 Takashi Iwai 2022-02-26 08:21:21 UTC
For installing on a Leap system, please use the kernel in OBS Kernel:stable:Backport, instead.
Comment 25 David Kačerek 2022-02-26 23:11:33 UTC
(In reply to Takashi Iwai from comment #24)
> For installing on a Leap system, please use the kernel in OBS
> Kernel:stable:Backport, instead.

So I've installed the kernel-default-5.16.11-lp153.2.1.g90630c5 from Kernel:stable:Backport, but I'm having a problem when booting the system with it.

First, the systemd-modules-load.service fails and a bit later, the boot gets stuck at "A start job is running for /dev/disk/by-uuid/20b...395". That 20b...395 partition is my root partition with Btrfs on it. So far, I've waited for 5 min and nothing changes.

I tried to get more info with rd.debug or loglevel=6 kernel parameters but it doesn't say anything more on the stuck job.

I also tried to check boot log with "journalctl -b -1 -p err" when fully booted with the stock 5.3 kernel, but the previous boot with the 5.16.11 kernel is not seen by journalctl, probably because the root is not mounted at that time so journald can't write to /var/log/.

I also tried to get to the shell with rd.break=pre-mount to check the failing service and stuck job more closely but while I get the shell indeed, I'm not able to type anything since my keyboard isn't enabled yet.

So I was fiddling around with dracut to get keyboard support at early boot, but "dracut -f --force-drivers usbhid /boot/initrd-..." didn't help - my keyboard is still dead.
Comment 26 David Kačerek 2022-02-27 17:52:35 UTC
(In reply to David Kačerek from comment #25)
> So I've installed the kernel-default-5.16.11-lp153.2.1.g90630c5 from
> Kernel:stable:Backport, but I'm having a problem when booting the system
> with it.
> ...

Ok, I've made it work. I've found out I was executing dracut omitting the "--kver" option by mistake so I re-created initrd with modules for then currently running kernel which was the stock 5.3. Now, after executing dracut with "--kver 5.16.11-lp153.2.g90630c5-default" I'm able to boot the latest stable kernel 5.6.11.

However, going back to the original problem, with the latest kernel, I still get washed out colors when "Broadcast RGB" property is set to Automatic.
Comment 27 Takashi Iwai 2022-02-28 15:26:14 UTC
Please keep pinging the upstream bug tracker.  It's worth to mention the latest kernel version you've verified.