Bug 108225

Created attachment 141890 [details]
dmesg with fastboot

Created attachment 141891 [details]
dmesg with no fastboot

Thank you for filing a bug for this.

Unfortunately the dmesg output starts too late (it is missing the initial setup of the graphics).

Can you instead provide the output (the drm-debu.txt file) of:

journalctl -b0 | grep "drm:" > drm-debug.txt

For a boot with and without fastboot set, while keeping the drm.debug=0x1e ?

Created attachment 141892 [details]
journalctl no fastboot

Created attachment 141893 [details]
journalctl with fastboot

Attached new files.

(In reply to Basil Eric Rabi from comment #0)
> Created attachment 141889 [details]
> dmesg with no fastboot and with fastboot using drm.debug=0x1e

I'd like to see full dmesg from boot, i.e. add log_buf_len=4M or similar and attach dmesg command output. Keep the drm.debug option.

What does this print for each case after booting:

$ grep -d skip "" /sys/class/backlight/intel_backlight/*

> When booting with the option i915.fastboot=1 in command line, the screen
> brightness of Acer V3-772G laptop cannot be adjusted. When fastboot option
> is removed, the screen brightness can be adjusted without issues.

What do you mean brightness can't be adjusted? Please be more elaborate. Please try the sysfs interface directly, 'echo X > /sys/class/backlight/intel_backlight/brightness' where X is some number between 0 and max_brightness.

Does the backlight start working after a suspend/resume or a modeset?

Created attachment 141936 [details]
dmesg with no fastboot

Created attachment 141937 [details]
dmesg with fastboot

Created attachment 141938 [details]
dmesg with fastboot after suspend/resume

With fastboot enabled, the screen brightness stays at maximum and can't be adjusted by either Fn + Brightness keys (which are the left and right arrow keys) nor with 'echo X > /sys/class/backlight/intel_backlight/brightness'. 

Using 'echo X > /sys/class/backlight/intel_backlight/brightness' changes only the value of 'cat /sys/class/backlight/intel_backlight/brightness' but the actual brightness of the screen stays at maximum.

After suspending and resuming (while fastboot is enabled), the backlight works and adjusting the brightness works again. I have attached the dmesg output after suspend/resume.

The output of 'grep -d skip "" /sys/class/backlight/intel_backlight/*' by both fastboot enabled and disabled are the same:

/sys/class/backlight/intel_backlight/actual_brightness:489
/sys/class/backlight/intel_backlight/bl_power:0
/sys/class/backlight/intel_backlight/brightness:489
/sys/class/backlight/intel_backlight/max_brightness:4882
/sys/class/backlight/intel_backlight/type:raw

How can I do a modeset?

(In reply to Basil Eric Rabi from comment #11)
> How can I do a modeset?

Try 'xrandr --output eDP-1 --off --output eDP-1 --auto'

If that helps when the bug is on, it would really be helpful if you could provide the output of the following 1) after boot, 2) after running the above.

# intel_reg read 0xc8250 0xc2004 0xc8254 0x61250 0x61254

intel_reg is a tool in the intel-gpu-tools, or IGT.

I suspect the BIOS or GOP sets up different backlight settings from what i915 does, and after fastboot the backlight adjustment writes have no effect.

(Note to my future self and other developers: My hunch says GOP does not set BLM_PCH_OVERRIDE_ENABLE and uses the CPU register to adjust backlight, while i915 uses PCH override and uses the PCH register to adjust backlight. Without the override, the PCH register does not have effect. PCH override is the default after Lynxpoint, so we use that mode also for LPT.)

xrandr works.

After boot:

0xC8250 : 0x80000000
0xC2004 : 0x4
0xC8254 : 0x131201E9
0x61250 : 0x0
0x61254 : 0x0

After modeset:

0xC8250 : 0xC0000000
0xC2004 : 0x4
0xC8254 : 0x131200F4
0x61250 : 0x0
0x61254 : 0x0

(In reply to Basil Eric Rabi from comment #13)
> xrandr works.

To be clear: do you mean that when booting with fastboot=1, that after running the xrandr command the brigthness control starts working ?

(In reply to Hans de Goede from comment #14)
> To be clear: do you mean that when booting with fastboot=1, that after
> running the xrandr command the brigthness control starts working ?

Yes, when booting with fastboot=1, running the command
`xrandr --output eDP-1 --off && xrandr --output eDP-1 --auto`
makes the screen brightness adjustable again.

Thanks, comment #13 and comment #15 confirm my hunch in comment #12.

On LPT, SPT and KBP PCHs we need to either force a modeset regardless of fastboot (a bit heavy handed) or sanitize/enable the PCH override (need to double check if the override bit can be set on the fly).

*** Bug 103781 has been marked as a duplicate of this bug. ***

Hi Jani,

Thanks for trying to fix this issue.

I will test again if this bug has been solved when the kernel arrives on my Arch Linux system, which is currently at 4.18.14, which should contain the possible fix.


Do you have an estimation in which new kernel version will this fix land, for example 4.20, 4.21, ...?

Do you believe this will be backported to existing kernels and if so, do you know in which v4.18.x / v4.19.x this will land?

We don't have a fix yet, and no estimates as fastboot still isn't the default configuration.

Well, I know how to enable fastboot on a kernel; that is how I got to this bug report ;-)

Please let me know, if you have a possible fix has been found and pushed upstream, preferably with an estimation in which kernel version the fix lands.

Again, thanks for your efforts.

I have exactly the same issue on the Dell M3800 (Intel i7-4702HQ + muxless Nvidia K1100M). Using i915.fastboot=1, I don't see a single flicker from power-on all the way to GNOME desktop. However, just as reported, backlight control doesn't work and is set to maximum. I have additionally tried acpi_backlight=[vendor,native,video] without any success.

I can test patches and provide further debug infos, if needed. Please let me know.

Cheers,
Tolga

(In reply to Tolga Cakir from comment #21)
> I have exactly the same issue on the Dell M3800 (Intel i7-4702HQ + muxless
> Nvidia K1100M). Using i915.fastboot=1, I don't see a single flicker from
> power-on all the way to GNOME desktop. However, just as reported, backlight
> control doesn't work and is set to maximum. I have additionally tried
> acpi_backlight=[vendor,native,video] without any success.
> 
> I can test patches and provide further debug infos, if needed. Please let me
> know.

Do you have LynxPoint (LPT) PCH? Look for something like this in the dmesg:

[    5.224781] [drm:intel_pch_type [i915]] Found LynxPoint PCH

Does the trick from comment #12 help? What's the output of the intel_reg reads in the two scenarios? (See comment #13 for example.)

I just want to ensure you are really experiencing the same bug, and not something else.

Created attachment 142461 [details] [review]
Try using cpu mode?

Well, please try the fix that jani suggested, and then if it doesn't work, could you try this?

Created attachment 142465 [details] [review]
Switch backlight to PWM mode on init.

This should definitely work, but might cause a flicker during boot. Can you check?

Created attachment 142472 [details] [review]
(hopefully) Flicker free version of switching backlight method.

Can you test if this works? If not the previous patch should work.

(In reply to Jani Nikula from comment #22)
> Do you have LynxPoint (LPT) PCH? Look for something like this in the dmesg:
> 
> [    5.224781] [drm:intel_pch_type [i915]] Found LynxPoint PCH
> 
> Does the trick from comment #12 help? What's the output of the intel_reg
> reads in the two scenarios? (See comment #13 for example.)

My platform is Lynx Point (Intel HM87 chipset, Intel Core i7-4702HQ), eventhough I don't see that specific line. I've done the tests on an Arch Linux system, kernel 4.19.2.

After running the mentioned xrandr commands, my screen turns off for a second, comes back on and backlight control works again. My output intel_reg read output:

Fresh boot w/ fastboot (non-working backlight control):
BLC_PWM_PCH_CTL1 (0x000c8250): 0x80000000 (enable 1, override 0, inverted polarity 0)
            (0x000c2004): 0x00000004
BLC_PWM_PCH_CTL2 (0x000c8254): 0x131203b1 (freq 4882, cycle 945)
            (0x00061250): 0x00000000
            (0x00061254): 0x00000000

After running xrandr command (backlight control working):
BLC_PWM_PCH_CTL1 (0x000c8250): 0xc0000000 (enable 1, override 1, inverted polarity 0)
            (0x000c2004): 0x00000004
BLC_PWM_PCH_CTL2 (0x000c8254): 0x131203b1 (freq 4882, cycle 945)
            (0x00061250): 0x00000000
            (0x00061254): 0x00000000

@Maarten Lankhorst: Thanks for the patches in comment #23 #24 #25! I'm setting up a testing environment and will report back asap.

The one in comment 25 should work, if it fails then comment 24 should.. comment 23 won't, for sure.

(In reply to Maarten Lankhorst from comment #25)
> Created attachment 142472 [details] [review] [review]
> (hopefully) Flicker free version of switching backlight method.
> 
> Can you test if this works? If not the previous patch should work.

I have tested the patch in comment #25 on Arch Linux and patched against drm-intel-next branch.

My observations: when I power on my laptop, the default brightness is set around 50% brightness. When i915 gets loaded, the brightness level changes to my user value (saved during shutdown, restored on next boot). The brightness level changes without any form of smoothing, but there is no flickering. It changes strict from e.g. 50% to 75%, without the backlight turning off. After the boot process, backlight controls fully work!

However, the flickering is not 100% gone, eventhough it's much better than without fastboot=1. There is a very short screen content blanking, but the backlight stays on. The contents of the screen blank for around ~1/10th of a second and resume where they stopped.

Eventhough I still notice a very brief screen flickering, the result is superior to fastboot=0.

I'm testing comment #24 next and will report back.

About the short flicker, I've been tracking down a regression in 4.20 (and thus also drm-next) which causes the screen to briefly go purple with DSI panels.

Can you try:

git revert 516a49cc19467e298d08a404f73a6e311f4548d1

That fixes the purple flash for me (I need to write a proper commit message and then submit this revert upstream for 4.20).

While debugging the purple flash I found another possible suspect commit, so if that revert does not help, you can also try:

git revert 9b27390139dbe0dc10d1899545248862fe826b61

For me that commit makes the initial hw-state readout think none of the pipes have any active planes (but strangely enough I see no negative effects from this).

And for good measure if neither revert helps, try combining both.

(In reply to Maarten Lankhorst from comment #24)
> Created attachment 142465 [details] [review] [review]
> Switch backlight to PWM mode on init.
> 
> This should definitely work, but might cause a flicker during boot. Can you
> check?

I've just tested this, same setup as in comment #28. It worked the same as the patch in comment #25. I've created a video after applying patch #24. Uploaded on Google Drive.

fastboot=1 and patch #24:
https://drive.google.com/open?id=1UEvoKR_9vgJCuc5J4nMXRtiK0Tx8Uvo5

You can see the "blanking" behaviour I described in comment #28 at around 00:00:15. I recorded the video in a dark room with high ISO, so you can see the backlight behaviour more clearly. As you can see, the screen never turns off.

fastboot=0 and patch #24:
https://drive.google.com/open?id=1G4kqypsQ5fmWHpDAY1ezTPPrQTzkZMDN

The screen completely turns off and on, including backlight.

Patch #25 behaves the same as patch #24. If you have further ideas, how to fix the blanking, I'm happy to try out more patches, as I have the testing environment setup and working.

Thanks for the patches!

Cheers,
Tolga

Created attachment 142522 [details] [review]
More debug spam

Can you take a look at this patch?

(In reply to Tolga Cakir from comment #30)
> If you have further ideas, how to
> fix the blanking, I'm happy to try out more patches, as I have the testing
> environment setup and working.

If you can test the 2 reverts from comment #29 with fastboot=1 and see if they fix the short blanking that would be great.

(In reply to Hans de Goede from comment #29)
> About the short flicker, I've been tracking down a regression in 4.20 (and
> thus also drm-next) which causes the screen to briefly go purple with DSI
> panels.
> 
> Can you try:
> 
> git revert 516a49cc19467e298d08a404f73a6e311f4548d1
> 
> That fixes the purple flash for me (I need to write a proper commit message
> and then submit this revert upstream for 4.20).

(In reply to Maarten Lankhorst from comment #31)
> Created attachment 142522 [details] [review] [review]
> More debug spam
> 
> Can you take a look at this patch?

Thanks for the suggestions and the patch! I have applied git revert 516a49cc19467e298d08a404f73a6e311f4548d1, aswell as the patch from comment #31. The flickering is gone. I have flicker-free, blanking-free boot experience. Backlight never turns off during boot and backlight controls work after boot procedure. Just perfect!

The debug message from patch #31 gave me this:
[    2.426812] [drm] Backlight PCH value: 861, converted to freq 1134, converted to lpt units 930, minmax: 249/4882

To sum it up: git revert 516a49cc19467e298d08a404f73a6e311f4548d1 and applying patch #31 fixes this issue! Thank you! I haven't applied the 2nd git revert, as this already worked as I wished.

Cheers,
Tolga

Hi Hans and Maarten,

This sounds promising!
Any chance it might land in 4.20 ? rc-4? rc-5?

If so, I can run a test too.

Instead of reverting, does applying https://patchwork.freedesktop.org/series/52754/ work?

*** Bug 108672 has been marked as a duplicate of this bug. ***

(In reply to Maarten Lankhorst from comment #35)
> Instead of reverting, does applying
> https://patchwork.freedesktop.org/series/52754/ work?

I'll be able to test in about 3 hours. Do you want me to test Ville's patches on their own, or do you want me to test your patches plus Ville's?

Together! :D

I have tested patch #31 and the patches at https://patchwork.freedesktop.org/series/52754/ together. No flicker, no blanking. Backlight controls work. Same observations as in comment #33. Perfect!

Thanks for all your efforts!

Cheers,
Tolga

Hopefully addressing the backlight issue and backlight issue on s4 resume:

https://patchwork.freedesktop.org/series/53239/

Thanks for the patches! I'm just about leaving, I will test when I return in about 8 hours.

I checked out at d6a09cee2458adeed5c07882c7e0b91f089515b8 and applied both your patches from Nov 29th.

Fresh boot and S3 resume work the same as before, but S4 resume is still bugged. I get a dark screen.

After the kernel takes over, the backlight gets turned off and the display seems to be blank. I have used my smartphone's LED light and I couldn't spot any sort of display content. I had blind console access though. So I created a script for backlight setting, but echoing to /sys/class/backlight/intel_backlight/brightness in that situation didn't bring the backlight up (it works on S3 / normal boot).

So, backlight controls still don't work after S4 resume.

I want to note, that my laptop seems to do some sort of "modeset", before it puts itself into hibernate. When I initiate hibernate, the screen turns off, shortly turns on again (shows screen contents, backlight on, a bit brighter) and turns off again + whole device shuts down (S4). Maybe your new code saves / points to the wrong values because of this?

Haven't found anything in the logs. Since I have blind console access, I can prepare scripts for blindly debugging. Any instructions / ideas?

dmesg from the resumed kernel would be nice. :)

Created attachment 142667 [details]
dmesg S4 resume

As requested, both patches from 29th Nov applied. drm.debug=0x1e set. I have marked and commented my actions. Search the dmesg for all occurences of "TOLGA" and you will find the timestamps on backlight change attempts, hibernation and blind reboot.

Created attachment 142668 [details]
journal S4 resume

Additional drm debug infos after initiating "blind reboot" (line 2140), not included in "dmesg S4 resume".

Backlight turning off during S4 hibernate is expected. The kernel performs all steps of suspend. A whole snapshot of the memory is made. It then performs a resume so all devices are accessible again, and then the memory snapshot is written to disk. After this the system really shuts down.

This is probably what you're seeing when hibernating.

In the first patch to fix backlight on resume, can you change in intel_panel.c:
if (panel->backlight.enabled && conn_state->crtc) {

to:
if (panel->backlight.level && conn_state->crtc) {

?

(In reply to Maarten Lankhorst from comment #46)
> Backlight turning off during S4 hibernate is expected. The kernel performs
> all steps of suspend. A whole snapshot of the memory is made. It then
> performs a resume so all devices are accessible again, and then the memory
> snapshot is written to disk. After this the system really shuts down.
> 
> This is probably what you're seeing when hibernating.
Thanks for the explanation!

> In the first patch to fix backlight on resume, can you change in
> intel_panel.c:
> if (panel->backlight.enabled && conn_state->crtc) {
> 
> to:
> if (panel->backlight.level && conn_state->crtc) {
> 
> ?
I have applied your mentioned changes. It indeed fixes the S4 resume issue. I have tested fresh boot, S3 resume, S4 resume and couldn't observe any sort of issues. Backlight levels are restored correctly and backlight controls work fine after all these actions. No flicker occur after resuming to console from all tested states (S3, S4, S5).

A single flicker occurs when S4 resuming to GNOME, but it looks like it's a GNOME-related issue. Doesn't happen after S3 resume and I couldn't spot any further issues, other than the single flicker. Maybe Hans has some insight on this, as (afaik) he has worked on multiple projects regarding flickerfree experience.

Furthermore, I have checked, whether enable_fbc=1 is affected by fastboot in any way. According to dmesg, fbc gets enabled, regardless of fastboot. I have verified this by measuring power consumption: with enable_fbc=1, my laptop draws ~6.5W; without it draws 10W. Setting fastboot=1 doesn't affect it in any way: I still achieve 6.5W power draw by enabling_fbc=1 and fastboot=1 at the same time.

I couldn't test the effects on enable_psr=1, as it's bugged on my laptop (PSR1). It allowed my laptop to enter PC7 on 4.18 kernels, but I had flickering issues, so disabled it. 4.19.4 flickers even more badly and no PC7 anymore. Latest 4.20.x doesn't seem to flicker anymore, but no PC7. So, I don't know, if it *really* works (dmesg says it's enabled). Therefore, I can't say anything about that.

All in all, I think this can be viewed as fixed. Feel free to add my Tested-by Tag.

Thanks for all your efforts! If you need further testing, please let me know. Also feel free to CC me, if you ever need me to test anything in the future for HSW laptops.

Cheers,
Tolga

If I understood your code correctly, I think the following scenario is possible: on inactivity, laptop dims screen (backlight level 0) after e.g. 5 minutes and automatically hibernates after 15 minutes. After resuming from S4, the backlight wouldn't come up.

I will test this tomorrow and let you know.

I have now tested the conditions mentioned in comment #48. With your patches applied and setting backlight to 0 before S4, backlight gets restored to max_brightness (4882 in my case) upon S4 resume.

When setting backlight to 0 before either S3 or S5, backlight gets set to 244 (out of 4882 max, so I guess 5%) after S3 / S5 resume. In all cases (S3, S4, S5), I had working backlight controls and flicker free boot. Nice!

Yeah, as far as I can tell, the code doesn't preserve backlight enabled state, and always enables backlight to last level on a modeset. All I did was doing the same for S4 resume.

Maybe worth fixing at some point, but at least it's consistent. :)

Should be fixed in drm-tip now, even for s4 resume. :)

Thank you Maarten for all your efforts! I have pulled and built drm-intel-next at c09d39166d8a3f3788680b32dbb0a40a70de32e2. Everything works as expected!

Thanks for the feedback.Closing this bug.

Hi Hans and Maarten,

Kernel 5.1.2 has arrived at Arch Linux and I confirm that fastboot is working including the brightness controls.

This is on a Hashwell system, for which fastboot is not enabled by default.
But maybe it could by now?

Thanks anyway for the efforts.