Bug 72289

Created attachment 90191 [details]
dmesg w/ drm.debug=0x06

Created attachment 90192 [details]
X.org log

Created attachment 90193 [details]
xrandr --verbose

Created attachment 90194 [details]
intel_reg_dumper

Created attachment 90195 [details]
vbios

Temporal dithering?

Yes, it looks like could be a result from temporal dithering. The Windows driver manages to mask the effect somehow though.

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 ...

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.

Correction, we need bar 0 (bar 1 is only for some older machines). I need to grab coffee before writing more bugzilla comments ;-)

I think I succeeded with that tool. I will attach the 00:02.0 BAR 0 dump if anyone wants to dig into it.

Created attachment 90378 [details]
00:02.0 bar 0 dump from windows

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

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.

It should be already in the attachments. :)

The only relevant difference I could spot is the PIPECONF register:

# intel_reg_write 0x70008 0xd0000000

should write the value Windows uses.

No cigar.

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 ...

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.

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.

Smells like a candidate for Jani's patch to come up with a better backlight tuning value ...

(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?

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.

Joonas, any chance to try again please?

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.

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.

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

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.

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.

Created attachment 99038 [details]
dmesg-3.15.0-rc3-custom.txt

Created attachment 99039 [details]
i915_opregion-3.15.0-rc3-custom.dat

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).

Created attachment 100283 [details]
dmesg (drm.debug=0xe)

Created attachment 100284 [details]
i915_opregion

There was a change in the enable sequence for gen4. Please try current drm-intel-nightly.

That patch seems to not help this bug.

Please retest with latest drm-intel-nighly and attach new logs.

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.

Created attachment 107773 [details]
dmesg 2014-10-13

Created attachment 107774 [details]
i915 opregion 2014-10-13

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?

(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.

Timeout, closing. We may have actually fixed this in nightly to. Please reopen if the problem persists with latest kernels.