Talk:Backlight

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)

system76-oled

Is it worth mentioning this project as a possible solution? It's what I've been using as a stopgap since there appears to be no cohesive solution for OLED right now. Spease (talk) 06:34, 13 April 2020 (UTC)

Nvidia backlight control enabling via nvidia.conf

Hello, on my machine, backlight control would not work unless I made changes to nvidia.conf, as described in: [1] I strongly recommend to include a similar section or redirection to the thinkpad wiki. --KerrnelPanic (talk) 11:04, 7 April 2018 (UTC)

See NVIDIA/Tips_and_tricks#Enabling_brightness_control. -- Lahwaacz (talk) 11:38, 7 April 2018 (UTC)

So why is there no reference on this backlight page?--KerrnelPanic (talk) 12:24, 7 April 2018 (UTC)

I found out that you can enable Nvidia backlight control by using the kernel parameter "nvidia.NVreg_EnableBacklightHandler=1" It took me a long time to find this... it was driving me crazy. I hope this can be referenced on the Backlight page. --KiteGX (talk) 00:08, 1 November 2018 (UTC)

Need to add DefaultDependencies=no to [Unit] section in fix-brightness.service

I faced an issue with fix-brightness.service not run by systemd at startup due to a ordering cycle issue. The solution was to add DefaultDependencies=no to [Unit] section of fix-brightness.service

This topic has been created to discuss this change and get it added to the page for community benefit.

—This unsigned comment is by Shanmukhateja (talk) 05:50, 29 November 2020 (UTC). Please sign your posts with ~~~~!

Why does having DefaultDependencies=yes cause an issue? It is explicitly starting Before=systemd-backlight@backlight:amdgpu_bl0.service therefore there should be no implicit ordering issues. Jonathon (talk) 16:33, 29 November 2020 (UTC)

I don't know why it causes an issue but on my Manjaro Stable branch as of 29 Nov 2020 with systemd version 246, it doesn't work without setting that flag. Here's my boot log in Pastebin: https://pastebin.com/aAe1Vhtv I had to research this stuff to understand what DefaultDependencies was and how to turn it on. —This unsigned comment is by Shanmukhateja (talk) 30 November 2020‎. Please sign your posts with ~~~~!

Udev rules for permissions of brightness doesn't work

See forum pages [2] [3] Sffred (talk) 07:28, 14 January 2021 (UTC)

I've also stumbled on this over the weekend. After playing around for a while, the issue seems to be with using the "GROUP" and "MODE" commands, rather than with matching the parameters. The following rule works for me:

/etc/udev/rules.d/45-backlight.rules

ACTION=="add", SUBSYSTEM=="backlight", KERNEL=="intel_backlight", RUN+="/usr/bin/chgrp video /sys/class/backlight/intel_backlight/brightness"
ACTION=="add", SUBSYSTEM=="backlight", KERNEL=="intel_backlight", RUN+="/usr/bin/chmod g+w /sys/class/backlight/intel_backlight/brightness"

The main difference I see is that here we are explicitly naming the file that is to be the target of changing permissions. Avernan (talk) 15:14, 1 March 2021 (UTC)

The initially suggested rule using MODE and GROUP options of udev also does not work for me. The accuracy dispute banner asks for an explanation why, but all I know is it has no effect. Neither the owner nor permissions of the target files update.

The newer suggestion, supposedly "for intel_backlight", actually has nothing to do with Intel. And it succeeds for me on AMD, by swapping in amdgpu_bl0 in the specified paths.

However, the suggestion is incomplete: As currently written, using only RUN+=..., this appends the new rules to every udev rule. You can expect a system spammed with countless failed with exit code 1 errors until the brightness file actually gets mounted. Each time any rule is checked, it also runs chgrp & chmod on the brightness file.

So, although I cannot explain why the other fails, I agree that when it does fail, these are the correct rules; which both select for the backlight system with ACTION, SUBSYSTEM, and KERNEL and use RUN to explicitly make changes to .../brightness.

