Bug 1143755

Created attachment 812394 [details]
hwinfo --gfx

Created attachment 812395 [details]
hwinfo --monitor

Created attachment 812396 [details]
Xorg log

Created attachment 812397 [details]
dmesg

Additional information:
When I change the display brightness I see that the black is getting darker, so the screen is not actually turned off, something like a power saving mode? Also the problem remains even if I detach the secondary monitor and reboot. So without a secondary monitor the system is not usable.

Thanks. You may try with

  i915.enable_dc=0 

on the boot kernel command line ...

Like this?

λ peter [~] → cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.2.3-1-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap quiet i915.enable_dc=0

Still not working.

Yes, thanks for giving it a try!

Does the backlight control itself work like before?

The backlight going darker at the boot time might be the systemd trying to restore the saved value.  See systemd-backlight man page.  It's saved in /var/lib/systemd/backlight/*.

And the backlight going darker during X session is done by the desktop itself.

I haven't noticed a problem on a similar machine (Latitude 7270) but with XFCE, so this might be depending on the desktop.

"Does the backlight control itself work like before?" - Sorry I don't know what that means. 

However I've added systemd.restore_state=0 kernel parameter and now it works.

But do I need to leave it like this?

Well, systemd-backlight only tries to restore the backlight brightness to the previously saved value.  And it means that the previously saved value in /lib/var/systemd/backlight/* is wrong (or unexpected to you).

So try to remove /var/lib/systemd/backlight/* value once, and test rebooting normally.  Does it make things working?

About the backlight test: I thought you tested changing the backlight brightness by some way.  The question was just whether this worked normally like before with the new kernel.

For testing the raw backlight value, you can try to write via sysfs like:
  echo 200 > /sys/class/backlight/xxx/brightness

(In reply to Peter Luladjiev from comment #10)
> "Does the backlight control itself work like before?" - Sorry I don't know
> what that means. 
> 
> However I've added systemd.restore_state=0 kernel parameter and now it works.
> 
> But do I need to leave it like this?

Okay never mind, went black again 20 minutes after a boot.

Just, as an addition here. Your Laptop brightness may work as well once the desktop has been started ...

(In reply to Peter Luladjiev from comment #12)
> (In reply to Peter Luladjiev from comment #10)
> > "Does the backlight control itself work like before?" - Sorry I don't know
> > what that means. 
> > 
> > However I've added systemd.restore_state=0 kernel parameter and now it works.
> > 
> > But do I need to leave it like this?
> 
> Okay never mind, went black again 20 minutes after a boot.

It implies that the desktop environment lowers the brightness for power-saving.
I don't know what change in kernel makes the difference, though.

Check the values in /sys/class/backlight/* (both brightness and max_brightness) at the dark state on the 5.2.x kernel.  Then boot with 5.1.x, and check the values there again.  If the max_brightness differs, it might a cause of inconsistency, for example.

(In reply to Takashi Iwai from comment #14)
> (In reply to Peter Luladjiev from comment #12)
> > (In reply to Peter Luladjiev from comment #10)
> > > "Does the backlight control itself work like before?" - Sorry I don't know
> > > what that means. 
> > > 
> > > However I've added systemd.restore_state=0 kernel parameter and now it works.
> > > 
> > > But do I need to leave it like this?
> > 
> > Okay never mind, went black again 20 minutes after a boot.
> 
> It implies that the desktop environment lowers the brightness for
> power-saving.
> I don't know what change in kernel makes the difference, though.
> 
> Check the values in /sys/class/backlight/* (both brightness and
> max_brightness) at the dark state on the 5.2.x kernel.  Then boot with
> 5.1.x, and check the values there again.  If the max_brightness differs, it
> might a cause of inconsistency, for example.

Both versions have the same brightness: 937

  λ peter [~] → cat /sys/class/backlight/intel_backlight/max_brightness
  937
  λ peter [~] → cat /sys/class/backlight/intel_backlight/brightness
  937

> So try to remove /var/lib/systemd/backlight/* value once, and test rebooting normally.  Does it make things working?

No luck with removing the files in /var/lib/systemd/backlight

> For testing the raw backlight value, you can try to write via sysfs like:
>   echo 200 > /sys/class/backlight/xxx/brightness

The only thing that happens is that the is getting darker.

> About the backlight test: I thought you tested changing the backlight brightness by some way.

Yes I changed the brightness level through Energy Saving menu and through laptop's function keys. The effect is the same like changing /sys/class/backlight/xxx/brightness value

Update: 

I did

  xset s off
  xset s 0 0
  xset -dpms

And for now it's not going black. Will see if it stays that way.

(In reply to Peter Luladjiev from comment #16)
> Update: 
> 
> I did
> 
>   xset s off
>   xset s 0 0
>   xset -dpms
> 
> And for now it's not going black. Will see if it stays that way.

I think this fixed the issue. 1 hour uptime and the screen remains turned on.
AFAIK these settings will be reset when I reboot, do I need to add them somewhere like .xinitrc or something?

Hi Peter,

Do you get the same problem when booting Tumbleweed KDE Live from a USB-stick? If not, we probably don't have a kernel regression.

Do you get any additional errors in dmesg when this problem occurs? (eg. link training issues).

And how is the exact problem?  With my freshly installed system (the very same machine), KDE turns off the screen shortly after dimming when no activity is seen, no matter which kernel.  I've tested both 5.1.x and 5.2.x.

And, if you reboot at this state, systemd will remember this exact dark state and tries to restore it at the next boot time via systemd-backlight service.  So going to this dark mode right after the boot is no bug per se, if it's the state at the previous shutdown.

The dimming and screen-off can be suppressed by adjusting the Energy Saving setup on KDE.

(In reply to Patrik Jakobsson from comment #18)
> Hi Peter,
> 
> Do you get the same problem when booting Tumbleweed KDE Live from a
> USB-stick? If not, we probably don't have a kernel regression.
> 
> Do you get any additional errors in dmesg when this problem occurs? (eg.
> link training issues).

I'm writing from Tumbleweed KDE Live snapshot 20190730 and yes, the issue remains, laptop screen is blank. Only error in dmesg is

  [    6.997001] Couldn't get size: 0x800000000000000e
  [    6.997017] Couldn't get UEFI MokListRT

I suppose that's because I choose UEFI boot instead of Legacy when booting from USB

(In reply to Takashi Iwai from comment #19)
> And how is the exact problem?  With my freshly installed system (the very
> same machine), KDE turns off the screen shortly after dimming when no
> activity is seen, no matter which kernel.  I've tested both 5.1.x and 5.2.x.
> 
> And, if you reboot at this state, systemd will remember this exact dark
> state and tries to restore it at the next boot time via systemd-backlight
> service.  So going to this dark mode right after the boot is no bug per se,
> if it's the state at the previous shutdown.
> 
> The dimming and screen-off can be suppressed by adjusting the Energy Saving
> setup on KDE.

As I said in the previous comment that happens on LIVE USB as well, even if there is activity. However the screen went off on Tumbleweed splash screen, I didn't even have time to see the login screen nor do any activity.

If you are correct and it uses the previous state wouldn't a kernel parameter systemd.restore_state=0 fix the problem, because I did tried it previously. Or I'm mistaken at what that parameter does.

I tried to disable dimming and screen off through Energy Saving but nothing changed.

And is it same without external monitor and docking station?
I've tested only with the laptop screen.

(In reply to Takashi Iwai from comment #22)
> And is it same without external monitor and docking station?
> I've tested only with the laptop screen.

Yes no matter if I have attached monitor. I don't have docking station.

What else I noticed is that after the reboot the xset commands does not help keeping the screen on.

Update:
I think xset s 0 0 helped me to keep the screen on.

Hrm, then I cannot reproduce the problem at all here.  The screen keeps on if I disable "Dim screen" and "Screen Energy Saving" on the power setup window.
(Oh there is also "Lock Screen" setup, too.)

It must be something weird in the user space side.  Reassigned to KDE people.

(In reply to Takashi Iwai from comment #25)
> Hrm, then I cannot reproduce the problem at all here.  The screen keeps on
> if I disable "Dim screen" and "Screen Energy Saving" on the power setup
> window.
> (Oh there is also "Lock Screen" setup, too.)
> 
> It must be something weird in the user space side.  Reassigned to KDE people.

Thanks anyway.

Update: xset s 0 0 didn't helped. Screen went off after 10 minutes while I was working on it.

Just a couple of thoughts. Takashi, since you tested on the same model (7470) without any problems and Peter tested with KDE Live but still experienced the issue; wouldn't this suggest a hardware/firmware issue? Also, the fact that backlight is still on (and can be adjusted) when this problem occurs makes me think that it's not as simple as the screen going into power saving mode.

We've got another bug report regarding i915 driver on 5.2, and a regression wrt PSR was confirmed (bug 1143139).

Could you check whether passing i915.enable_psr=0 boot option fixes your problem?

(In reply to Takashi Iwai from comment #28)
> We've got another bug report regarding i915 driver on 5.2, and a regression
> wrt PSR was confirmed (bug 1143139).
> 
> Could you check whether passing i915.enable_psr=0 boot option fixes your
> problem?

λ peter [~] → cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.2.3-1-default root=/dev/mapper/system-root splash=silent resume=/dev/system/swap quiet i915.enable_psr=0

No issues so far.

OK, then this is a regression by PSR2 enablement in i915 driver.
Should be addressed in the later 5.2.x stable update.

*** This bug has been marked as a duplicate of bug 1143139 ***