【Solved】Display Problems on Repaired HP-Envy 15t-ep000

[nmssis]

I will let you know some time later tomorrow what I may be able to glean from these. I'm hoping there will be something different between the two sets which indicates what might be happening.

Sounds good! Thank you!

[SMG]

Just an intermediate update: I finished comparing the Xorg logs. The files had very few differences and I could not relate those differences to what is happening with the display.

In the Xorg log file, the laptop display is referenced as:

Code: Select all

[     7.054] (II) modeset(0): Manufacturer: CMN  Model: 1519  Serial#: 0

I looked up that and found Innolux 15.6" IPS LCM 1920×1080 400nits WLED eDP 30pins CMN1519. That is a WLED screen that is not a touchscreen according to that page.

If your touchscreen was working after it returned from the repairs, then X Server is not using information which matches your screen, but I do not know that it matters for what X Server is doing with that information. Later lines in the log indicate it is recognized as a touchscreen.

Code: Select all

[     7.359] (II) event6  - ELAN2513:00 04F3:2B74: is tagged by udev as: Touchscreen
[     7.359] (II) event6  - ELAN2513:00 04F3:2B74: device is a touch device

From what I could find, this warning message below means the Nvidia card is not directly connected to the laptop screen. That may be because your laptop was in Intel or On-Demand mode which has the Intel gpu running the screen, so it is not a concern.

Code: Select all

[     7.083] (WW) NVIDIA(G0): Unable to get display device for DPI computation.

The only differences between the two files is the first set below was in the 5.4 kernel Xorg log and not the 5.8 kernel's log. I do not know what this might reference, but if Intel is running the display then it is not likely to matter.

Code: Select all

[     7.648] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=11 (/dev/input/event21)
[     7.648] (II) No input driver specified, ignoring this device.
[     7.648] (II) This device may have been added with another device file.
[     7.649] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=8 (/dev/input/event18)
[     7.649] (II) No input driver specified, ignoring this device.
[     7.649] (II) This device may have been added with another device file.
[     7.649] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=10 (/dev/input/event20)
[     7.649] (II) No input driver specified, ignoring this device.
[     7.649] (II) This device may have been added with another device file.
[     7.650] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=7 (/dev/input/event17)
[     7.650] (II) No input driver specified, ignoring this device.
[     7.650] (II) This device may have been added with another device file.
[     7.650] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=9 (/dev/input/event19)
[     7.650] (II) No input driver specified, ignoring this device.
[     7.650] (II) This device may have been added with another device file.
[     7.651] (II) config/udev: Adding input device HDA NVidia HDMI/DP,pcm=3 (/dev/input/event16)
[     7.651] (II) No input driver specified, ignoring this device.
[     7.651] (II) This device may have been added with another device file.

And the below was in the 5.8 kernel Xorg log and not the 5.4 kernel Xorg log. If I recall correctly, I think it may just be a spurious event. This is not the first time I've seen it in Xorg logs.

Code: Select all

[   204.730] (EE) event9  - SYNA32A6:00 06CB:CE24 Touchpad: kernel bug: Touch jump detected and discarded.
See https://wayland.freedesktop.org/libinput/doc/1.15.5/touchpad-jumping-cursors.html for details

Going to go back through the dmesg info now. I did a quick pass of each before comparing the Xorg logs and nothing jumped out at me, but will take a closer look.

Do you notice if the toggling between the full and half screen seems to be on a set time frequency? Does it happen at regular intervals or irregular intervals?

[nmssis]

The only differences between the two files is the first set below was in the 5.4 kernel Xorg log and not the 5.8 kernel's log. I do not know what this might reference, but if Intel is running the display then it is not likely to matter.

When I used the command for the results it was on NVIDIA On-Demand mode. Although I am not sure if this is useful in this case or not.

Do you notice if the toggling between the full and half screen seems to be on a set time frequency? Does it happen at regular intervals or irregular intervals?

So far it does vary depending if I am on the login screen or the regular desktop environment. But both of them do happen at irregular intervals. On login, the toggling between the full and half screen is severe as I would have to login as fast as possible or else it would start doing the same thing as the second video. However on the desktop environment it does not occur nearly as much. However it still occurs around once a minute but sometimes it glitches consecutively in the span of three seconds.

