【Solved】Display Problems on Repaired HP-Envy 15t-ep000
Forum rules
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Before you post read how to get help. Topics in this forum are automatically closed 6 months after creation.
Re: Display Problems on Repaired HP-Envy 15t-ep000
I found an Interactive BIOS Simulator for HP Envy 15-ep0000 Laptop PC. I'll see if anything looks like it might help.
A woman typing on a laptop with LM20.3 Cinnamon.
Re: Display Problems on Repaired HP-Envy 15t-ep000
That sounds good! Thank you!SMG wrote: ⤴Sun Apr 11, 2021 6:43 pm I found an Interactive BIOS Simulator for HP Envy 15-ep0000 Laptop PC. I'll see if anything looks like it might help.
Re: Display Problems on Repaired HP-Envy 15t-ep000
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
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.
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.
A woman typing on a laptop with LM20.3 Cinnamon.
Re: Display Problems on Repaired HP-Envy 15t-ep000
Will try this, however I will have to do this the next day and I will remind you promptly!SMG wrote: ⤴Sun Apr 11, 2021 9:30 pm 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 replacingquiet splash
withnomodeset
(for installing the Nvidia drivers which you already have), but instead of usingnomodeset
I would like you to tryintel_idle.max_cstate=4
.
Re: Display Problems on Repaired HP-Envy 15t-ep000
Update:
I tried to use
https://imgur.com/jyteb9N
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
Re: Display Problems on Repaired HP-Envy 15t-ep000
Did you get a chance to try
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
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. A woman typing on a laptop with LM20.3 Cinnamon.
Re: Display Problems on Repaired HP-Envy 15t-ep000
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.
That sounds really long lolHowever, their computer was taking 19.5 minutes to boot.
Re: Display Problems on Repaired HP-Envy 15t-ep000
There were two different sets of directions I gave for editing grub to add the parameter. For doing it on your install:
SMG wrote: ⤴Sun Apr 11, 2021 9:30 pmYou 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 replacingquiet splash
withnomodeset
(for installing the Nvidia drivers which you already have), but instead of usingnomodeset
I would like you to tryintel_idle.max_cstate=4
.
It is. Very. Long.
A woman typing on a laptop with LM20.3 Cinnamon.
Re: Display Problems on Repaired HP-Envy 15t-ep000
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.
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.
Re: Display Problems on Repaired HP-Envy 15t-ep000
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"
Code: Select all
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=4"
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.
A woman typing on a laptop with LM20.3 Cinnamon.
Re: Display Problems on Repaired HP-Envy 15t-ep000
As for usingSMG wrote: ⤴Tue Apr 13, 2021 8:12 pmIf you feel using theintel_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 withxed admin:///etc/default/grub
Change this line:To this:Code: Select all
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
You then save the file.Code: Select all
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_idle.max_cstate=4"
Then update grub withsudo update-grub
and all future boots of the computer will use that parameter.
intel_idle.max_cstate=4
I will likely make this permanent. I will let you know what happens!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!I'm sorry, but I have run out of things to check for new ideas. Nothing I checked today gave me any new leads.
Re: Display Problems on Repaired HP-Envy 15t-ep000
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
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?
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
P.S: If I had to change out the "problem graphic card" can this be an option?
Re: Display Problems on Repaired HP-Envy 15t-ep000
Always good to celebrate the little victories.
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.
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.
A woman typing on a laptop with LM20.3 Cinnamon.
Re: Display Problems on Repaired HP-Envy 15t-ep000
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 wrote: ⤴Fri Apr 16, 2021 8:01 pm 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.
Re: Display Problems on Repaired HP-Envy 15t-ep000
It's my understanding all laptop screens of that size/resolution have two cables. It's the fundamental design.
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.
A woman typing on a laptop with LM20.3 Cinnamon.
Re: Display Problems on Repaired HP-Envy 15t-ep000
I tried the 5.10-oem kernel and it behaves just the same as the 4.8 kernel.SMG wrote: ⤴Sat Apr 17, 2021 12:40 pm 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 withsudo 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.
Re: Display Problems on Repaired HP-Envy 15t-ep000
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.
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.SMG wrote: ⤴Wed Apr 07, 2021 7:46 pmThere 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.
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.
Instead ofSMG wrote: ⤴Sun Apr 11, 2021 10:11 amOne can add the kernel parameternomodeset
to the live session boot which disables just the graphics drivers. Here are the instructions Linux Mint Installation Guide: Nomodeset boot option.
nomodeset
I would like you to add the following:
Code: Select all
acpi_osi=! \"acpi_osi=Windows 2015\"
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.A woman typing on a laptop with LM20.3 Cinnamon.
Re: Display Problems on Repaired HP-Envy 15t-ep000
Instead ofSMG wrote: ⤴Sat Apr 17, 2021 9:42 pm 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 parameternomodeset
to the live session boot which disables just the graphics drivers. Here are the instructions Linux Mint Installation Guide: Nomodeset boot option.
nomodeset
I would like you to add the following:
Code: Select all
acpi_osi=! \"acpi_osi=Windows 2015\"
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.Re: Display Problems on Repaired HP-Envy 15t-ep000
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.
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.
A woman typing on a laptop with LM20.3 Cinnamon.
Re: Display Problems on Repaired HP-Envy 15t-ep000
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!