Bug 108225 - [LPT SPT KBP] Acer V3-772G screen brightness cannot be adjusted with i915.fastboot enabled
Summary: [LPT SPT KBP] Acer V3-772G screen brightness cannot be adjusted with i915.fas...
Status: ASSIGNED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Maarten Lankhorst
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
: 103781 108672 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-04 09:55 UTC by Basil Eric Rabi
Modified: 2018-12-07 23:09 UTC (History)
7 users (show)

See Also:
i915 platform: HSW
i915 features: display/backlight


Attachments
dmesg with no fastboot and with fastboot using drm.debug=0x1e (503.36 KB, text/x-matlab)
2018-10-04 09:55 UTC, Basil Eric Rabi
no flags Details
dmesg with fastboot (252.39 KB, text/plain)
2018-10-04 10:01 UTC, Basil Eric Rabi
no flags Details
dmesg with no fastboot (250.94 KB, text/plain)
2018-10-04 10:02 UTC, Basil Eric Rabi
no flags Details
journalctl no fastboot (407.77 KB, text/plain)
2018-10-04 10:42 UTC, Basil Eric Rabi
no flags Details
journalctl with fastboot (371.80 KB, text/plain)
2018-10-04 10:43 UTC, Basil Eric Rabi
no flags Details
dmesg with no fastboot (469.55 KB, text/plain)
2018-10-08 13:02 UTC, Basil Eric Rabi
no flags Details
dmesg with fastboot (655.10 KB, text/plain)
2018-10-08 13:03 UTC, Basil Eric Rabi
no flags Details
dmesg with fastboot after suspend/resume (1.53 MB, text/plain)
2018-10-08 13:04 UTC, Basil Eric Rabi
no flags Details
Try using cpu mode? (3.16 KB, patch)
2018-11-14 11:25 UTC, Maarten Lankhorst
no flags Details | Splinter Review
Switch backlight to PWM mode on init. (1.88 KB, patch)
2018-11-14 13:39 UTC, Maarten Lankhorst
no flags Details | Splinter Review
(hopefully) Flicker free version of switching backlight method. (2.02 KB, patch)
2018-11-15 10:44 UTC, Maarten Lankhorst
no flags Details | Splinter Review
More debug spam (2.22 KB, patch)
2018-11-19 17:28 UTC, Maarten Lankhorst
no flags Details | Splinter Review
dmesg S4 resume (167.14 KB, text/x-log)
2018-11-30 15:10 UTC, Tolga Cakir
no flags Details
journal S4 resume (226.15 KB, text/x-log)
2018-11-30 15:13 UTC, Tolga Cakir
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Basil Eric Rabi 2018-10-04 09:55:42 UTC
Created attachment 141889 [details]
dmesg with no fastboot and with fastboot using drm.debug=0x1e

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.

Distro: Fedora 29

`uname -r`
4.18.11-301.fc29.x86_64

# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.

Handle 0x0002, DMI type 2, 16 bytes
Base Board Information
	Manufacturer: Acer
	Product Name: VA70_HW
	Version: Type2 - Board Version
	Serial Number: NBM8S11001411026447200
	Asset Tag: Type2 - Board Asset Tag
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Type2 - Board Chassis Location
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