/etc/udev/rules.d/backlight.rules

ACTION=="add", SUBSYSTEM=="backlight" KERNEL=="{vendor-specific-name}", RUN+="/bin/chgrp video /sys/class/backlight/intel_backlight/brightness"
ACTION=="add", SUBSYSTEM=="backlight" KERNEL=="{vendor-specific-name}", RUN+="/bin/chmod g+w /sys/class/backlight/intel_backlight/brightness"

I have to wonder though: For those systems that can use the original rule, is there any downside to using this RUN version instead? Skylize (talk) 20:19, 12 May 2022 (UTC)

Information about systemd-backlight@.service seems incorrect

AFAIK, the service it self does not generate anything and is not "enabled by default and static". It is pulled in by udev rules in 99-systemd.rules for each backlight device. DDoSolitary (talk) 12:43, 30 October 2021 (UTC)

Add acpi_backlight=nvidia_wmi_ec Kernel Parameter

Some Optimus laptops have backlight issues under newer Linux kernels. There is a new module called nvidia_wmi_ec that can resolve these issues for some hybrid graphics configurations. Adding acpi_backlight=nvidia_wmi_ec to the kernel command line options enables it at boot and allows the backlight controls to work.

Here is a kernel mailing list thread with more details.

Ddipuma (talk) 17:28, 3 March 2023 (UTC)

sysfs path does not exist

sudo ls /sys/class/backlight/ returns nothing. So I guess it is not available in all systems.

I should note that I came to this article because my monitor brightness changes randomly. I mean the brightness that is set from the monitor menu. I was seeing if it is possible that a software is doing so. Siavoshkc (talk) 16:03, 8 December 2023 (UTC)

If it returns nothing, then /sys/class/backlight/ exists, but is empty – you would get an error if it did not exist. This is common for desktop systems which have only external displays. — Lahwaacz (talk) 09:10, 10 December 2023 (UTC)

So I guess there must be some explanation about the difference for external displays if it causes difference in configuration. Siavoshkc (talk) 10:26, 10 December 2023 (UTC)

I discovered the problem with my monitor brightness was that KDE is dimming display after some time of inactivity. When it tries to bring it back it fails (don't know why but guess monitor does not follow). I disabled the feature and voilà. Siavoshkc (talk) 13:39, 14 July 2024 (UTC)

Need a section on AMD's Ambient Backlight Manager

Recently, on updating to Linux 6.9, on my ASUS AMD laptop, I got automatic backlight dimming as a power saving feature when the charger was unplugged, and I could not find any info on the Wiki about this. My Reddit post about this, for details: https://www.reddit.com/r/archlinux/comments/1dao6if/how_to_kill_laptop_screen_backlight_power_saving/

I was suggested a forum topic where someone did more research on this, including ways to disable it: https://bbs.archlinux.org/viewtopic.php?id=296000

And today I was also shown a section about disabling AMD ABM's panel power savings, but in the Framework Laptop 13 specific Wiki page: Framework Laptop 13#(AMD) Washed-out colors when using power-profiles-daemon in power-saver or balanced mode

This is clearly not a Framework laptop specific feature, so I feel like this should be talked about here. Architector4 (talk) 22:55, 9 July 2024 (UTC)

Remove xbacklight section

Basically as mentioned in the reasoning, there's no usecase that would not be served better by any of the other tools. If one doesn't want to remove, another option might be to recommend installing acpilight instead which provides a CLI-compatible drop-in while doing the more modern correct approach on all drivers. V1del (talk) 18:30, 15 November 2024 (UTC)

Mention xrandr in Color correction section

xrandr is not mentioned in the Color correction section, in spite of being really easy to use, especially for people (like me) who are clueless about ICC profiles. Gamma can be corrected by typing:

   xrandr --output <your connected device> --gamma red:green:blue

The results are immediately visible, and once satisfied, this command can be saved in one's xinitrc. Ftonneau (talk) 12:50, 20 November 2024 (UTC)