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

[SMG]

I found an Interactive BIOS Simulator for HP Envy 15-ep0000 Laptop PC. I'll see if anything looks like it might help.

[nmssis]

I found an Interactive BIOS Simulator for HP Envy 15-ep0000 Laptop PC. I'll see if anything looks like it might help.

That sounds good! Thank you!

[SMG]

I checked the BIOS/UEFI information and did not find anything helpful. There are very few options for anything.

On the Main page under the Device Firmware Revision is GOP (Graphic Output Protocol). According to FAQ BIOS and Firmware question #2, "The GOP driver (also known as EFI video driver in some Intel EMGD documentation) is a replacement for legacy video BIOS and enables the use of UEFI pre-boot firmware without compatibility support module (CSM)." Which means you are correct in not finding CSM or Legacy Boot.

I read through the first bug post I mentioned (with basically the same laptop as yours) and even read that person's logs, but did not find any ideas in it. He was finding some success with the patch provided, but the patch required building one's own kernel (which he we was doing with Arch). It was also a workaround and didn't really fix the issue. It seem to me the only true fix is a BIOS/UEFI update from HP. While I doubt that will happen, we can always hope it might.

The only idea which has been sticking in my mind is a kernel parameter which is suggested as a fix for the FIFO underrun and helps clear the flickering after resuming from sleep others have had. Your one 5.4 dmesg output did have that error message, so I expect it to be more likely to be helpful with the 5.4 kernel, but you are welcome to try it with the live session 5.8 as well.

You can try it as a one-time boot parameter on your installed version of Mint by following the directions described in the Release Notes for Linux Mint 20.1 Cinnamon in the section on 'Solving freezes during the boot sequence'. That describes booting into grub and replacing quiet splash with nomodeset (for installing the Nvidia drivers which you already have), but instead of using nomodeset I would like you to try intel_idle.max_cstate=4.

If that helps reduce the glitching, I can give you instructions on how to make it permanent so you do not have to add it for each boot. Actually, if it helps, I would definitely recommend trying it on the live session too.

Changing that parameter can reduces battery life, but you can decide if that is a worthwhile trade-off should it help the situation.

[nmssis]

You can try it as a one-time boot parameter on your installed version of Mint by following the directions described in the Release Notes for Linux Mint 20.1 Cinnamon in the section on 'Solving freezes during the boot sequence'. That describes booting into grub and replacing quiet splash with nomodeset (for installing the Nvidia drivers which you already have), but instead of using nomodeset I would like you to try intel_idle.max_cstate=4.

Will try this, however I will have to do this the next day and I will remind you promptly!

[nmssis]

Update:
I tried to use intel_idle.max_cstate=4 for both with and without compatibility mode and it showed a split screen again. Here is an image for what had happened for both states:

https://imgur.com/jyteb9N

[SMG]

Did you get a chance to try intel_idle.max_cstate=4 with the 5.4 kernel? Or did that force the image to a permanent squished screen instead of cycling with full and squished?

That bug thread Split screen/display corruption issue on HP Envy 15-ep0004ns didn't give me warm fuzzies about being able to find a solution, but it is my hope that we can at least stabilize the image on the 5.4 kernel as best as possible.

Someone on another thread with an HP Pavilion Laptop 15-cc1xx had the same i915 0000:00:02.0: Failed to program MOCS registers; expect performance issues message in their log, but did not mention graphics issues. However, their computer was taking 19.5 minutes to boot.

[nmssis]

Did you get a chance to try intel_idle.max_cstate=4 with the 5.4 kernel? Or did that force the image to a permanent squished screen instead of cycling with full and squished?

Sorry! I just realized my mistake! I didn't realize that I was supposed to use the LM20.1 that was installed on my computer and not the edge live environment ISO.

However, their computer was taking 19.5 minutes to boot.

That sounds really long lol

[SMG]

Sorry! I just realized my mistake! I didn't realize that I was supposed to use the LM20.1 that was installed on my computer and not the edge live environment ISO.

There were two different sets of directions I gave for editing grub to add the parameter. For doing it on your install:

You can try it as a one-time boot parameter on your installed version of Mint by following the directions described in the Release Notes for Linux Mint 20.1 Cinnamon in the section on 'Solving freezes during the boot sequence'. That describes booting into grub and replacing quiet splash with nomodeset (for installing the Nvidia drivers which you already have), but instead of using nomodeset I would like you to try intel_idle.max_cstate=4.

That sounds really long lol

It is. Very. Long.

[nmssis]

Update:

I edited it for both 5.4 and 5.8 kernels.

As for the 5.4 kernel the glitches on the login screen did not occur as much, however the glitches were still present (switching between squished and not.)

As for the 5.8 kernel it still had the permanent squished screen.

[SMG]

As for the 5.4 kernel the glitches on the login screen did not occur as much, however the glitches were still present (switching between squished and not.)

