Difference between revisions of "Talk:Backlight"

From ArchWiki
Jump to: navigation, search
(Merge with Laptop: Remove closed discussion.)
(New kernel parameters: Remove closed discussion.)
 
(44 intermediate revisions by 9 users not shown)
Line 1: Line 1:
 +
== Potentially misleading tutorial section... or please help me fix this ==
 +
The thing is that, when it increases frequency, it increases brightness proportionally so it effectively just makes the system call it different brightness numbers. I guess this is why they call it "moving the problem".
  
 +
I want higher frequency WITHOUT increasing brightness. What do I do? My intel_reg read 0xC8254 default is "0x12280000 (freq 4648, cycle 0)". [[User:Niceglly|Niceglly]] ([[User talk:Niceglly|talk]]) 08:09, 1 November 2017 (UTC)
 +
 +
:So you don't see a solution to your problem - what's misleading about that? Have you thought if the thing you want is even physically possible? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:02, 1 November 2017 (UTC)
 +
 +
::The section is misleading because it promises a solution to what you call "[my] problem". It doesn't simply say "press FN+brighter and you get rid of the flicker" (which would be true), but it says "do this Backlight PWM modulation frequency magic and you'll fix the flicker" (which does EXACTLY what FN+brighter does); nothing is mentioned about the brightness "side effect" that fully defeats the purpose of the advice. If what I want is physically impossible (it's not; it's just volt vs hertz), shouldn't this page stop promising otherwise, explicitly or implicitly? On the other hand, in your reply you seem to suggest you're not familiar with the problem nor indeed interested in it but you're just addressing some procedural or attitudinal issue; did I (unintentionally) show some slight disrespect for the work of the editors? Either way, I hope my answer adds clarity as to the reasonableness of my original comment. [[User:Niceglly|Niceglly]] ([[User talk:Niceglly|talk]]) 21:27, 1 November 2017 (UTC)
 +
 +
