Dual link DSI pannel display issue Huawei Matebook E 2022

Hello, I have a problem with kernels newer than v6.1.4. For some reason, my screen splits in half (when I rotate the screen, the split and orientation does not change).

I got the kernels directly from here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/refs/tags

This problem occurs with every Linux distribution I have tested.

Arch, Manjaro, Debian, Ubuntu, Fedora. Even without a display server, the error occurs in the console. Therefore, I think it must have something to do with the framebuffer.

I made Video from by now:

2024-12-01 18-17-39.mp4

For example, whenever the cursor flashes, the image on the left side of the monitor moves up and comes out at the bottom. Sometimes the right site does it as well, but not as often.

It is difficult to describe... A good example would be a toothed belt that you hold tight, and a motor tries to turn anyway. It's exactly the same kind of jerking with the picture.
It is interesting because it only occurs to a certain degree and does not go around like a conveyor belt. Sometimes one of the sites turns black first during poweroff or startup.

For testing, I use Fedora.

My hardware is a Huawei Matebook E See:inxi_output.txt

Unfortunately, for some reason I can't dump my VBios as I get an error that it is an invalid argument. https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/dump-video-bios.html

I also built a kernel as described here, using the default kernel from fedora 38. The kernel is v6.2.9-300. fc38. x86_64. This shows the same error. https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/build-guide.html Picture of the Screen v6.5.0-rc3+:

I'm sorry for the quality, but I can't get it better

Other Files:

intel_reg_dump.txt

lspci_output.txt

xrandr_output.txt

dmsg_output.txt

For sake of completeness, here is the bug report I had made before it was suggested that I should report it here. https://bugzilla.kernel.org/show_bug.cgi?id=217666

I'm still learning how all that works, so please send some links to or manuals where I can get some more Background knowledge.

added Community feature: display/Other platform: TGL labels

@johannes.nitschke.pe Please try with latest drmtip kernel and provide the i915 logs as in below instructions: drm.debug=0x1e log_buf_len=4M https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs

I think that's what you are asking about. dmesg_output_31.07.2023.txt

@johannes.nitschke.pe Thanks for the logs. in the attached logs, please have a look @armurthy modeset is falining: [ 7.720420] RIP: 0010:intel_modeset_verify_crtc+0x469/0x500 [i915] [ 7.720718] Code: 24 10 e9 2e fd ff ff 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 19 1d 21 de 48 89 da 48 c7 c7 80 cc aa c0 48 89 c6 e8 27 de 85 dd <0f> 0b e9 ff fd ff ff 48 8b 5f 50 48 85 db 75 03 48 8b 1f 89 4c 24 [ 7.720727] RSP: 0018:ffff9c13c07c3878 EFLAGS: 00010286

Could also indicate the state readout for dual link DSI is not correct. This isn't necessarily (or even likely) the root cause.

@johannes.nitschke.pe Can you please share the output of i915_display_info.

Looks like its a MIPI panel [ 21.025583] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:308:DSI-1] probed modes : [ 21.025586] [drm:drm_mode_debug_printmodeline] Modeline "2560x1600": 60 291594 2560 2762 2802 2842 1600 1615 1630 1710 0x48 0x5

Looks like the requested debug level is not enabled, drm.debug=0xe. Can you please use drm.debug=0x1e and then collect the dmesg?

@armurthy @suresh_kurmi Here you go. dmesg_output_01.08.2023.txt i915_display_info.txt

added feature: display/DSI label

@johannes.nitschke.pe Did it ever work properly, on any kernel you've tried?

Does grub show properly? Does it only get broken after i915 is probed?

Please attach the VBT from /sys/kernel/debug/dri/0/i915_vbt. (The vbios dump guide you referenced should be updated.)

@jani Yes grub shows properly, the Linux version where the issue first occurs is the v6.1.5. All versions I tested from before work.(Also "stock" distro-kernels)

Does it only get broken after i915 is probed? As for this question, I don't really know. I only know, that when I start the kernel in "save-mode" it works just fine. So I think this assumption might be correct.

Unfortunately, the guide shows the same Error.

i915_vbt

I also tried FreeBSD and installed a desktop environment, and it works properly. But I think that doesn't matter. (Edit: With the i915 driver, Free BSD gets a Purple Screen and that's it. Maybe I tested an older version of i915 with Free BSD back then)

Edit: When I plug in a Monitor, Projector, TV, they work fine. The issue on the main Display remains.

Does v6.1 work? The v6.1.z releases are all stable backports, so I just want to make sure where the problem was introduced.

I eyeballed through the i915 changes between v6.0 and v6.1 and nothing obvious stood out... but it's nearly 400 commits.

Since you seem to be able to compile your own kernels, the fastest way to find the issue just might be git bisecting it.

Sorry for the late response.

