No Backlight / Black Screen Randomly After Restart

Apologies for the delayed response. I have been working the last couple of days and unable to continue testing this device.

Confirmed that I did have most of those power management settings already configured that way. Based on that suggestion, I did change the Lock Screen Automatically from 5 mins to Never.

I think the computer is x86_64, but I don’t know what znver1 is… The CPU is a core i5 - 1145G7.

I did read the help post request to avoid idioms or local saying, but I can’t think of another way to describe the experimental XE driver test other than a catch 22 or caught between a rock and a hard place since the test would just be for a single login attempt and not persistent across reboots. Rebooting seems to be part of the cause of the problem, it’s not just sleep. If I am able to get to the grub2 menu to add that temporary parameter, then the issue is already not present for that particular boot cycle. If the issue is present on that boot cycle, then I would not be able to even see the grub2 menu in order to enter that parameter. Do you get where I’m coming from? But I do think I understand the reason for the temporary setting, because if it doesn’t work or makes things worse, then it only requires a restart and that would revert all changes.

As an update, the server setting change seems to have improved things, though it is not gone and it does not behave normally compared to other computers like a macbook with OS X or a telemetry, bloatware ridden Windows computer that just boots up when one tells it to. But it is better than before. It doesn’t take as long or as many attempts to get it to boot normally now. OR, I’m just having a string of good luck dice rolls since the issue is intermittent…

Also, I presumed that Wayland was part of the problem, but if this server kernel loading attempt turns out to be the solution or as good as it’s going to get, would that only continue to work if I stay on x11? Or would that server kernel change continue to work if I switched back to using Wayland (for the touchpad gestures)? If the desktop kernel turns out to be the problem, does that mean Wayland was not the problem? Or were they both problems and the combined problems were what made it unusable?

Also yes, when I say shut off, I meant power down. I did not mean just lock or sleep or hibernate.

This is how to add kernel parameters globally or permanently. To make the attempt to use the XE driver permanent (nano is a simple command line text editor):

sudo nano /etc/default/grub

Find the line that begins with GRUB_CMDLINE_LINUX_DEFAULT go to the end of that line and type space followed by ‘i915.force_probe=!9a49 xe.force_probe=9a49’ so that line looks exactly like this:

GRUB_CMDLINE_LINUX_DEFAULT='quiet splash logo.nologo audit=0 rd.timeout=120 dm_mod.use_blk_mq=1 rd.systemd.show_status=0 systemd.show_status=0 i915.force_probe=!9a49 xe.force_probe=9a49'

Note where the ’ marks are that is important. Edit: Then while nano is still open type Ctrl>o to write the changes and Ctrl>x to close nano. You can run sudo nano /etc/default/grub again to be sure the changes were written to that file. Then run:

sudo update-grub2

and reboot. To revert again use nano and simply remove what you added. If something goes wrong you can do this by booting in to Console Mode. To check that the XE driver is actually being used after booting type in terminal (Konsole) inxi -G. This is easier to do than it is to explain it, but do note that what you type must be exact.

This type of change is easy enough to do and also easy to revert if something goes wrong.

Edit-2: The instructions for nano are at the bottom of the window as you can see.

I tried the temporary XE driver setting and it didn’t seem to cause an issue loading into the desktop environment. It seemed a little faster, but I can’t tell if that’s actually the case. I will try the permanent setting next.

Graphics:
Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: xe v: kernel
Device-2: Syntek Integrated Camera driver: uvcvideo type: USB
Display: x11 server: X.org v: 1.21.1.16 with: Xwayland v: 24.1.6 driver:
X: loaded: modesetting unloaded: fbdev,vesa dri: iris gpu: xe
resolution: 1920x1200~60Hz
API: EGL v: 1.5 drivers: iris,swrast platforms: gbm,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 25.0.6
renderer: Mesa Intel Iris Xe Graphics (TGL GT2)
API: Vulkan v: 1.4.312 drivers: N/A surfaces: xcb,xlib
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console
wl: wayland-info x11: xdpyinfo, xprop, xrandr

Ok, I tried deleting the ’ after the show_status=0 and then leaving the ’ at the end after 9a49 and that seemed to work.
I rebooted and launched the default option, which is the server kernel still. I saw a brief flash or artifacting that I’ve never seen before, less than a second. But it loaded in as hoped. It looks like the experimental driver setting did stick after the reboot. When there is an OpenMandriva update, will running the software center update change the kernel back to the desktop kernel? Would I have to enter a command in terminal to change the kernel back to the server version? If this fix works, can the OpenMandriva team incorporate it into the default Rock version that gets installed from the software update center?

