Bug 72289

Summary: [GM45 backlight] LCD waterfall effect on HP 2230s laptop
Product: DRI Reporter: Joonas Saarinen <jza>
Component: DRM/IntelAssignee: Intel GFX Bugs mailing list <intel-gfx-bugs>
Status: CLOSED WORKSFORME QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: medium CC: intel-gfx-bugs, jani.nikula, jza
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: GM45 i915 features: display/backlight
Attachments:
Description Flags
dmesg w/ drm.debug=0x06
none
X.org log
none
xrandr --verbose
none
intel_reg_dumper
none
vbios
none
00:02.0 bar 0 dump from windows
none
dmesg-3.15.0-rc3-custom.txt
none
i915_opregion-3.15.0-rc3-custom.dat
none
dmesg (drm.debug=0xe)
none
i915_opregion
none
dmesg 2014-10-13
none
i915 opregion 2014-10-13 none

Description Joonas Saarinen 2013-12-03 22:25:21 UTC
System environment:
-- chipset: GM45
-- system architecture: x86_64
-- xserver-xorg-video-intel: 2:2.99.904-0ubuntu2
-- xserver-xorg: 1:7.7+1ubuntu6
-- kernel: 3.11.0-12-generic
-- Linux distribution: Xubuntu 13.10
-- Machine or mobo model: Hewlett-Packard 2230s (FU312EA#AK8), BIOS: 68PHU Ver. F20
-- Display connector: LVDS

Reproducing steps: Reproducable always by using the X.org desktop normally.

Additional info:

The display of the laptop has a waterfall interference effect when used with the Linux Intel GPU driver. The effect is more pronounced the lower the display brightness is set. On maximum brightness, the effect cannot be perceived.

The screen is completely calm on all brightness levels when the Windows driver is used. Notice though that the bad effect is also present in BIOS menus and when an operating system with a generic display driver is used. Maybe the driver or LCD panel has to be configured in certain way to make the effect disappear.

I captured a short video showing the effect: http://users.metropolia.fi/~joonasms/waterfall.3gp

In the included dmesg with drm.debug=0x06 I have booted the machine with maximum brightness, then adjusted it all the way down, and then back all the way up.
Comment 1 Joonas Saarinen 2013-12-03 22:26:34 UTC
Created attachment 90191 [details]
dmesg w/ drm.debug=0x06
Comment 2 Joonas Saarinen 2013-12-03 22:27:06 UTC
Created attachment 90192 [details]
X.org log
Comment 3 Joonas Saarinen 2013-12-03 22:27:40 UTC
Created attachment 90193 [details]
xrandr --verbose
Comment 4 Joonas Saarinen 2013-12-03 22:28:33 UTC
Created attachment 90194 [details]
intel_reg_dumper
Comment 5 Joonas Saarinen 2013-12-03 22:28:56 UTC
Created attachment 90195 [details]
vbios
Comment 6 Chris Wilson 2013-12-03 22:34:26 UTC
Temporal dithering?
Comment 7 Joonas Saarinen 2013-12-03 22:54:43 UTC
Yes, it looks like could be a result from temporal dithering. The Windows driver manages to mask the effect somehow though.
Comment 8 Daniel Vetter 2013-12-04 08:30:09 UTC
We don't do temporal dithering. I suspect the backlight values aren't good as set in the vbios/vbt, and windows somehow fixes it. But just speculation really.

It would be interesting to grab a register dump from windows (crazy people managed to do that) and compare it to linux. But I have no idea how to do that ...
Comment 9 Daniel Vetter 2013-12-04 08:35:25 UTC
http://www.pcitree.de/userguide.html seems to be a tool which can grab a dump of the PCI bar. For your machine we'd need a dump of device 00:02.0 bar 1. It should be 1M big.
Comment 10 Daniel Vetter 2013-12-04 08:36:13 UTC
Correction, we need bar 0 (bar 1 is only for some older machines). I need to grab coffee before writing more bugzilla comments ;-)
Comment 11 Joonas Saarinen 2013-12-06 21:43:18 UTC
I think I succeeded with that tool. I will attach the 00:02.0 BAR 0 dump if anyone wants to dig into it.
Comment 12 Joonas Saarinen 2013-12-06 21:44:14 UTC
Created attachment 90378 [details]
00:02.0 bar 0 dump from windows
Comment 13 Joonas Saarinen 2013-12-06 22:01:18 UTC
And while we are at it, here's also a video of the screen under Windows. I set it to show the same Xubuntu wallpaper.

http://users.metropolia.fi/~joonasms/no_waterfall.3gp
Comment 14 Daniel Vetter 2013-12-07 08:36:31 UTC
Seems to have succeeded, the decoded dump makes sense. Now we need the same thing from Linux, with the same config (i.e. no external screens or such stuff). Please grab the latest intel-gpu-tools from git

