Bug 86936 - Facilitate override on minimum brightness level
Summary: Facilitate override on minimum brightness level
Status: REOPENED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: All Linux (All)
: medium enhancement
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-02 15:37 UTC by Aurabindo J
Modified: 2019-01-07 09:39 UTC (History)
2 users (show)

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


Attachments
/sys/kernel/debug/dri/0/i915_opregion (8.00 KB, text/plain)
2014-12-02 15:37 UTC, Aurabindo J
no flags Details
Add a module parameter for overriding minimum brightness control (3.40 KB, patch)
2014-12-02 15:39 UTC, Aurabindo J
no flags Details | Splinter Review
Dmesg with drm.debug=14 (98.77 KB, text/plain)
2014-12-04 16:21 UTC, Aurabindo J
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aurabindo J 2014-12-02 15:37:03 UTC
Created attachment 110359 [details]
/sys/kernel/debug/dri/0/i915_opregion

Recent changes made the minimum allowed brightness level from 0 to an arbitrary value of 25% (of Max value).

Such an arbitrary value may not be suitable for all users alike. However, it also fixes some issues on a few hardware. Hence facilitate an override for systems that work sanely without limit on minimum brightneess.

Mailing list thread: http://www.gossamer-threads.com/lists/linux/kernel/2060904

Associated commit:

commit e1c412e75754ab7b7002f3e18a2652d999c40d4b
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Wed Nov 5 14:46:31 2014 +0200

    drm/i915: safeguard against too high minimum brightness
    
    Never trust (your interpretation of) the VBT. Regression from
    
    commit 6dda730e55f412a6dfb181cae6784822ba463847
    Author: Jani Nikula <jani.nikula@intel.com>
    Date:   Tue Jun 24 18:27:40 2014 +0300
    
        drm/i915: respect the VBT minimum backlight brightness