If you feel using the intel_idle.max_cstate=4 is an improvement you would like to make permanent, here is how you can do that.

As with any code change, I recommend making a Timeshift snapshot first.

Open grub for editing with xed admin:///etc/default/grub
Change this line:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

To this:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=4"

You then save the file.
Then update grub with sudo update-grub and all future boots of the computer will use that parameter.

I'm sorry, but I have run out of things to check for new ideas. Nothing I checked today gave me any new leads.

[nmssis]

As for the 5.4 kernel the glitches on the login screen did not occur as much, however the glitches were still present (switching between squished and not.)

If you feel using the intel_idle.max_cstate=4 is an improvement you would like to make permanent, here is how you can do that.

As with any code change, I recommend making a Timeshift snapshot first.

Open grub for editing with xed admin:///etc/default/grub
Change this line:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

To this:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=4"

You then save the file.
Then update grub with sudo update-grub and all future boots of the computer will use that parameter.

As for using intel_idle.max_cstate=4 I will likely make this permanent. I will let you know what happens!

I'm sorry, but I have run out of things to check for new ideas. Nothing I checked today gave me any new leads.

It's ok! I know you trying to solve this problem took alot of research . I'm also really impressed with how many ideas you have offered! Thank you for helping me so far!

[nmssis]

Btw, sorry for delaying my response I have been really busy for the past few days.

I followed the steps and it worked really well! The glitches are present but I don't have to quickly type my password on login anymore!

However, I am not sure whether this may be a raise for concern or not but when I typed in xed admin:///etc/default/grub it showed these errors in the terminal although I still edited the file with no interference:

Code: Select all

** (xed:3299): WARNING **: 19:00:41.180: The specified location is not mounted

(xed:3299): Gtk-CRITICAL **: 19:02:38.039: gtk_notebook_get_tab_label: assertion 'list != NULL' failed

(xed:3299): Gtk-CRITICAL **: 19:02:38.055: gtk_notebook_get_tab_label: assertion 'list != NULL' failed

But again, I'm glad this is improved so far! Thank you!

P.S: If I had to change out the "problem graphic card" can this be an option?

[SMG]

I followed the steps and it worked really well! The glitches are present but I don't have to quickly type my password on login anymore!

Always good to celebrate the little victories.

However, I am not sure whether this may be a raise for concern or not but when I typed in xed admin:///etc/default/grub it showed these errors in the terminal although I still edited the file with no interference:

I just checked and the same thing happened for me. I don't recall seeing that in the past, but it's been a while since I've tested it and there might have been some updates which might relate to this happening. The first is a warning and not an error. The other two may be bugs? Not sure.

P.S: If I had to change out the "problem graphic card" can this be an option?

Did you mean the screen? If so, both the one you have now and the prior one were problematic, so I do not know what a good one might be.

You only have one graphic card which is Nvidia and I do not think that is causing problems. The Intel graphics are built into the cpu, so that can not be individually changed. Both Nvidia and Intel were working in Windows 10, so that is a sign it is probably not a hardware issue.

The issue from what I could gather from the bug report seems to be information in a sort of video translation table being passed from the UEFI/BIOS to the operating system. The person helping with the patch indicated it didn't seem like the table info is of a sort which that person normally sees. I do not know enough about how that works to hazard a guess as to how that impacts the situation.

From what I could tell from that thread and some other information I read about screens, yours, because it is a higher resolution screen, has two cables which transmit the information to the screen. The entire screen is working the entire time, even when squished, because it is all lit. It's not like part of the screen has an image and the rest is black. However, it seems for some reason because of that translation table, the image on the screen is only being fed into one cable? So the entire screen is lit, but the image projected on the screen isn't using both channels/cables. The patch the person made was a way to force both to be used, but it caused side effects which were problematic. That is how I understood the situation, but I may be wrong.

[nmssis]

From what I could tell from that thread and some other information I read about screens, yours, because it is a higher resolution screen, has two cables which transmit the information to the screen. The entire screen is working the entire time, even when squished, because it is all lit. It's not like part of the screen has an image and the rest is black. However, it seems for some reason because of that translation table, the image on the screen is only being fed into one cable? So the entire screen is lit, but the image projected on the screen isn't using both channels/cables. The patch the person made was a way to force both to be used, but it caused side effects which were problematic. That is how I understood the situation, but I may be wrong.

Noted, thank you! But for my purposes, do you believe that the screen should have been one or two cables? Also, are there some known issues with Linux when it came to using two cables for the screen?

[SMG]

But for my purposes, do you believe that the screen should have been one or two cables?

It's my understanding all laptop screens of that size/resolution have two cables. It's the fundamental design.

Also, are there some known issues with Linux when it came to using two cables for the screen?

No. This is not an issue of Linux and the cables.

The issue is HP designed this laptop to run on Windows. The hardware and firmware (UEFI) were set up and tested to make sure it ran on Windows 10. It was never designed, tested, or checked to see how it might run on any other operating system including any Mac OS or Linux-based distros.
_____________________