http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/

and run the intel_reg_duper tool and attach its output.
Comment 15 Joonas Saarinen 2013-12-07 12:12:13 UTC
It should be already in the attachments. :)
Comment 16 Daniel Vetter 2013-12-09 10:34:11 UTC
The only relevant difference I could spot is the PIPECONF register:

# intel_reg_write 0x70008 0xd0000000

should write the value Windows uses.
Comment 17 Joonas Saarinen 2013-12-09 12:41:47 UTC
No cigar.
Comment 18 Daniel Vetter 2013-12-10 07:33:53 UTC
I've hunted around in docs for magic registers, but didn't spot anything else than what we decode already. And besides the pipeconf there's nothing really different which would matter ...
Comment 19 Daniel Vetter 2013-12-10 07:38:06 UTC
Hm, the backlight controls are different, that could be it:

# intel_reg_write 0x61250 0x80000000
# intel_reg_write 0x61254 0x15cc07c6

Note that as soon as you do any brightness changes we'll overwrite these settings again. So don't touch any brightness keys/settings and disable autodimming for testing.

If it works please also test them individually to figure out which one is the important change.
Comment 20 Joonas Saarinen 2013-12-10 08:21:49 UTC
Well, that was an excellent discovery.

It seems that the latter one (0x61254 0x15cc07c6) simply fixes the problem completely.

I'm not sure if the former one plays any role of importance here.
Comment 21 Daniel Vetter 2013-12-10 09:45:10 UTC
Smells like a candidate for Jani's patch to come up with a better backlight tuning value ...
Comment 22 Jani Nikula 2013-12-20 13:34:15 UTC
(In reply to comment #21)
> Smells like a candidate for Jani's patch to come up with a better backlight
> tuning value ...

Joonas, in the mean time, how's backlight running drm-intel-nightly branch of http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-nightly?
Comment 23 Joonas Saarinen 2014-01-19 11:29:32 UTC
The kernel pulled from the drm-intel tree freezes after "Loading initial ramdisk", could be that I botched something. Vanilla 3.13.0-rc8 kernel shows no improvement though.
Comment 24 Jani Nikula 2014-03-14 13:21:23 UTC
Joonas, any chance to try again please?
Comment 25 Jani Nikula 2014-04-10 13:19:11 UTC
Joonas, ping for updates.

(In reply to comment #20)
> Well, that was an excellent discovery.
> 
> It seems that the latter one (0x61254 0x15cc07c6) simply fixes the problem
> completely.
> 
> I'm not sure if the former one plays any role of importance here.

It might make a crucial difference, since register 0x61250 bit 30 that's set in your reg dump but not in Daniel's suggestion (presumably based on Windows) is the "combination mode". Register 0x61254 has backlight modulation frequency and duty cycle. So I'd very much like you to try:

# intel_reg_write 0x61250 0x00000000 && intel_reg_write 0x61250 0x80000000

and see if that fixes the issue. If not, I'd like you to reboot, and try:

# intel_reg_write 0x61250 0x00000000 && intel_reg_write 0x61254 0x15cc07c6 && intel_reg_write 0x61250 0xc0000000

(All on one command line just because one at a time you'll get a black screen and it'll be hard to continue ;)

Finally it would be nice to retest on v3.14 or later because we changed the backlight code considerably, and further debugging will be easier on the recent code base.
Comment 26 Joonas Saarinen 2014-04-11 16:09:44 UTC
Here are some new results (I rebooted between each test).

1) Ubuntu Trusty kernel 3.13.0-19-generic
# intel_reg_write 0x61250 0x00000000 && intel_reg_write 0x61250 0x80000000

No perceivable effect (waterfall effect remains).

2) Ubuntu Trusty kernel 3.13.0-19-generic
# intel_reg_write 0x61250 0x00000000 && intel_reg_write 0x61254 0x15cc07c6 && intel_reg_write 0x61250 0xc0000000

The backlight works great.

3) The most recent upstream git Linux kernel
# intel_reg_write 0x61250 0x00000000 && intel_reg_write 0x61250 0x80000000

The brightness adjustment has no effect, constantly maximum brightness.

4) The most recent upstream git Linux kernel
# intel_reg_write 0x61250 0x00000000 && intel_reg_write 0x61254 0x15cc07c6 && intel_reg_write 0x61250 0xc0000000

The backlight is stable. However the dynamic range is incorrect. The display starts to dim when I go below about 40% brightness, all settings above that correspond max brightness.
Comment 27 Joonas Saarinen 2014-04-11 16:30:31 UTC
Couple of more observations...