Comment 1 Aurabindo J 2014-12-02 15:39:18 UTC
Created attachment 110360 [details] [review]
Add a module parameter for overriding minimum brightness control
Comment 2 Jani Nikula 2014-12-03 08:38:09 UTC
(In reply to Aurabindo J from comment #0)
> Associated commit:
> 
> commit e1c412e75754ab7b7002f3e18a2652d999c40d4b
> Author: Jani Nikula <jani.nikula@intel.com>
> Date:   Wed Nov 5 14:46:31 2014 +0200
> 
>     drm/i915: safeguard against too high minimum brightness
>     
>     Never trust (your interpretation of) the VBT. Regression from
>     
>     commit 6dda730e55f412a6dfb181cae6784822ba463847
>     Author: Jani Nikula <jani.nikula@intel.com>
>     Date:   Tue Jun 24 18:27:40 2014 +0300
>     
>         drm/i915: respect the VBT minimum backlight brightness

The first commit ("drm/i915: respect the VBT minimum backlight brightness") is the real culprit in your case. It starts restricting the minimum brightness based on VBT. The VBT value is supposed to have been selected by the OEM to match the hardware requirements.

The second commit ("drm/i915: safeguard against too high minimum brightness") ensures the limit isn't "too high". It should *not* be effective in your case, where the minimum per VBT is (15/255)*max, i.e. you can't go below 5%.
Comment 3 Jani Nikula 2014-12-03 08:43:16 UTC
A few additional things to consider.

First, does 5% brightness running a kernel before the offending commit correspond to lowest brightness running a kernel after the offending commit?

Second, there might be a catch here. The brightness UI, whichever it may be, might provide you with an arbitrary number of steps. The UI might not let you choose the lowest non-zero brightness. E.g. going up from 0, it probably jumps to something other than 1.

See if this gives you more desirable results:

# echo 1 > /sys/class/brightness/intel_backlight/brightness
Comment 4 Aurabindo J 2014-12-03 13:03:37 UTC
(In reply to Jani Nikula from comment #2)
> (In reply to Aurabindo J from comment #0)
> > Associated commit:
> > 
> > commit e1c412e75754ab7b7002f3e18a2652d999c40d4b
> > Author: Jani Nikula <jani.nikula@intel.com>
> > Date:   Wed Nov 5 14:46:31 2014 +0200
> > 
> >     drm/i915: safeguard against too high minimum brightness
> >     
> >     Never trust (your interpretation of) the VBT. Regression from
> >     
> >     commit 6dda730e55f412a6dfb181cae6784822ba463847
> >     Author: Jani Nikula <jani.nikula@intel.com>
> >     Date:   Tue Jun 24 18:27:40 2014 +0300
> >     
> >         drm/i915: respect the VBT minimum backlight brightness
> 
> The first commit ("drm/i915: respect the VBT minimum backlight brightness")
> is the real culprit in your case. It starts restricting the minimum
> brightness based on VBT. The VBT value is supposed to have been selected by
> the OEM to match the hardware requirements.

Yes, I noticed it right the first time itself, thats why I included info about both the commits.

> 
> The second commit ("drm/i915: safeguard against too high minimum
> brightness") ensures the limit isn't "too high". It should *not* be
> effective in your case, where the minimum per VBT is (15/255)*max, i.e. you
> can't go below 5%.

my /sys/class/backlight/intel_backlight/max_brightness says 5273. So percentage is calculated relative to this value ? The minimum level I can set is 64 after the offending commit, which is obviously the arbitrary value hardcoded. It is neither the 5%, which should have been ~264, nor 25%, which would be ~1319

If you meant 5% of *255* (and it is), which would be ~ 13, and it is not the new minimum for me, rather 64. So where does 15 come into picture? Wild rounding or anything else? And please clarify what "max" you meant.

Older one also showed proper actual_brightness. But latest kernel always gives 0. By older one, I meant the one without *both* of the referenced commit. I didnt test it in between. Actually 3.10 (the one in centos 7). The newer on is from arch (3.17)
Comment 5 Aurabindo J 2014-12-03 13:19:17 UTC
(In reply to Jani Nikula from comment #3)
> A few additional things to consider.
> 
> First, does 5% brightness running a kernel before the offending commit
> correspond to lowest brightness running a kernel after the offending commit?

No, since 5% (of 255)  brightness is at 12 and the new minimum in current kernel is 64.

> 
> Second, there might be a catch here. The brightness UI, whichever it may be,
> might provide you with an arbitrary number of steps. The UI might not let
> you choose the lowest non-zero brightness. E.g. going up from 0, it probably
> jumps to something other than 1.

Yes the brightness UI always goes in steps, though not linearly. It seems to be exponential since at times I see very lower brightness states (before offending commits) between the usually-smallest and turned-off state when I am pressing holding brightness down key from the highest brightness level. I dont get this intermediate level when for going down from other states, for example second lowest.

However, it is letting me choose the smallest level of 64 (in  newer kernels).  Since I cannot read the actual_brightness to know the current level (it is always 0 in new kernel). But I confirmed it by manually echoing the test case values and visually inspecting for any change in brightness for the minimum value supported  by UI. For all values above 64, the UI was able to reduce the brightness by a some amount.

> 
> See if this gives you more desirable results:
> 
> # echo 1 > /sys/class/brightness/intel_backlight/brightness

This still puts the current level to 64, which is a bit on the high side.

Please let me know other details you need
Comment 6 Jani Nikula 2014-12-03 14:12:42 UTC
Please attach dmesg with drm.debug=14 module parameter set with a newer kernel (=including both commits).

15 is a value extracted from the VBT (which is in the opregion you attached). It is a coefficient (15/255)*max where max is max_brightness. That translates to the max being about 5% of the max.

The minimum brightness should *not* affect what you can set the brightness interface to. All values 0..max_brightness are allowed, and it should just scale the input suitable for hardware.
Comment 7 Jani Nikula 2014-12-03 14:15:07 UTC
(In reply to Aurabindo J from comment #4)
> my /sys/class/backlight/intel_backlight/max_brightness says 5273. So
> percentage is calculated relative to this value ? The minimum level I can
> set is 64 after the offending commit, which is obviously the arbitrary value
> hardcoded.

The commits should have no impact on what you can write to the brightness interface.

> Older one also showed proper actual_brightness. But latest kernel always
> gives 0. By older one, I meant the one without *both* of the referenced
> commit. I didnt test it in between. Actually 3.10 (the one in centos 7). The
> newer on is from arch (3.17)

That's odd. What's the machine?
Comment 8 Aurabindo J 2014-12-04 16:20:33 UTC
(In reply to Jani Nikula from comment #7)

> 
> That's odd. What's the machine?

Here is the DMI decode http://pastebin.com/hS5UtPxm
Comment 9 Aurabindo J 2014-12-04 16:21:35 UTC
Created attachment 110462 [details]
Dmesg with drm.debug=14
Comment 10 Aurabindo J 2014-12-14 13:36:35 UTC
Hi Jani,

This still needs to be in NEEDINFO. Do you need any other details ?
Comment 11 Jani Nikula 2014-12-15 08:47:46 UTC
Please try video.use_native_backlight=0 module parameter.
Comment 12 Aurabindo J 2014-12-19 09:21:53 UTC
(In reply to Jani Nikula from comment #11)
> Please try video.use_native_backlight=0 module parameter.

I'm afraid that doesn't change anything. The minimum level stays as such, at 64.
new dmesg with drm debug option and video.use_native_backlight=0 is at http://pastebin.com/0nFxW3qP
Comment 13 Adi H 2015-09-17 03:38:39 UTC
This bug is preventing us from upgrading the kernel. Please bring back the old behaviour: give us a way to override the restriction on minimum backlight brightness.
Comment 14 Jari Tahvanainen 2017-03-01 15:13:20 UTC
Adi H (3aditya3@gmail.com), is this problem still valid?
Comment 15 Ricardo 2017-05-30 17:57:20 UTC
based on the lack of activity and a response from the submitter to update results with latest configuration the bug will be closed
Comment 16 Aurabindo J 2019-01-07 09:38:58 UTC
Hi,

Apologies for the inactivity.

I'd like a more sensible default rather than the solution "minimum brightness is [an arbitrary] 25% of maximum brightness"


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.