Adjust brightness to lowest value caused screen whole black

this is a i915 driver bug and should be fixed already

hmm actually it isn't, I can reproduce it in vivid.. it should be fixed with trusty kernel though so it has regressed in vivid

looks like trusty doesn't work on my intel sdp either, so the bugfix in trusty kernel was hw specific to some extent, so this is not a generic bug

it was fixed for broadwell
https://bugs.launchpad.net/bugs/1339476

and now I see there's a newer bug for older chips
https://bugs.launchpad.net/bugs/1405073

so for what hw was this bug filed for originally? If broadwell, it needs a proper project bug. If earlier, this is a dupe of 1405073 and for kittyhawk2.0 needs to be tested with vivid anyway

hm, didn't notice this was a public bug.. so moving to linux

Timo,

 Thanks for you quick look.
 Here is the original bugs. :)

 https://bugs.launchpad.net/stella/+bug/1281379

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1381625

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

@Timo,
Original oem lp:1281379 was reported with Intel Haswell or Chief River platforms.

We will verify with vivid in kittyhawk 2.0 and update result here.

Issue can be reproduced with below builds, please refer the results below:

[Tested images for verification]
Stock 14.04.1 [ubuntu-14.04.1-desktop-amd64.iso] -> Failed
Stock 14.10 [ubuntu-14.10-desktop-amd64.iso] -> Failed
15.04 daily build @1/13 [vivid-desktop-amd64.iso] -> Failed

[Test Case / Reproduce Steps]
1. Install Image
2. Press System's brightness hotkey to adjust the brightness level to the lowest or
3. Go to System "Settings" -> "Brightness & Lock" to adjust brightness level to the lowest
4. Check if the screen display still has backlight

[Other Info]
1. For 14.04, due to bug#1332379, (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1332379), the brightness cannot be adjusted after the system freshly installed. After adding kernel parameter "video.use_native_backlight=1" it then can work.
2. Test unit: Dell Haswell ULT system

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc4-vivid/

update kernel from 3.16.0-25 to 3.19.0-031900rc4-lowlatency, the brightness issue is not fixed.

my understanding of the oem bug is we think the driver is behaving normal and this should be fixed in user space, Tim Chen already has a patch for g-s-d which we can re-work it for u-s-d.

Ok, so this got fixed for i915_bdw in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1374389

but even the fixed kernel doesn't work on my Wilson Beach SDP, and the commits in i915_bdw got reverted for 3.17 and up. Even drm-intel-next (->4.1) doesn't work.

So I guess it's best to fix in userspace until the driver side is fixed once and for all..

Hey.

I'm researching the behaviour of backlight in the wild and my current theory is that brightness of zero can equally well mean "dim" or "totally off". I don't have a test for that yet so the sample range is very small (the hardware I have at home + several contributions from the community) but that seems to be the case.

I also looked at windows API and I'm about to look at the current Microsoft certification requirements. The API says that the values are arbitrary and no mapping to actual light intensity can be assumed.

If you want to track my work, please look at https://github.com/zyga/lantern

Hey, a small update. Lantern test v2 tests exactly what happens when brightness is set to 0. I have 10 samples so far and I will be able to analyze them today. My gut feeling is that acpi aka firmware control never tuns the backlight off entirely (so setting zero in userspace is safe) while raw control will just disable all light at the same level. I would suggest that for raw controls the bottom value should be 10% of max brightness. The actual value also depends on if the scale is linear or logarithmic which is on my TODO list to check in Lantern.

Status changed to 'Confirmed' because the bug affects multiple users.

see my comments on https://code.launchpad.net/~kaihengfeng/unity-settings-daemon/add-brightness-limit-mechanism/+merge/277416 , high-level userspace isn't the place for changing this.

Can you please elaborate on what the actual bug is here? I. e. what's wrong with turning off the backlight on the lowest level, that seems rather desirable and straightforward to me?

I. e. is the problem that the backlight doesn't come back on when you raise the brightness again or so?

Since Linux kernel v3.18-rc1, it contains

commit e6755fb78e8f20ecadf2a4080084121336624ad9
Author: Jani Nikula <jani.nikula at intel.com>
Date: Tue Aug 12 17:11:42 2014 +0300

    drm/i915: switch off backlight for backlight class 0 brightness

This bug probably targets on how to avoid this driver behavior's change.

Reverting that commit can easily fix this issue or we need to fix all userspace programs related to the brightness control.

There are some scenarios make turning off brightness not desirable, e.g. an AIO user changes brightness to the lowest level in unity-control-center, he can't change it back if his keyboard does not have brightness hotkey.

Since we can't ensure that all graphics driver have the same mechanism and each one of them does not change, I think it's a better choice to let userspace program controls a consistent policy.

So if you run into that situation, discovering that this is configurable and changing the configuration seems equally hard (or harder). I can understand the heuristics what was done upstream in gnome-settings-daemon (see linked bug) to generally clam the brightness to >= 1 if there are many steps. That will work without configuration, does not need to be discovered, and keeps the path open for a better fix in the future as this doesn't set/affect any user config or other permanent state on disk. We could use that approach in unity-settings-daemon too?

Yes, we can use that approach on unity-settings-daemon, with some minor modification to make xbacklight works.

My intention to make it configurable is because there was a Braswell laptop with a cheap panel, which needs at least 5% max brightness to make it barely visible. For OEM projects, to solve problems like that, a minimum brightness setting can be a generic and convenient way to make preloaded Ubuntu more polished.

That being said, most panel works just fine with brightness value 1 in my experience.

Status changed to 'Confirmed' because the bug affects multiple users.

This bug was fixed in the package unity-settings-daemon - 15.04.1+16.04.20151118.1-0ubuntu1

---------------
unity-settings-daemon (15.04.1+16.04.20151118.1-0ubuntu1) xenial; urgency=medium

  [ Shih-Yuan Lee (FourDollars) ]
  * power: On raw backlight types, clamp the value to a minumum (LP:
    #1381625) gsd-rr: Apply the similar method from power plugin to fix
    the lowest brightness issue. (LP: #1381625) (LP: #1381625)

 -- Shih-Yuan Lee <email address hidden> Wed, 18 Nov 2015 09:36:58 +0000

Hello Bin, or anyone else affected,

Accepted gnome-desktop3 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnome-desktop3/3.8.4-0ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

I have verified gnome-desktop3/3.8.4-0ubuntu3.2 by trusty-proposed and it does fix this issue.

This bug was fixed in the package gnome-desktop3 - 3.8.4-0ubuntu3.2

---------------
gnome-desktop3 (3.8.4-0ubuntu3.2) trusty-proposed; urgency=medium

  * Apply the similar method from the power plugin in unity-settings-daemon to
    fix the lowest brightness issue. (LP: #1381625)

 -- Shih-Yuan Lee (FourDollars) <email address hidden> Fri, 20 Nov 2015 15:35:36 +0800

The verification of the Stable Release Update for gnome-desktop3 has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

There's still a merge request pending for unity-settings-daemon. Is that necessary now?

It is not necessary.