There have been some recent updates to the 5.10-oem kernel which affect the i915 driver. The fixes were not specifically for the issue you are seeing, but maybe the changes will help. You can install the latest 5.10-oem with sudo apt install linux-oem-20.04b. It will become active when you reboot. This will be a newer version than the one you tried earlier in this thread.

The oem kernel is one which manufacturers use to certify their hardware works on Ubuntu. The Ubuntu team has been working with Intel to get fixes for the i915 driver as issues crop up so manufacturers can certify their hardware works on Ubuntu 20.04. It seems the HP "Z" lines of desktops and laptops are the recent ones with certification.

[nmssis]

There have been some recent updates to the 5.10-oem kernel which affect the i915 driver. The fixes were not specifically for the issue you are seeing, but maybe the changes will help. You can install the latest 5.10-oem with sudo apt install linux-oem-20.04b. It will become active when you reboot. This will be a newer version than the one you tried earlier in this thread.

I tried the 5.10-oem kernel and it behaves just the same as the 4.8 kernel.

[SMG]

I tried the 5.10-oem kernel and it behaves just the same as the 5.8 kernel.

That kernel has some fixes for i915 that even the mainline kernel does not have, so I was hopeful. Oh, well.

I do not have high hopes for my next suggestion, but if you have the time and inclination to try it then we'll know for sure it did or did not help. I mentioned the below earlier in the thread.

There are BIOS/UEFIs for some computers which only activate certain hardware functionality if they think Windows is running. There are some kernel parameters we can pass to in an attempt to get the UEFI to think Windows is running instead of Linux. Since this computer was originally a Windows-only computer and others are consistently seeing the same issue across multiple Linux distros, it's as if Linux is not getting or using the correct message about the display.

When checking the logs, I did not notice anything which suggested what this type of parameter addresses was there, but maybe it is at a lower level and just not evident in the logs.

I would like you to try this on the live session with the 5.8 kernel. Here were the instructions from earlier in the thread about how to add a kernel parameter to the live session.

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.

Instead of nomodeset I would like you to add the following:

Code: Select all

acpi_osi=! \"acpi_osi=Windows 2015\"

There are two parameters there with a space between them. The forward slashes are necessary before each quote mark. I do not know, but I want to give you a heads up this may negatively affect functionality of the computer (such as keyboard, touchpad, WiFi, display backlight, graphics ).

ACPI = Advanced Configuration and Power Interface

The year numbers commonly tested in that space are 2009, 2012, 2015, and 2020 which are considered mimics of Win7, Win8, and two different versions of Win10. We do not know which code standard HP may have used to write the UEFI for your computer, so we just try and see if one works. Since your computer was issued in a Win10 version, I figure we start with one of those.

[nmssis]

I would like you to try this on the live session with the 5.8 kernel. Here were the instructions from earlier in the thread about how to add a kernel parameter to the live session.

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.

Instead of nomodeset I would like you to add the following:

Code: Select all

acpi_osi=! \"acpi_osi=Windows 2015\"

[/quote]

For the acpi_osi=! \"acpi_osi=Windows 2015\" I tried all of the versions from 2009, 2012, 2015 and 2020. There is a strange difference between them.

When I used the 2009 and 2012, it acts just like the 5.8 kernel. While the 2015 and 2020 still has the split screen and the bleeding bottom. But when it changes colors depending on what is on the upper part of the display, the color change is far more responsive and solid. Note: 2009, 2012, and the 5.8 kernel has the bottom gradually change in a mist like effect.

[SMG]

It sounds like none of those made the situation any better. The default the Linux kernel uses seems to be best.

I would suggest keeping up with any BIOS/UEFI updates HP might put out for your computer. I would also suggest posting on that HP Community thread I referenced earlier asking the OP if they found anything which worked and give a little background of what you experienced (changed displayed and what you saw before and after). Maybe something was discovered by the OP which worked or maybe HP will see more people are using Linux and do something to fix the issue. (We can always dream big. )

I realize HP support mentioned removing Windows, but there is the slim possibility the software settings for graphics in Windows may "flip a switch" in the hardware that gets left that way when one later boots into a Linux distro. I've seen that happen with Fn function toggle keys (but do not recall that being an HP computer). I would think it would be easier to get the UEFI updates with Windows installed too. Because of how Windows "takes over", if you decide to do that the recommendation is to have Windows installed first and then add Linux distros.

I have no guesses whatsoever about what changed between kernels 5.4 and 5.6 that is causing the squished screen in the upper half. Because I have no guesses, I have no more recommendations.

[nmssis]

I truly learned a lot from the posts that you made as suggestions! Unlike my craptop, I'm in a better position since I learned much from our exchanges. One day we may find another resolution, if we do, I will post here to let everyone know. But until then, I thank you again and I'll keep searching!