`ls /sys/class/backlight` output for both fastboot enabled and disabled:
intel_backlight
Comment 1 Basil Eric Rabi 2018-10-04 10:01:17 UTC
Created attachment 141890 [details]
dmesg with fastboot
Comment 2 Basil Eric Rabi 2018-10-04 10:02:03 UTC
Created attachment 141891 [details]
dmesg with no fastboot
Comment 3 Hans de Goede 2018-10-04 10:24:01 UTC
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 ?
Comment 4 Basil Eric Rabi 2018-10-04 10:42:45 UTC
Created attachment 141892 [details]
journalctl no fastboot
Comment 5 Basil Eric Rabi 2018-10-04 10:43:15 UTC
Created attachment 141893 [details]
journalctl with fastboot
Comment 6 Basil Eric Rabi 2018-10-04 10:43:58 UTC
Attached new files.
Comment 7 Jani Nikula 2018-10-08 09:04:58 UTC
(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?
Comment 8 Basil Eric Rabi 2018-10-08 13:02:01 UTC
Created attachment 141936 [details]
dmesg with no fastboot
Comment 9 Basil Eric Rabi 2018-10-08 13:03:26 UTC
Created attachment 141937 [details]
dmesg with fastboot
Comment 10 Basil Eric Rabi 2018-10-08 13:04:44 UTC
Created attachment 141938 [details]
dmesg with fastboot after suspend/resume
Comment 11 Basil Eric Rabi 2018-10-08 13:21:56 UTC
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?
Comment 12 Jani Nikula 2018-10-11 15:36:18 UTC
(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.)
Comment 13 Basil Eric Rabi 2018-10-11 16:57:13 UTC
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
Comment 14 Hans de Goede 2018-10-12 09:00:42 UTC
(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 ?
Comment 15 Basil Eric Rabi 2018-10-12 10:18:12 UTC
(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.
Comment 16 Jani Nikula 2018-10-22 15:22:24 UTC
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).
Comment 17 Jani Nikula 2018-10-23 11:22:03 UTC
*** Bug 103781 has been marked as a duplicate of this bug. ***
Comment 18 Arthur Borsboom 2018-10-23 13:55:13 UTC
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?
Comment 19 Jani Nikula 2018-10-24 09:21:02 UTC
We don't have a fix yet, and no estimates as fastboot still isn't the default configuration.
Comment 20 Arthur Borsboom 2018-10-24 09:26:20 UTC
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.
Comment 21 Tolga Cakir 2018-11-09 07:29:55 UTC
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
Comment 22 Jani Nikula 2018-11-14 11:05:50 UTC
(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.
Comment 23 Maarten Lankhorst 2018-11-14 11:25:49 UTC
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?
Comment 24 Maarten Lankhorst 2018-11-14 13:39:14 UTC
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?
Comment 25 Maarten Lankhorst 2018-11-15 10:44:08 UTC
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.
Comment 26 Tolga Cakir 2018-11-19 06:57:08 UTC
(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.
Comment 27 Maarten Lankhorst 2018-11-19 08:54:36 UTC
The one in comment 25 should work, if it fails then comment 24 should.. comment 23 won't, for sure.
Comment 28 Tolga Cakir 2018-11-19 16:21:34 UTC
(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.
Comment 29 Hans de Goede 2018-11-19 17:19:04 UTC
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.
Comment 30 Tolga Cakir 2018-11-19 17:25:23 UTC
(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
Comment 31 Maarten Lankhorst 2018-11-19 17:28:10 UTC
Created attachment 142522 [details] [review]
More debug spam

Can you take a look at this patch?
Comment 32 Hans de Goede 2018-11-19 17:44:19 UTC
(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.
Comment 33 Tolga Cakir 2018-11-19 18:54:21 UTC
(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
Comment 34 Arthur Borsboom 2018-11-20 08:51:29 UTC
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.
Comment 35 Maarten Lankhorst 2018-11-20 14:09:11 UTC
Instead of reverting, does applying https://patchwork.freedesktop.org/series/52754/ work?
Comment 36 Maarten Lankhorst 2018-11-20 14:12:53 UTC
*** Bug 108672 has been marked as a duplicate of this bug. ***
Comment 37 Tolga Cakir 2018-11-20 14:24:45 UTC
(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?
Comment 38 Maarten Lankhorst 2018-11-20 14:25:34 UTC
Together! :D
Comment 39 Tolga Cakir 2018-11-20 18:20:11 UTC
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
Comment 40 Maarten Lankhorst 2018-11-29 12:48:41 UTC
Hopefully addressing the backlight issue and backlight issue on s4 resume:

https://patchwork.freedesktop.org/series/53239/
Comment 41 Tolga Cakir 2018-11-29 12:58:18 UTC
Thanks for the patches! I'm just about leaving, I will test when I return in about 8 hours.
Comment 42 Tolga Cakir 2018-11-30 03:26:07 UTC
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?
Comment 43 Maarten Lankhorst 2018-11-30 12:34:01 UTC
dmesg from the resumed kernel would be nice. :)
Comment 44 Tolga Cakir 2018-11-30 15:10:38 UTC
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.
Comment 45 Tolga Cakir 2018-11-30 15:13:32 UTC
Created attachment 142668 [details]
journal S4 resume

Additional drm debug infos after initiating "blind reboot" (line 2140), not included in "dmesg S4 resume".
Comment 46 Maarten Lankhorst 2018-12-07 11:28:30 UTC
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) {

?
Comment 47 Tolga Cakir 2018-12-07 21:43:20 UTC
(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
Comment 48 Tolga Cakir 2018-12-07 23:09:28 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.