The more recent kernel does not retain the modified backlight values when the display goes to sleep. The older one works.

Additionally, with both kernels only the first 16 bits of the value 0x15cc07c6 get written (not sure if it means anything):

Value before: 0x305E305E
Value after: 0x15CC305E
Comment 28 Jani Nikula 2014-05-07 12:38:06 UTC
Please try current drm-intel-nightly from http://cgit.freedesktop.org/drm-intel and attach dmesg with drm.debug=0xe. Also please attach /sys/kernel/debug/dri/0/i915_opregion. Thanks.
Comment 29 Joonas Saarinen 2014-05-14 17:11:44 UTC
Currently that tree seems to fail with "render ring initialization failed".

I'll attach a couple of files, but I'm not sure if they are useful right now.

With that kernel I cannot get past the login screen anyway.
Comment 30 Joonas Saarinen 2014-05-14 17:12:54 UTC
Created attachment 99038 [details]
dmesg-3.15.0-rc3-custom.txt
Comment 31 Joonas Saarinen 2014-05-14 17:13:22 UTC
Created attachment 99039 [details]
i915_opregion-3.15.0-rc3-custom.dat
Comment 32 Joonas Saarinen 2014-06-02 10:49:19 UTC
Ok, apparently in the current drm-intel the render ring bug does not appear anymore. So some updated info.

Before touching registers manually, the panel still flickers. The other results are also similar as before.

# intel_reg_write 0x61250 0x00000000 && intel_reg_write 0x61250 0x80000000

Result: always maximum brightness.

# intel_reg_write 0x61250 0x00000000 && intel_reg_write 0x61254 0x15cc07c6 && intel_reg_write 0x61250 0xc0000000

Result: backlight ok, but the dynamic range is wrong.

Will attach dmesg and i915_opregion (before any register writes).
Comment 33 Joonas Saarinen 2014-06-02 10:50:30 UTC
Created attachment 100283 [details]
dmesg (drm.debug=0xe)
Comment 34 Joonas Saarinen 2014-06-02 10:51:10 UTC
Created attachment 100284 [details]
i915_opregion
Comment 35 Jani Nikula 2014-06-18 15:01:08 UTC
There was a change in the enable sequence for gen4. Please try current drm-intel-nightly.
Comment 36 Joonas Saarinen 2014-06-18 21:38:28 UTC
That patch seems to not help this bug.
Comment 37 Rodrigo Vivi 2014-10-08 20:21:48 UTC
Please retest with latest drm-intel-nighly and attach new logs.
Comment 38 Joonas Saarinen 2014-10-13 12:53:46 UTC
Will do.

The backlight range seems correct now, although the range becomes wrong once I write the new backlight PWM value. Anyway, before manually setting the new value, the display still has the wavy effect, so problem remains.

So how does this work? If done properly, should it be the responsibility of the video BIOS to set the correct PWM value already when the machine is started? I know that there has been batches of this computer sold with both CMO and SEC panel. So maybe the former works properly, but with low frequency the internal temporal dithering in the SEC display goes haywire and HP did not account for this? But then again, the Windows driver takes care of it, which makes me almost wonder that there is some exception for this panel baked in. Maybe not, though.
Comment 39 Joonas Saarinen 2014-10-13 12:54:52 UTC
Created attachment 107773 [details]
dmesg 2014-10-13
Comment 40 Joonas Saarinen 2014-10-13 12:55:50 UTC
Created attachment 107774 [details]
i915 opregion 2014-10-13
Comment 41 Jesse Barnes 2015-03-09 22:03:24 UTC
Well, it's definitely possible we have to re-program the PWM params as those are panel specific; I think the VBT is supposed to be updated with the correct values.

Jani, do we trust those these days?  Maybe current bits will behave better?
Comment 42 Jani Nikula 2015-03-10 17:12:45 UTC
(In reply to Jesse Barnes from comment #41)
> Well, it's definitely possible we have to re-program the PWM params as those
> are panel specific; I think the VBT is supposed to be updated with the
> correct values.
> 
> Jani, do we trust those these days?  Maybe current bits will behave better?

No, we don't look at the PWM freq in VBT, we just use whatever the BIOS used at boot. Which *should* be the same thing.

I had patches eons ago to use the VBT freq, but I haven't updated them in a while. The VBT has the frequency in Hz (which I think is a surprisingly sane choice) but translating that to the register value depends on clocks and needs a bunch of platform specific code. And I'm not really sure it's worthwhile to be adding that for the oldest gens.
Comment 43 Jani Nikula 2015-10-23 12:29:10 UTC
Timeout, closing. We may have actually fixed this in nightly to. Please reopen if the problem persists with latest kernels.

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.