The v6.1.0 works just fine. It's just the jump from v6.1.4 to v6.1.5, that's where the error first was introduced.

I never used git bisect before. I hope, I used it correctly!

How I used it:

• $ git init
• $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
• $ git bisect start
• $ git bisect good v6.1.4
• $ git bisect bad v6.1.5
• $ cd linux && make oldconfig

After I recompiled (7 times) and gave git bisect good/bad feedback, it gave me this output:

gitbisec.txt

Good job on the bisect, thanks!

Well, except that it points at my commit that was crucial in fixing suspend/resume issues on a handful of other models.

Does suspend/resume work for you with v6.1.4?

No, unfortunately resume does not work. (v6.1.4 and v6.1.5)

@jani Any suggestion how to handle this bug, or a solution ?

It's a dual link DSI panel, so the symptoms aren't entirely surprising.

Gut feeling says this might be related to how we use and enable port sync mode in TRANS_DDI_FUNC_CTL2.

mentioned in issue #6476 (closed)

As I have the exact same problem Johannes described in this issue, I would like to ask, if I can do anything to help fixing this error. Currently I have to run a 6.0 kernel which is not maintained because there is no working LTS version. The display started working with kernel version 6.0.x (#6476 (closed)) and got the problem in 6.1.x (Johannes provided all the details).

Do you need further logs or anything else (tagging @jani because you already made assumptions for the cause of the issue)? Is there a possible workaround (as external displays work fine there might be an option to configure something to make the internal display work?)

@glU79z We could take the last working version of the kernel and apply the patches (gitbisec.txt). Then we can see which one is the problem and investigate it further.

changed title from Framebuffer-Display issue to Dual dsi pannel display issue Huawei Matebook E 2022

changed title from Dual dsi pannel display issue Huawei Matebook E 2022 to Dual link DSI pannel display issue Huawei Matebook E 2022

Sorry, this issue has been neglected a bit. :(

There's been a bunch of changes here, can anyone try v6.9 or drm-tip branch from https://gitlab.freedesktop.org/drm/tip with drm.debug=14 module parameter and attach dmesg from boot?

Please try this patch. It's a bit of a shot in the dark, but let's see.

0001-drm-i915-dsi-modify-MIPI_RESET_1-2-gpio-enable-disab.patch

I have built with the v6.9 tip you suggested. Unfortunately, the patch did not fix the problem. (Same as before):( (Maybe I faild to applay it correctly ?) I went into the cloned directory and used this command for patching. $patch -p1 < /path/to/your/0001-drm-i915-dsi-modify-MIPI_RESET_1-2-gpio-enable-disab.patch. Hope that drm.debug=14 is enabled correctly.

Without patch Dmesg-Vanilla-tip.txt

With the patch applied PatchedOutput.txt Thank you for your efforts. (I forgot to edit this back then)

So, I've done some testing and with those patches out of the Issue (mentioned in the git bisect), I recreated the error with those patches:

Used linux-6.1-rc7 to patch from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/refs/tags I applied 2 Patches from this the issue: #6131 (comment 1664948). The first patch: 0001-v6.1-rc7-drm-i915-dsi-add-support-for-ICL-native-MIP.patch

Then I saw that this was mentioned under the previous comment: ""Dual-link models (one Takahiro has) still require commit 8d58bb79 ("drm/i915/dsi: fix VBT send packet port selection for dual link DSI") on top. Included here as a patch for completeness, should apply to both v6.1-rc7 and v6.0.9:"" I also patched this:
0001-drm-i915-dsi-fix-VBT-send-packet-port-selection-for-.patch

@glU79z and @jani

I have now checked the patches individually and this one causes the error. Maybe it gives someone an idea how to solve this issue :).

0001-v6.1-rc7-drm-i915-dsi-add-support-for-ICL-native-MIP.patch

Edit:(If anyone wonders, the patch 0001-drm-i915-dsi-opportunistic-attempt-at-using-GPIO-on-.patch from #6131 (comment 1659626) didn't cause the issue.)

Since something might have changed with the new version 6.10.x, I am sending the dmesg of the new kernel 6.10.0-rc7+ (cloned from intel drm tip)

dmesg6.10.0-rc7+.txt

Here is the dmesg of the latest intel drm tip 03.10.2024 dmesg6.12.0-rc1+.txt

https://kernel.googlesource.com/pub/scm/linux/kernel/git/amlogic/linux/+/963bbdb32b47cfa67a449e715e1dcc525fbd01fc#:~:text=drm/i915/dsi:%20add%20support%20for%20ICL+ I found it may be this commit resulted the problem

Cc @jani

mentioned in issue #12045

I research into the difference of kernel 6.1.4 and 6.1.5 and found the problem lies in /drivers/gpu/drm/i915/display/intel_dsi_vbt.c in the source code of kernel. In 6.1.5, the kernel added a new function icl_native_gpio_set_value() which result the problem. Owing to lack of the knowledge of coding the kernel, i just annotated some of the code. And then i builded the kernel in my computer and install it. The flickering problem is gone with the version of kernel 6.11.1.

Here is my solution:

1. Download the source code of kernel you want after 6.1.5
2. Find the file intel_dsi_vbt.c in /linux-6../drivers/gpu/drm/i915/display/intel_dsi_vbt.c
3. In that file, find function icl_native_gpio_set_value(),(it's in line 323 in kernel 6.11.1) , and then annotated all of the code in case "MIPI_RESET_1" and "MIPI_RESET_2"
4. And then build this kernel and install it. That all.

And by the way, i found the code annotated is about Hot Plug Detect, and i guessed it may have some bad effect to that, next i would like to contact the author of that file to know more infomation about it.

Oh... I just try for a few times, it works newer than 6.1.4, such as 6.1.5, but 6.11.1 does not work properly, but do solved some problem, like screen flickering, but the screen was black, not able to display anything...

I test 6.2,6.3,6.4,6.5, The solution works well, but In the newer version of kernel, like 6.1.112 or 6.6, it is not works. Em,Is there anything i can do to solve this problem?

Hi @Rufish, Please look up the Bisect and the Patch I found, that caused the error. In my opinion, the best we can do is to dump the VBT. Since I wasn't able to dump it back then, I will try it later. Disabling this Case Switch itself won't fix the Issue. It is more likely that you will create new problems.

Here are a few thoughts from me, as I'm already working on this a bit. Spoiler: I'm not good at programming with c or c++, nor do I really know how the Intel etc. code really works. It could be nonsense from the start.

As you suggested, I think as well that the error might have its origin in the case statement. Specially, in the "calculation" of the Index Value. If our case cant handle the Index Value correctly, that could result in the incorrect behavior.

• +#define SHOTPLUG_CTL_DDI_HPD_OUTPUT_DATA(hpd_pin) (0x4 << (_HPD_PIN_DDI(hpd_pin) * 4))

Here is the whole case:

case MIPI_RESET_1:

case MIPI_RESET_2:

index = gpio == MIPI_RESET_1 ? HPD_PORT_A : HPD_PORT_B; +

• /* Set port hotplug to output */ /*Also the hotplug stuff didnt cause the Issue */
• intel_de_rmw(dev_priv, SHOTPLUG_CTL_DDI,
• SHOTPLUG_CTL_DDI_HPD_STATUS_MASK(index), 0);
• /* Set output value */
• intel_de_rmw(dev_priv, SHOTPLUG_CTL_DDI,
• SHOTPLUG_CTL_DDI_HPD_OUTPUT_DATA(index), /* This triggers the Error definitly*/
• value ? SHOTPLUG_CTL_DDI_HPD_OUTPUT_DATA(index) : 0);
• break;
• /* The if-statement will choose SHOTPLUG_CTL_DDI_HPD_OUTPUT_DATA(index) in case if you wonder */

---

I dumpt now the promised VBT, Here is how I've done it. $cp /sys/kernel/debug/dri/0000:00:02.0/i915_vbt /home/user/Downloads i915_vbt

$cat i915_vbt | hexdump -c > i915_vbt-heydump.txt i915_vbt-hexdump.txt

Edit: I now decoded the i915_vbt:intel_vbt_decode-i915_vbt.txt

I got the VBT file by this way, and i found my vbt file is the same as you uploaded before. Here is my vbt i915_vbt, and hex file i915_vbt-heydump.txt

uname -a Linux chafi-MatebookE-Ubuntu 6.8.0-45-generic #45 (closed)-Ubuntu SMP PREEMPT_DYNAMIC Fri Aug 30 12:02:04 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Which Bios REV. Do you use ? I use the newest 5.0 version. But the bug occurs even in the oldest Bios firmware...

My Bios version is 1.35, i have no idea whether the problem is about the version of Bios

@Rufish @jani I happened to be testing around with different kernel versions when this popped up. Sorry for the poor quality, but maybe this will help. I've been switching back and forth from newer to older kernel versions, testing them. This is the picture of the 6.8.5-301.fc40... "stock" Fedora workstation kernel. Maybe this could help. (I don't know if I can reproduce it again)

Edit: I saw similar things in other issues, I tested upwards Kernel version 6.1.4.

changed the description

@suresh_kurmi @jani

I gave it some thought, maybe I'm totally wrong (I mean I'm completely lost):

Could it be that the patch did not introduce the error, but instead triggered an existing problem in the framebuffer handling? The repeated [drm:drm_mode_addfb2] [FB:xxx] messages say that the driver is constantly creating new framebuffers. Is it properly releasing the previous ones? Could this be a framebuffer leak? For more details, please refer to the video I have added to the problem description. :)