P.S (regarding the touchscreen): The touchscreen did work after the repair.

[SMG]

So far it does vary depending if I am on the login screen or the regular desktop environment.

That is interesting. I will check to see what processes may or may not be running at that point.

However on the desktop environment it does not occur nearly as much. However it still occurs around once a minute but sometimes it glitches consecutively in the span of three seconds.

I was thinking it might relate to a system service polling at regular intervals, but the 3 second glitches makes that seem not likely.

[nmssis]

However on the desktop environment it does not occur nearly as much. However it still occurs around once a minute but sometimes it glitches consecutively in the span of three seconds.

I was thinking it might relate to a system service polling at regular intervals, but the 3 second glitches makes that seem not likely.

One thing to add is that the three second glitches rarely ever happen. So majority of the glitches happen around the 1 minute mark.

Another thing (most likely unrelated) is that when I would run virtual machines on my computer, the amount of times the screen fluctuates from half to full screen reduces in a considerable amount and the virtual machine does not have any half screen issues.

[SMG]

Another thing (most likely unrelated) is that when I would run virtual machines on my computer, the amount of times the screen fluctuates from half to full screen reduces in a considerable amount and the virtual machine does not have any half screen issues.

What OS's are the virtual machines?

[nmssis]

What OS's are the virtual machines?

The OS's are Linux Mint 19.2 (Cinnamon Edition), Arch Linux (not properly set up at all), and Pop OS.

[SMG]

It took me a while to determine what were differences because of how the kernel might interact with the hardware and what might be actual differences in how the system was running because of the hardware. Based on the messages, it appears the 5.8 kernel is a better match for your hardware.

Best as I can tell, this seems like this issue may be related to the i915 Intel driver. I found the following line in the dmesg of the 5.4 kernel.

Code: Select all

[Thu Apr  8 19:23:28 2021] i915 0000:00:02.0: Failed to program MOCS registers; expect performance issues.

In fact, you are seeing performance issues. The image is not stable with the 5.4 kernel while it is with the 5.8 kernel (but not the correct image size).

Have you had to log in real fast when using the 5.8 kernel? Are you seeing the same type of color degradation issue you are noticing with the 5.4 kernel?

The two might be using slightly different versions of the driver, but I think the kernel used in conjunction with the driver is also a factor.

Code: Select all

5.4 - [Thu Apr  8 19:23:28 2021] [drm] Initialized i915 1.6.0 20190822 for 0000:00:02.0 on minor 0
5.8 - [Thu Apr  8 19:16:40 2021] [drm] Initialized i915 1.6.0 20200515 for 0000:00:02.0 on minor 0

Let's see if dmesg -T | grep -i "drm\|i915" gives any clues as to what might be happening. I believe the output will be short enough you can post it here within the code tags. I'm hoping it will show more info that what was in the prior outputs, but if not, I'll have to figure out where/what to check next as to what might be happening.

[SMG]

What OS's are the virtual machines?

The OS's are Linux Mint 19.2 (Cinnamon Edition), Arch Linux (not properly set up at all), and Pop OS.

I do not know the specifics of your installs, but I think VirtualBox uses different graphics drivers for the display which is another reason why I think this issue might be related somehow to the graphics drivers.

The issue I have not quite figured out is why the image on the display is squished, but the dimension of the display is correct (you have light and color across the entire display). It's as if somewhere in the code something is dividing by two when it should not.

[SMG]

This ISO Linux Mint 20.1 "Ulyssa" - Cinnamon (Edge, 64-bit) has the 5.8 kernel in it and would be a way to test the 5.8 kernel without having to keep changing back and forth between kernels on your install.

Booting to it in Compatibility Mode to a live session of Mint should disable the graphics drivers. I'm curious if you would get a full display or a half display with it. You will get a message from Cinnamon about running without hardware acceleration because booting that way uses software rendering of graphics.

[nmssis]

Have you had to log in real fast when using the 5.8 kernel? Are you seeing the same type of color degradation issue you are noticing with the 5.4 kernel?

