No signal on 4K 60Hz DisplayPort monitor by default, until "max bpc" is lowered to 8

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

apport information

There doesn't seem to be any external monitor connected to this machine, or any 'DP-3' connector.

Please attach 'xrandr --verbose' info with a monitor connected showing the problem, or please open a new bug from the affected machine.

Note also that if you did have a machine that required:

  xrandr --output DP-3 --set "max bpc" 8

on a 4K 60Hz display then that may indicate a bandwidth problem. Maybe a limitation of the cable. Does a max bpc of 10 also work? What values don't work?

reply #20

yes, Daniel.
Originally, the display would like to use 10 bpc. but it is failed with some dongle.
However, we found that, it uses 8bit color depth on Windows. We wonder if Windows has done some magic for enhancing compatibilty. Maybe we can also discuss if we can have some implementation like export the bpc selection to gnome-control-center for user.

Otherwise, user can just found that it works on Windows but failed on Ubuntu.

I forgot a display signal doesn't include any alpha channel, so yeah 8 bpc will require less bandwidth than 10 bpc.

The maximum capability of the monitor should be advertised in its EDID. At least modern monitors do. You can check it using the 'edid-decode' command and grepping for 'bits per primary'. What gets returned?

Can you share the EDID of the troublesome display?

Upload the problem edid.

Thanks that does seem to be an old EDID v1.3 with no defined bit depth. But there are some vendor-specific blocks there that do advertise support for 10bpc and 12bpc.

In this case I think it's correct to try and default to 10bpc or 12bpc. It's probably only the cable or dongle letting it down. I wonder if such limited cable bandwidth is something we can detect in software?...

Imagine (or please test) what a newer monitor with an EDID v1.4 would do. If that reported more definite support for 10bpc then it would be even more correct to try and default to 10bpc. But we would also need more intelligent logic (somewhere) that detects when the desired bandwidth isn't being achieved due to cable or dongle problems.

This change was made by a bot.

My monitor is EDID 1.3 and it has the same problem.

edid-decode (hex):

00 ff ff ff ff ff ff 00 41 0c 8f c1 bd 07 00 00
08 1d 01 03 80 3c 22 78 2a 67 a1 a5 55 4d a2 27
0e 50 54 bf ef 00 d1 c0 b3 00 95 00 81 80 81 40
81 c0 01 01 01 01 4d d0 00 a0 f0 70 3e 80 30 20
35 00 55 50 21 00 00 1a a3 66 00 a0 f0 70 1f 80
30 20 35 00 55 50 21 00 00 1a 00 00 00 fc 00 50
48 4c 20 32 37 36 45 38 56 0a 20 20 00 00 00 fd
00 17 50 1e a0 3c 00 0a 20 20 20 20 20 20 01 72

02 03 33 f1 4c 90 04 03 1f 13 01 12 5d 5e 5f 60
61 23 09 07 07 83 01 00 00 6d 03 0c 00 10 00 38
78 20 00 60 01 02 03 67 d8 5d c4 01 78 80 03 e3
0f 00 0c 56 5e 00 a0 a0 a0 29 50 30 20 35 00 55
50 21 00 00 1e 02 3a 80 18 71 38 2d 40 58 2c 45
00 55 50 21 00 00 1e 01 1d 00 72 51 d0 1e 20 6e
28 55 00 55 50 21 00 00 1e 4d 6c 80 a0 70 70 3e
80 30 20 3a 00 55 50 21 00 00 1a 00 00 00 00 4e

----------------

EDID version: 1.3
Manufacturer: PHL Model 49551 Serial Number 1981
Made in week 8 of 2019
Digital display
Maximum image size: 60 cm x 34 cm
Gamma: 2.20
DPMS levels: Off
RGB color display
First detailed timing is preferred timing
Color Characteristics
  Red: 0.6455, 0.3339
  Green: 0.3017, 0.6357
  Blue: 0.1542, 0.0566
  White: 0.3125, 0.3291
