Hi everyone, Sorry that I forgot to CC the maintainers in the initial e-mail I sent yesterday, which can be found at the end of this e-mail.
I also would like to add further important details: * The problem is found on two additional custom PCs for a total of three custom PCs as follows: ** PC-1: Intel Celeron N5100 @ 1.10GHz whose integrated Intel video card is 8086:4e61 (JasperLake). ** PC-2: Intel N97 whose integrated Intel video card is 8086:46d1 (Alder Lake-N). ** PC-3: Intel N150 whose integrated Intel video card is 8086:46d4 (the newer Alder Lake-N). * The problem is _not_ found on the following custom PC: ** PC-4: Intel Celeron J4125 CPU @ 2.00GHz whose integrated Intel video card is 8086:3185 (UHD Graphics 600). The problem can be forced to occur on PC-4 by building the kernel at commit 99cfbed19d06 after rewriting line 702 of the file "intel_dp_link_training.c" (https://github.com/torvalds/linux/blob/99cfbed19d06dfe9c9929c436b5a768231c05b70/drivers/gpu/drm/i915/display/intel_dp_link_training.c#L702) to be: link_config[0] = DP_MSA_TIMING_PAR_IGNORE_EN; Therefore, it is clear that on PC-1, PC-2, and PC-3, the conditional expression "crtc_state->vrr.flipline" evaluates to true while on PC-4, it evaluates to false. The commit message says the following on changing the conditional expression from "crtc_state->vrr.enable" to "crtc_state->vrr.flipline": "I decided to leave the MSA timing ignore bit set all the time whether VRR is actually enabled or not. If the sink can figure out the timings with that information when VRR is active then surely it can also do it when VRR is inactive." That decision by Ville Syrjälä seems to not work with the AOC monitor 24P2Q, a DP-to-DP cable, and either PC-1 or PC-2 or PC-3. Ville Syrjälä assumed 3 years ago that the sink could figure out the timings regardless of whether VRR is active or inactive. The real case at hand with the AOC monitor 24P2Q, a DP-to-DP cable, and either PC-1 or PC-2 or PC-3 demonstrates that it seems not to be the case. Nevertheless, my question remains: is the rationale given by Ville Syrjälä for his decision 3 years ago invalid according to the DisplayPort (DP) standard and so the bug is in i915, or is the rationale valid according to the standard and so the bug is in the BIOSes of PC-1, PC-2, and PC-3? Thank you for your help. -- Best regards, Tadeus Prastowo On Mon, Jul 13, 2026 at 2:36 AM Tadeus Prastowo <[email protected]> wrote: > > Hi everyone, > > I have an AOC monitor with the following details: > * Product No. 24P2Q. > * Model No. 24P2. > * Manufactured in March 2021. > * Native resolution is 1920x1080. > * Input connections: DP, DVI, HDMI, and VGA. > * Product website: https://www.aoc.com/uk/monitors/24p2q > > The AOC monitor is connected to a custom PC with the following details: > * CPU: Intel(R) Celeron(R) N5100 @ 1.10GHz > (https://www.intel.com/content/www/us/en/products/sku/212329/intel-celeron-processor-n5100-4m-cache-up-to-2-80-ghz/specifications.html). > * Integrated Intel video card VID:PID is 8086:4e61 (JasperLake UHD graphics). > * The mainboard has two DP output ports. > > The monitor and the custom PC are connected with a DP-to-DP cable. > > The monitor has been working fine with Ubuntu 20.04 LTS in its native > resolution: 1920x1080@60. The Ubuntu 20.04 has Linux kernel version > 5.15. > > But, the monitor no longer works in its native resolution after > upgrading to Ubuntu 24.04 LTS: the monitor screen remains black. The > Ubuntu 24.04 has Linux kernel version 6.14. The monitor can work when > the resolution is set to 1024x768@60 using xrandr, but that is not the > solution of this problem because I want the monitor to work at its > native resolution. > > The problem remains when using the latest Ubuntu LTS (26.04), which > has Linux kernel version 7.0. > > Different DP-to-DP cables have been tested with Ubuntu 24.04, but the > problem remains. The monitor works with Ubuntu 24.04 when either a > DP-to-DVI or DP-to-HDMI or DP-to-VGA cable is used, but the monitor > cannot work with Ubuntu 24.04 when using a DP-to-DP cable, which > again, presents no problem whatsoever when using Ubuntu 20.04 with > kernel 5.15. > > The monitor works with Ubuntu 24.04 using a DP-to-DP cable when > connected to a different PC that uses a different Intel processor and > a different integrated Intel video card. > > In other words, the problem is specific to the custom PC described at > the beginning with a DP-to-DP connection to the AOC monitor. > > I have bisected the Linux kernel and found out that the cause of the > problem is the following diff-hunk of commit 99cfbed19d06 > (https://github.com/torvalds/linux/commit/99cfbed19d06#diff-eb927a6d3f0588695ab1a8f54a0c90a7a5feddcfa8379e49130b2594b819f686), > which is found between Linux kernel v6.4 and v6.5-rc1: > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c > @@ -699,7 +699,7 @@ intel_dp_prepare_link_train(struct intel_dp *intel_dp, > drm_dp_dpcd_write(&intel_dp->aux, DP_LINK_RATE_SET, > &rate_select, 1); > > - link_config[0] = crtc_state->vrr.enable ? DP_MSA_TIMING_PAR_IGNORE_EN : > 0; > + link_config[0] = crtc_state->vrr.flipline ? > DP_MSA_TIMING_PAR_IGNORE_EN : 0; > link_config[1] = intel_dp_is_uhbr(crtc_state) ? > DP_SET_ANSI_128B132B : DP_SET_ANSI_8B10B; > drm_dp_dpcd_write(&intel_dp->aux, DP_DOWNSPREAD_CTRL, link_config, 2); > > After I rebuilt the Linux kernel at commit 99cfbed19d06 by either > reverting the hunk or rewriting the assignment statement to > "link_config[0] = 0", the AOC monitor works fine again with the custom > PC using a DP-to-DP cable and Ubuntu 24.04 with my custom kernel. > > Since this problem persists even in the latest state of the Linux > kernel as of yesterday > (https://github.com/torvalds/linux/commit/44696aa3a489), my question > is then as follows: > > Is the actual problem the i915 driver or the BIOS of the custom PC? > Note that I do not blame the firmware of the AOC monitor because the > AOC monitor works fine when connected through a DP-to-DP cable to a > Ubuntu 24.04 running on a different PC that has a different Intel > processor and a different model of the integrated Intel video card. > > Thank you very much for any help. If you need further > information/test, just let me know. > > -- > Best regards, > Tadeus Prastowo