So sorry about the delayed response! For the 5.8 kernel I did not need to login fast. There is the same color degradation issue for both the 5.4 and 5.8 kernel.

Let's see if dmesg -T | grep -i "drm\|i915" gives any clues as to what might be happening. I believe the output will be short enough you can post it here within the code tags. I'm hoping it will show more info that what was in the prior outputs, but if not, I'll have to figure out where/what to check next as to what might be happening.

Here is the code for dmesg -T | grep -i "drm\|i915":

Code: Select all

[Fri Apr  9 00:08:39 2021] fb0: switching to inteldrmfb from EFI VGA
[Fri Apr  9 00:08:39 2021] i915 0000:00:02.0: vgaarb: deactivate vga console
[Fri Apr  9 00:08:39 2021] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[Fri Apr  9 00:08:39 2021] [drm] Driver supports precise vblank timestamp query.
[Fri Apr  9 00:08:39 2021] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=io+mem
[Fri Apr  9 00:08:39 2021] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[Fri Apr  9 00:08:39 2021] i915 0000:00:02.0: Failed to program MOCS registers; expect performance issues.
[Fri Apr  9 00:08:39 2021] [drm] Initialized i915 1.6.0 20190822 for 0000:00:02.0 on minor 0
[Fri Apr  9 00:08:39 2021] fbcon: i915drmfb (fb0) is primary device
[Fri Apr  9 00:08:40 2021] i915 0000:00:02.0: fb0: i915drmfb frame buffer device
[Fri Apr  9 00:08:41 2021] systemd[1]: Condition check resulted in Load Kernel Module drm being skipped.
[Fri Apr  9 00:08:43 2021] sof-audio-pci 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[Fri Apr  9 00:08:43 2021] [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
[Fri Apr  9 00:08:44 2021] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[Fri Apr  9 00:08:44 2021] [drm] No driver support for vblank timestamp query.
[Fri Apr  9 00:08:44 2021] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:01:00.0 on minor 1
[Fri Apr  9 00:09:15 2021] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

This ISO Linux Mint 20.1 "Ulyssa" - Cinnamon (Edge, 64-bit) has the 5.8 kernel in it and would be a way to test the 5.8 kernel without having to keep changing back and forth between kernels on your install.

Booting to it in Compatibility Mode to a live session of Mint should disable the graphics drivers. I'm curious if you would get a full display or a half display with it. You will get a message from Cinnamon about running without hardware acceleration because booting that way uses software rendering of graphics.

I will try this and boot into compatibility mode. I'll let you know how it goes.

[SMG]

All the lines except the last one were in the previous dmseg files. I have seen the last message

Code: Select all

 [Fri Apr  9 00:09:15 2021] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

in relation to computers with Intel graphics resuming from sleep mode such as in this thread Screen flashing with Intel HD 630 - RESOLVED. Given your issue seems to be more than flickering, I'm not sure if that workaround might be appropriate.

We'll see how the 'compatibility mode' test goes to come up with a game plan of what might be worth trying.

[nmssis]

I tried to use compatibility mode for the Linux Mint Edge ISO, and there were few interesting things to point out as I booted into compatibility mode in the live environment.

When everything was loaded for the live environment to display, the screen was at full display. However, the mouse, the keyboard, nor the touchscreen would interact with the screen. Initially it appeared to be frozen until I pressed the power button. Then it would show the pop up about shutting down. But then it would stay frozen as well. Here is the imgur link to see this: https://imgur.com/a/5vqLJt1

P.S: The colors did not tint at all during this process. And if a video is necessary, I will repeat the process again and record it!

[SMG]

When everything was loaded for the live environment to display, the screen was at full display.
...
The colors did not tint at all during this process.

That screenshot is the best your laptop screen has looked. Sigh. This test seems to confirm the issue is related to the graphics driver for Intel.

I noticed HP released new Intel drivers for your model this year (for the Windows version), so they obviously found something which was not quite right and it was fixed. I do not know what that might have been.

However, the mouse, the keyboard, nor the touchscreen would interact with the screen.

I was anticipating that might happen given what happened when you tested LM19.3. I think that may be a driver-related issue. While we often recommend Compatibility Mode because it disables graphics drivers, it also disables some other drivers as well. I expected your wireless not to connect because of that and I see the disconnected symbol in the panel.

One can add the kernel parameter nomodeset to the live session boot which disables just the graphics drivers. Here are the instructions Linux Mint Installation Guide: Nomodeset boot option. I'm putting them here so we have them handy as I'm hoping to find a solution which does not disable the graphics, but probably will involve kernel parameters. I think booting the live session is a less cumbersome way to test with the 5.8 kernel given your graphics are a bit more stable with the 5.4 kernel installed.

I will do some more searching and let you know what I find.

[nmssis]

One can add the kernel parameter nomodeset to the live session boot which disables just the graphics drivers. Here are the instructions Linux Mint Installation Guide: Nomodeset boot option. I'm putting them here so we have them handy as I'm hoping to find a solution which does not disable the graphics, but probably will involve kernel parameters. I think booting the live session is a less cumbersome way to test with the 5.8 kernel given your graphics are a bit more stable with the 5.4 kernel installed.

Im gonna try the nomodeset and I’ll let you know!

[SMG]

Im gonna try the nomodeset and I’ll let you know!

That will put the system into software rendering mode for graphics, so expect to see a warning message from Cinnamon about "no hardware acceleration".

[SMG]

I found a bug report of the issue Split screen/display corruption issue on HP Envy 15-ep0004ns. The person found the 5.5 kernel was the last one that worked which fits with our observation that 5.4 works (mostly) and 5.6 was squished screen.

While that bug is not listed as closed, that discussion had a link to an older bug report which had some interesting observations.

In the older bug thread from 2016-2017 Comment 58 indicated the issue at that time was with 2 of the 3 different panel manufacturers used for those specific HP computers.

At that time, apparently Windows had been installed with Legacy support and when they switched the BIOS/UEFI from Legacy Mode to UEFI and reinstalled Windows in UEFI mode everything worked as it should on all the panels. This was explained in Comment 63.

The reason those settings made a difference is explained in Comment 83. "The BIOS provides us with a different Video BIOS Table (VBT) depending on legacy vs. UEFI boot. There are differences in the panel type (really just an index in the tables), device type, timings."

I do not know what is available in your UEFI, but they listed the option under F10 > BIOS Setup > Advanced > Secure Boot. They used the option "Legacy Support Disabled and Secure Boot Disabled". Per Comment 77 "Important is to have Legacy Support Disabled. It is not enough just boot from UEFI and have Legacy Support enabled - it must be disabled (and then the only way to boot is UEFI)."

The first bug report I listed indicated the person checked the setting and did not find it. However, I know that option was still available on some HP computers I helped others with within the last six months (although those did have AMD Ryzen processors and not Intel). If you don't see that option, check to see if there are any options which mention CSM (Compatibility Support Module).

Since your install was fine before they replaced the panel, one might guess the new panel may have been from a different manufacturer. A combination of that and the settings in the BIOS/UEFI may be what is causing the squished screen.

[nmssis]

Update:

I tried the nomodeset option for the live session (not in compatibility mode) and the keyboard, mouse and touchscreen was all working properly! However, there was one small thing (I am not sure if this is exclusively a live session issue) is that the resolution was different compared to what this laptop can support and it does not give me an option to switch resolutions:

https://imgur.com/a/fIMNxjR

So far this feels like it is progressing really well!

[SMG]

However, there was one small thing (I am not sure if this is exclusively a live session issue) is that the resolution was different compared to what this laptop can support and it does not give me an option to switch resolutions:

That is the effect of nomodeset which turns off the capabilities of the Intel and Nvidia graphics drivers.

Let us know what settings are available in the BIOS/UEFI based on my post about the bug reports I found.

[nmssis]

Let us know what settings are available in the BIOS/UEFI based on my post about the bug reports I found.

I tried finding the settings in the BIOS Setup Utility and I found nothing regarding the CSM nor Legacy Boot at all. Although I may send screenshots since there is a chance I may be missing something.