Established Timings I & II
    720x400 70.082 Hz 9:5 31.467 kHz 28.320 MHz (IBM)
    640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz (DMT)
    640x480 66.667 Hz 4:3 35.000 kHz 30.240 MHz (Apple)
    640x480 72.809 Hz 4:3 37.861 kHz 31.500 MHz (DMT)
    640x480 75.000 Hz 4:3 37.500 kHz 31.500 MHz (DMT)
    800x600 56.250 Hz 4:3 35.156 kHz 36.000 MHz (DMT)
    800x600 60.317 Hz 4:3 37.879 kHz 40.000 MHz (DMT)
    800x600 72.188 Hz 4:3 48.077 kHz 50.000 MHz (DMT)
    800x600 75.000 Hz 4:3 46.875 kHz 49.500 MHz (DMT)
    832x624 74.551 Hz 4:3 49.726 kHz 57.284 MHz (Apple)
   1024x768 60.004 Hz 4:3 48.363 kHz 65.000 MHz (DMT)
   1024x768 70.069 Hz 4:3 56.476 kHz 75.000 MHz (DMT)
   1024x768 75.029 Hz 4:3 60.023 kHz 78.750 MHz (DMT)
   1280x1024 75.025 Hz 5:4 79.976 kHz 135.000 MHz (DMT)
Standard Timings
   1920x1080 60.000 Hz 16:9 67.500 kHz 148.500 MHz (DMT)
   1680x1050 59.954 Hz 16:10 65.290 kHz 146.250 MHz (DMT)
   1440x900 59.887 Hz 16:10 55.935 kHz 106.500 MHz (DMT)
   1280x1024 60.020 Hz 5:4 63.981 kHz 108.000 MHz (DMT)
   1280x960 60.000 Hz 4:3 60.000 kHz 108.000 MHz (DMT)
   1280x720 60.000 Hz 16:9 45.000 kHz 74.250 MHz (DMT)
Detailed mode: Clock 533.250 MHz, 597 mm x 336 mm
               3840 3888 3920 4000 ( 48 32 80)
               2160 2163 2168 2222 ( 3 5 54)
               +hsync -vsync
               VertFreq: 59.997 Hz, HorFreq: 133.312 kHz
Detailed mode: Clock 262.750 MHz, 597 mm x 336 mm
               3840 3888 3920 4000 ( 48 32 80)
               2160 2163 2168 2191 ( 3 5 23)
               +hsync -vsync
               VertFreq: 29.981 Hz, HorFreq: 65.688 kHz
Display Product Name: PHL 276E8V
Display Range Limits
  Monitor ranges (GTF): 23-80 Hz V, 30-160 kHz H, max dotclock 600 MHz
Has 1 extension block
Checksum: 0x72

----------------

CTA-861 Extension Bl...

Regaring comment #26, I am using PX UH-1.2MX HDMI 2.0 certified Premium High Speed cable so the cable's quality should not be a problem.

Yeah the world is full of subtle connection problems. In this particular case, dropping back to 8bpc would fix it. But I'm not sure how we would detect that automatically, or if it's even the right thing to do in most cases.

I guess Windows is good at compatibility and defaulting to 8bpc is safe. But unless we have a GUI that allows users to then select 10bpc, defaulting to 8bpc is not something we should do.

reply #30,

Agree, I think we should add GUI option for user to set it.

Realistically I do not expect this bug to be fixed. Because we don't want to lower the default from 10bpc when the rest of us are trying to enable 10bpc in more cases, and adding a GUI to make it configurable is a multi-month effort because multiple projects would be involved there. But if you want to get the ball rolling on a GUI then I suggest requesting it at:

  https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues

This bug *might* be fixed without a GUI if some kind of error check and fallback can be automated in the modesetting code. For Xorg sessions that's in the 'xorg-server' project and for Wayland sessions that's the 'mutter' project.

I think different from #32.
To adding a GUI configure bpc is a long-term plan.

Before that,the default behavior should be designed to get the best user experience.
As we all know, there're lot of hardware components on the pipline of display path(e.g. socket, converter, dongle, cable, monitor)

With any lower quality component on the pipeline, dark screen or function lost is not acceptable.
It should be better to provide lower default bpc than dark user's screen.

Afterall, user can adjust the bpc by command in short-term or by UI in long-term plan.
But if we just dark user's screen, user mostly thinks the hardware is broken or Ubuntu provides poor compatibility(if they compare the same component to Windows).

No problem. It's not up to me anyway...

Long term, to get the GUI work done you will need to request enhancements in both of these projects:

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues
https://gitlab.gnome.org/GNOME/mutter/-/issues

Short term, to get the default changed you will need to request an enhancement here:

https://gitlab.freedesktop.org/xorg/xserver/-/issues

When done, please tell us the new issue IDs.