Graphics:
Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: xe v: kernel
Device-2: Syntek Integrated Camera driver: uvcvideo type: USB
Display: x11 server: X.org v: 1.21.1.16 with: Xwayland v: 24.1.6 driver:
X: loaded: modesetting unloaded: fbdev,vesa dri: iris gpu: xe
resolution: 1920x1200~60Hz
API: EGL v: 1.5 drivers: iris,swrast platforms: gbm,x11,surfaceless,device
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 25.0.6
renderer: Mesa Intel Iris Xe Graphics (TGL GT2)
API: Vulkan v: 1.4.312 drivers: N/A surfaces: xcb,xlib
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console
wl: wayland-info x11: xdpyinfo, xprop, xrandr

I am so happy something worked.

The permanent fix (actually a workaround) should apply to all kernels you have installed so you should just be able to boot in to a an existing kernel-desktop from ‘Advanced options’ in the Grub2 menu and see if it works. I would think that it would work and if it does you can just remove kernel-server. New kernels installed are built with the settings in /etc/defaulty/grub so they get this as well.

Use one of these methods to upgrade your system:

However it is time for me to say that what I have walked your through is new to me and I do not know everything so if there are problems let’s work through it we all learn. I am reasonably certain that changing the kernel parameters the way you did is permanent unless you, as root or super user, change it. And that this change will apply to any kernels installed at the time you ran sudo update-grub2 or any new kernels that will be installed.

That is decision making above my pay grade. My guess is that would be up to @bero or maybe to upstream at kernel.org. Speculation only: I suspect that as long as Intel keeps telling kernel.org that i915 is the correct driver that will be the rule until the day comes when Intel no longer says xe driver is experimental.

This is a bit complicated so maybe a little explanation would be useful.

When you run sudo update-grub2 it rewrites the file /boot/grub2/grub.cfg. The Grub2 menu when you boot is literally a reading of that file. update-grub2 (which actually runs a script) gets the instructions on how to write each entry in the list from /etc/default/grub and the instructions for the graphical look and feel, or the theme, of the actual Grub2 menu from /boot/grub2/themes/OpenMandriva/theme.txt. So user that has made this change or any kernel parameter change should be able to open /boot/grub2/grub.cfg and see the change in the GRUB_CMDLINE_LINUX_DEFAULT= line for each kernel entry. You may notice that the file says:

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

sudo update-grub2 and sudo grub2-mkconfig do the same thing. As I understand it sudo update-grub2 invokes a script the uses grub2-mkconfig with the correct options for OMLx systems.

In this instance I can not test whether the xe driver works because I do not have that hardware. I can and have tested whether how I change kernel parameters actually works, and it does. It does matter to see this type of thing work for another user. So thanks to @allison1derland.

After a few boot cycles and after having left the computer powered off for a while when that previously usually resulted in requiring many attempts at unplugging and unplugging the external monitor/power in order to get it to boot properly, it appears to be improved now. I will refrain from saying it is entirely fixed, but it is better than before trying all of these options. Thank you @ben79 kindly for all of your walk-through directions and explanations.

To summarize for posterity:

  1. Most important - change kernel from desktop kernel to server kernel
  2. Activate experimental intel XE graphics driver
  3. Possibly optional - change from wayland to x11

In case this information helps others who experience the possibly related, but different issue of the black screen with underscore _ symbol in the top left, the experimental driver option does not fix that issue. I just got it with the experimental driver setting loaded. It looks like the combination of the server kernel plus the experimental XE driver is the best setup to try. I also had x11 active, so wayland doesn’t seem to be the only cause of that underscore issue.

I will test this out for a while to see how stable/reliable it is. If it seems to be a long-term fix, I may test out wayland so I can use trackpad gestures.

1 Like

X11 to Wayland

sudo dnf in task-plasma6-wayland --refresh

Reboot and select the proper session at the bottom left of login screen.

It would be great if we can get confirmation that kernel-server + XE driver works and kernel-desktop + XE driver does not. Then to see if X11 is necessary or if this workaround works with Wayland as well.

One never knows we may provoke some changes in OMLx kernels with our findings here.

1 Like