:::In [https://en.wikipedia.org/wiki/Pulse-width_modulation#Principle PWM] control, the brightness depends on duty cycle, not frequency. So if you set the frequency and brightness changes, you're not changing only the frequency. Note that a 0% cycle would give you no light at all, so the system likely treats it as a special value. What values exactly have you been writing to the register? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:41, 2 November 2017 (UTC)
 +
 +
::::I got it from the original {{ic|0x12280000 (freq 4648, cycle 0)}} to {{ic|0x048a0000 (freq 1162, cycle 0)}}. By the way, why does it actually show lower frequency? I assume this is what the {{ic|freq 1162}} (<{{ic|4648}}) means. Also, do you think what I did (quadrupling frequency) is straining it too much? [[User:Niceglly|Niceglly]] ([[User talk:Niceglly|talk]]) 10:09, 2 November 2017 (UTC) (Posted at 09:35, forgot to sign.)
 +
 +
:::::The section says that the value corresponds to the period, which is 1/frequency and hence the value should be decreased to increase the frequency. The command output and [http://devbraindom.blogspot.cz/2013/03/eliminate-led-screen-flicker-with-intel.html?showComment=1479980213611#c6565996920753443004 this post] indicate that the lower 4 hex digits indicate the duty cycle - try to set it to 1228 or something like that and see if changing the upper 4 digits still changes brightness. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:02, 2 November 2017 (UTC)
 +
 +
::::::It is counterintuitive that freq = 1 / frequency; perhaps some long-standing engineering tradition. I tried all those values and the last four digits don't make any difference. However, it turns out that the brightness increase is proportional to the frequency increase far enough from linearly, so increasing frequency does help after all: for more aggressive frequency increases I can notice a flicker reduction when I bring the brightness down to the same level as before the frequency increase.
 +
::::::[[User:Niceglly|Niceglly]] ([[User talk:Niceglly|talk]]) 07:09, 3 November 2017 (UTC)
 +
 +
::::Apparently 1152 in {{ic|/sys/class/backlight/intel_backlight/brightness}}, FYI, is when the flicker begins to become noticeable with a fan test. I need to use a very large ratio ({{ic|0x12280000/$ratio}}) in order to get rid of the flicker when I want very low brightness. I would greatly appreciate it if you could tell me two things: {{ic|(1)}} Since the flicker means too low frequency, compensating all the way up to no flicker is safe AS LONG AS I don't increase brightness; so the register will show very high frequency but I shouldn't worry''':''' the ACTUAL frequency will be much lower (again: only at lower brightness). Am I right? {{ic|(2)}} If I am right, then---by the way---how do I get [the system to return] the ACTUAL frequency? (The frequency value that factors in the current brightness.) That would be the only relevant one, the one I need to keep an eye on while doing all of this risky testing, after all. This way I can draw my own conclusions; actually this way I may not even need an answer to my first question.
 +
::::[[User:Niceglly|Niceglly]] ([[User talk:Niceglly|talk]]) 07:54, 6 November 2017 (UTC)
 +
 +
:::::[http://devbraindom.blogspot.cz/2013/03/eliminate-led-screen-flicker-with-intel.html This page] (linked from the troubleshooting section) says that the PWM frequency is calculated as {{ic|1=fPWM = regC6204 / 128 / regC8254{7:4} }}, where {{ic|regC6204}} is the base clock frequency, 128 is the scaling factor and {{ic|regC8254{7:4} }} is what you write into the register (upper 4 digits). So the ''actual frequency'' is inverse proportional to the value set in the C8254 register.
 +
:::::On the other hand, the "flicker" and brightness are human perceptions and they are the non-linearity in this problem. In any case, the phrase "frequency value that factors in the current brightness" makes no sense - brightness is the result of the parameters set by the system, one of which is frequency.
 +
:::::The problem described in the troubleshooting section is finding a frequency such that the "flicker" is not perceptible at any brightness level. To talk about safety, please explain what you mean by that constraint.
 +
:::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:46, 6 November 2017 (UTC)
 +
 +
== Recommended way to allow a normal user to change brightness ==
 +
 +
What's the recommended way to allow a normal user to change the backlight brightness?  I added a udev rule that could do it, but the change was reverted as "not recommended" -- what is the recommended way, then?
 +
 +
It was also criticized as "wrong matching" -- okay, what's the correct matching?
 +
 +
I don't mind being told I'm doing it wrong, but along with that please tell me how to do it right.  Thanks!
 +
 +
[[User:Jlindgren|John Lindgren]] ([[User talk:Jlindgren|talk]]) 19:10, 3 November 2017 (UTC)
 +
 +
:Almost any tool mentioned in [[Backlight#Backlight_utilities]] will allow this. As for the udev matching, see [[Backlight#Udev_rule]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:13, 3 November 2017 (UTC)
 +
 +
::The only one available from the official repositories (xbacklight) doesn't work with modesetting.  brightnessctl works, I guess.  The fact that it's only available from AUR and installs a setuid binary seems a wee bit scary to me, though.  Personally, I think I'll stick with my world-writable device knob if that's the best solution you can recommend.
 +
 +
::Is it the "ACTION=add" I was missing from the udev rule?  I intentionally left out the "KERNEL==acpi_video0" as I wanted the script to work with either intel_backlight or acpi_video0.
 +
 +
::[[User:Jlindgren|John Lindgren]] ([[User talk:Jlindgren|talk]]) 19:29, 3 November 2017 (UTC)
 +
 +
:::Then you need to write multiple rules for each value of KERNEL you want to match. Otherwise the rule will match anything in the subsystem and you'll get errors in the log if the path does not happen to exist. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:26, 3 November 2017 (UTC)

Latest revision as of 07:20, 7 November 2017

Potentially misleading tutorial section... or please help me fix this

The thing is that, when it increases frequency, it increases brightness proportionally so it effectively just makes the system call it different brightness numbers. I guess this is why they call it "moving the problem".

I want higher frequency WITHOUT increasing brightness. What do I do? My intel_reg read 0xC8254 default is "0x12280000 (freq 4648, cycle 0)". Niceglly (talk) 08:09, 1 November 2017 (UTC)

So you don't see a solution to your problem - what's misleading about that? Have you thought if the thing you want is even physically possible? -- Lahwaacz (talk) 18:02, 1 November 2017 (UTC)
The section is misleading because it promises a solution to what you call "[my] problem". It doesn't simply say "press FN+brighter and you get rid of the flicker" (which would be true), but it says "do this Backlight PWM modulation frequency magic and you'll fix the flicker" (which does EXACTLY what FN+brighter does); nothing is mentioned about the brightness "side effect" that fully defeats the purpose of the advice. If what I want is physically impossible (it's not; it's just volt vs hertz), shouldn't this page stop promising otherwise, explicitly or implicitly? On the other hand, in your reply you seem to suggest you're not familiar with the problem nor indeed interested in it but you're just addressing some procedural or attitudinal issue; did I (unintentionally) show some slight disrespect for the work of the editors? Either way, I hope my answer adds clarity as to the reasonableness of my original comment. Niceglly (talk) 21:27, 1 November 2017 (UTC)
In PWM control, the brightness depends on duty cycle, not frequency. So if you set the frequency and brightness changes, you're not changing only the frequency. Note that a 0% cycle would give you no light at all, so the system likely treats it as a special value. What values exactly have you been writing to the register? -- Lahwaacz (talk) 07:41, 2 November 2017 (UTC)
I got it from the original 0x12280000 (freq 4648, cycle 0) to 0x048a0000 (freq 1162, cycle 0). By the way, why does it actually show lower frequency? I assume this is what the freq 1162 (<4648) means. Also, do you think what I did (quadrupling frequency) is straining it too much? Niceglly (talk) 10:09, 2 November 2017 (UTC) (Posted at 09:35, forgot to sign.)
The section says that the value corresponds to the period, which is 1/frequency and hence the value should be decreased to increase the frequency. The command output and this post indicate that the lower 4 hex digits indicate the duty cycle - try to set it to 1228 or something like that and see if changing the upper 4 digits still changes brightness. -- Lahwaacz (talk) 19:02, 2 November 2017 (UTC)
It is counterintuitive that freq = 1 / frequency; perhaps some long-standing engineering tradition. I tried all those values and the last four digits don't make any difference. However, it turns out that the brightness increase is proportional to the frequency increase far enough from linearly, so increasing frequency does help after all: for more aggressive frequency increases I can notice a flicker reduction when I bring the brightness down to the same level as before the frequency increase.
Niceglly (talk) 07:09, 3 November 2017 (UTC)
Apparently 1152 in /sys/class/backlight/intel_backlight/brightness, FYI, is when the flicker begins to become noticeable with a fan test. I need to use a very large ratio (0x12280000/$ratio) in order to get rid of the flicker when I want very low brightness. I would greatly appreciate it if you could tell me two things: (1) Since the flicker means too low frequency, compensating all the way up to no flicker is safe AS LONG AS I don't increase brightness; so the register will show very high frequency but I shouldn't worry: the ACTUAL frequency will be much lower (again: only at lower brightness). Am I right? (2) If I am right, then---by the way---how do I get [the system to return] the ACTUAL frequency? (The frequency value that factors in the current brightness.) That would be the only relevant one, the one I need to keep an eye on while doing all of this risky testing, after all. This way I can draw my own conclusions; actually this way I may not even need an answer to my first question.
Niceglly (talk) 07:54, 6 November 2017 (UTC)
This page (linked from the troubleshooting section) says that the PWM frequency is calculated as fPWM = regC6204 / 128 / regC8254{7:4}, where regC6204 is the base clock frequency, 128 is the scaling factor and regC8254{7:4} is what you write into the register (upper 4 digits). So the actual frequency is inverse proportional to the value set in the C8254 register.
On the other hand, the "flicker" and brightness are human perceptions and they are the non-linearity in this problem. In any case, the phrase "frequency value that factors in the current brightness" makes no sense - brightness is the result of the parameters set by the system, one of which is frequency.
The problem described in the troubleshooting section is finding a frequency such that the "flicker" is not perceptible at any brightness level. To talk about safety, please explain what you mean by that constraint.
-- Lahwaacz (talk) 16:46, 6 November 2017 (UTC)

Recommended way to allow a normal user to change brightness

What's the recommended way to allow a normal user to change the backlight brightness? I added a udev rule that could do it, but the change was reverted as "not recommended" -- what is the recommended way, then?

It was also criticized as "wrong matching" -- okay, what's the correct matching?

I don't mind being told I'm doing it wrong, but along with that please tell me how to do it right. Thanks!

John Lindgren (talk) 19:10, 3 November 2017 (UTC)

Almost any tool mentioned in Backlight#Backlight_utilities will allow this. As for the udev matching, see Backlight#Udev_rule. -- Lahwaacz (talk) 19:13, 3 November 2017 (UTC)
The only one available from the official repositories (xbacklight) doesn't work with modesetting. brightnessctl works, I guess. The fact that it's only available from AUR and installs a setuid binary seems a wee bit scary to me, though. Personally, I think I'll stick with my world-writable device knob if that's the best solution you can recommend.
Is it the "ACTION=add" I was missing from the udev rule? I intentionally left out the "KERNEL==acpi_video0" as I wanted the script to work with either intel_backlight or acpi_video0.
John Lindgren (talk) 19:29, 3 November 2017 (UTC)
Then you need to write multiple rules for each value of KERNEL you want to match. Otherwise the rule will match anything in the subsystem and you'll get errors in the log if the path does not happen to exist. -- Lahwaacz (talk) 20:26, 3 November 2017 (UTC)