Thanks for understanding.
There's an upstream bug discussing this similar issue, we can follow their effort there.
https://gitlab.freedesktop.org/drm/intel/-/issues/1890

I guess my only request is that:

if (EDID_version >= 1.4 && EDID_supports_10bit) then
  don't restrict "max bpc"
endif

I afraid we can not just trust (EDID_version >= 1.4 && EDID_supports_10bit). Because this issue caused by any problematic component in the middle of pipeline. To ensure the compatibility, better to just defautly set bpc=8.

Think of one scenario, a speaker get his Ubuntu machine onto stage, plug the HDMI or DP projector which works well on latest speaker who is using Windows machine. Then, he get dark screen or audio function lost....

I guess the Ubuntu user might not aware it's caused by bpc. The default behavior should offer better user experience.

My concern is that you might be taking functionality (deep/wide colour) away from people for whom it works.

This is a kernel bug so not sure if it's wise to fix it from userspace...

according to #40 and conversation on mattermost with Kai-Heng.
HWE is planning to add quirk for the faulty dongles so that the dark screen during boot time[1] can be fixed.

[1] https://gitlab.freedesktop.org/drm/intel/-/issues/1890

Upstream is also working on the same kind of issue:

https://gitlab.gnome.org/GNOME/mutter/-/issues/1391

reply to #39,
yes.... it's a trade off that we don't either want user get darkscreen when then randomly plug display port for case like #38 or user get lower bpc on their working display port.

So far, there seems no solid way to make sure both requirement.

Silly question:

Why not just default to 8 bpc and then only increase it to maximum 10/12/14/16 bpc if byte 20, bits 6-4 say that deep colour is supported by the monitor?

https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#Structure,_version_1.4

... because the EDID this bug is about (comment #23) is version 1.3. So it would get the default 8 bpc.

Hello Denial,

Do you mean if the monitor EDID < 1.4, set max bpc to 8 in kernel directly?
Do I understand it correctly?

I mean only EDID version 1.4 and later advertises depth, so use that but default to 8 bpc:

Set bpc to 8.
if ((EDID >= 1.4) && (a depth is advertised in byte 20 bits 6-4)) then
  Set bpc to the depth advertised in the EDID.
endif

So for this bug it would stay with bpc=8, because the EDID is only version 1.3 and does not provide any depth info.

Intel GFX dev has a branch that works:
git://github.com/vsyrjala/linux.git dp_downstream_ports_6

Will backport the branch once it hits upstream.

Full URL:
https://github.com/vsyrjala/linux/tree/dp_downstream_ports_6

apparently fixed by the series ending at

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=181567aa9f0d297804f1ea5d3ff4ba4518e05f2c

included in 5.10-rc1

Sounds like a plan, if it works. Just patch the kernel to choose a more sane default.

I came across this bug because of my problem which I described in

https://askubuntu.com/questions/1314639/weird-graphics-artifacts-monitor-off-with-ubuntu-20-04-and-nvidia-rtx-5000/1343876#1343876

In my case the Dell monitors tell, they can support 30bit.

I came to the conclusion, that the dockingstation's Displayports cannot handle 30bit which leads to strange screen artifacts.

However, the HDMI port of the dockingstation outputs 24bits and I have no screen corruption, connecting them directly to laptop is also no problem.

In Windows the output is limited at 24bits and the output is reliable.

xrandr with "max bpc" 8" is not working me and brings strange errors.

Is there any other way to tell Linux system to limit to 24bits?
Even before the Desktop appears the console has already switched to 30 bit (according to Monitor OSD info) without any EDID hacking?
 The Laptop is used daily across different dockingstations with different monitors (Home/Work)

System config:
- Dell Precision 15" 7540, Xeon E-2286M@2.4GHz, 128 GB ECC RAM, NVIDIA Quadro RTX 5000 16GB VRAM
- Dockingstations at Home and offices: WD19DC
- Dockingstation 1 WD19DC: 2xDell 43' U4320Q
- Dockingstation 2 WD19DC: 2xDellxU3818DW, 37.5" + Laptopdisplay

I just solved my 30bit problem with an Displayport to HDMI adapter[1].
Now the screens operate at 4k 60Hz 24bits in Linux and no more screen corruption.

This should also fix the problem for some people in Wayland sessions:

  https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1834

It is in mutter release 40.1 and future release 3.38.5.