screen brightness

[s-light]

research how screenbrightness is handled by windows..
then implement for linux.

[RobinVanCauter]

I saw you managed to make brightness control work using icc-brightness; how did you set it up for both displays?

After running the tool I only managed to change the brightness of the second display, which even on maximum seems rather dim in comparison to the main display (which is probably at full brightness, so that could be why).

It's also a bit buggy, when I change the brightness, it is like the display is flickering to max brightness for a split second first.

Any pointers on this?

Thanks for all of your investigation so far, it's been really helpful!

[s-light]

hello @T-Grave ,
great you found the information :-)

i have setup icc-brightness just as in the orig. repository readme.
and with this it is working for me for the main screen (the top one = OLED)
(but i loose the color-resolution of course....)
sometimes icc-brightness gets buggy. then not every brightness step is working.
if this happens i just do a $ icc-brightness clean this deletes the automatically generated profiles.
and then it is working again..

i dont see any flickering..

for the bottom screen i have currently no way to dim it.
i experimented a little bit with DDC (Display Data Channel) and the I2C devices i found..
but did not get any results yet..
i think / hope that is the way it is done undder windows...

there are some basic information out there:

• Is there a way to adjusts the brightness of the monitor?
• Control brightness of external monitors on Linux

for me that is what i tried so far:

$ i2cdetect -l
i2c-3   i2c             i915 gmbus dpb                          I2C adapter
i2c-10  i2c             DPDDC-D                                 I2C adapter
i2c-1   smbus           SMBus I801 adapter at efa0              SMBus adapter
i2c-8   i2c             DPDDC-A                                 I2C adapter
i2c-6   i2c             i915 gmbus dpd                          I2C adapter
i2c-13  i2c             NVIDIA i2c adapter 1 at 1:00.0          I2C adapter
i2c-4   i2c             i915 gmbus dpc                          I2C adapter
i2c-11  i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-2   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-0   i2c             NVIDIA GPU I2C adapter                  I2C adapter
i2c-9   i2c             DPDDC-B                                 I2C adapter
i2c-7   i2c             Synopsys DesignWare I2C adapter         I2C adapter
i2c-14  i2c             NVIDIA i2c adapter 7 at 1:00.0          I2C adapter
i2c-5   i2c             i915 gmbus misc                         I2C adapter
i2c-12  i2c             Synopsys DesignWare I2C adapter         I2C adapter

but ddcutil detect only partly works:

$ ddcutil detect
Failure getting EDID for /dev/i2c-0: status code=EOPNOTSUPP(-95): Operation not supported
Invalid display
   I2C bus:             /dev/i2c-8
   EDID synopsis:
      Mfg id:           SDC
      Model:            Unspecified
      Serial number:    Unspecified
      Manufacture year: 2019
      EDID version:     1.4
   DDC communication failed

Invalid display
   I2C bus:             /dev/i2c-10
   EDID synopsis:
      Mfg id:           BOE
      Model:            Unspecified
      Serial number:    Unspecified
      Manufacture year: 2019
      EDID version:     1.4
   DDC communication failed

i had no time to try the fix mentioned for nvidia cards yet..
and i don't tried ddccontrol

the other idea i had was to start windows and try to get som traces with wireshark - hopefully finding if the system is doing the brightness changes per i2c...

[RobinVanCauter]

I also checked out ddcutil and gave it a try with the verbose option.

This appears to be a laptop display. Laptop displays do not support DDC/CI.

So I guess DDC won't be an option 😞

Below the full output of ddcutil detect --verbose gave me the following output:

Output level:               Verbose
Reporting DDC data errors:  false
Trace groups active:        none
Traced functions:           none
Traced files:               none
Force I2C slave address:    false

Invalid display
   I2C bus:             /dev/i2c-7
      I2C address 0x30 (EDID block#)  present: false
      I2C address 0x37 (DDC)          present: false
      I2C address 0x50 (EDID)         present: true 
      /sys/bus/i2c/devices/i2c-7/name: DPDDC-A
   EDID synopsis:
      Mfg id:           SDC
      Model:            Unspecified
      Serial number:    Unspecified
      Manufacture year: 2019
      EDID version:     1.4
      Product code:     41001
      Extra descriptor: Unspecified
      Video input definition: 0xb5 - Digital Input (DisplayPort)
      Supported features:
         Digital display type: RGB 4:4:4
         Standard sRGB color space: False
      White x,y:        0.312, 0.329
      Red   x,y:        0.685, 0.312
      Green x,y:        0.243, 0.707
      Blue  x,y:        0.139, 0.055
      Extension blocks: 1
   EDID source: 
   EDID hex dump:
              +0          +4          +8          +c            0   4   8   c   
      +0000   00 ff ff ff ff ff ff 00 4c 83 29 a0 00 00 00 00   ........L.).....
      +0010   08 1d 01 04 b5 22 13 78 02 44 81 af 50 3e b5 23   .....".x.D..P>.#
      +0020   0e 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01   .PT.............
      +0030   01 01 01 01 01 01 fd df 00 30 f2 70 0c 80 30 20   .........0.p..0 
      +0040   44 00 58 c2 10 00 00 1b fd df 00 30 f2 70 0c 80   D.X........0.p..
      +0050   30 20 44 00 58 c2 10 00 00 1b 00 00 00 0f 00 ff   0 D.X...........
      +0060   09 3c ff 09 3c 2c 80 00 00 00 00 00 00 00 00 10   .<..<,..........
      +0070   00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 4a   ...............J
   DDC communication failed
   This appears to be a laptop display. Laptop displays do not support DDC/CI.

Invalid display
   I2C bus:             /dev/i2c-9
      I2C address 0x30 (EDID block#)  present: false
      I2C address 0x37 (DDC)          present: false
      I2C address 0x50 (EDID)         present: true 
      /sys/bus/i2c/devices/i2c-9/name: DPDDC-D
   EDID synopsis:
      Mfg id:           BOE
      Model:            Unspecified
      Serial number:    Unspecified
      Manufacture year: 2019
      EDID version:     1.4
      Product code:     2143
      Extra descriptor: Unspecified
      Video input definition: 0xa5 - Digital Input (DisplayPort)
      Supported features:
         Digital display type: RGB 4:4:4
         Standard sRGB color space: False
      White x,y:        0.312, 0.328
      Red   x,y:        0.640, 0.329
      Green x,y:        0.300, 0.600
      Blue  x,y:        0.149, 0.060
      Extension blocks: 0
   EDID source: 
   EDID hex dump:
              +0          +4          +8          +c            0   4   8   c   
      +0000   00 ff ff ff ff ff ff 00 09 e5 5f 08 00 00 00 00   .........._.....
      +0010   01 1d 01 04 a5 22 0a 78 02 de 50 a3 54 4c 99 26   .....".x..P.TL.&
      +0020   0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01   .PT.............
      +0030   01 01 01 01 01 01 a8 6b 00 a0 f0 4c 30 40 30 20   .......k...L0@0 
      +0040   35 00 58 63 10 00 00 1a 22 56 00 a0 f0 4c 30 40   5.Xc...."V...L0@
      +0050   30 20 35 00 58 63 10 00 00 1a 2e 1d 80 a0 70 26   0 5.Xc........p&
      +0060   30 20 30 20 35 00 58 63 10 00 00 1a 5c 17 80 a0   0 0 5.Xc....\...
      +0070   70 26 30 20 30 20 35 00 58 63 10 00 00 1a 00 bb   p&0 0 5.Xc......
   DDC communication failed
   This appears to be a laptop display. Laptop displays do not support DDC/CI.

[RobinVanCauter]

An update on using icc-brightness: after using the clean command, it now controls my main display instead of the ScreenPad Plus. But I still have the flicker. Since you're not experiencing the flicker I suspect it has something to do with GNOME (I'm using PopOS).

With the main display it is even clearer; the flicker is really the panel changing to max brightness for a split second right before it drops to the new requested value. I suspect the display (or gnome) is responding to me pressing the brightness button (but just setting max brightness because it doesn't know better) right before the icc-brightness watch kicks in.

When I have time I will see how it behaves when I use the command line instead of the buttons to confirm my suspicions.

Also, while reading this I think using ICC or xrandr is probably the only existing solution we will be able to use for the main display, as it would be related to the panel being OLED.

There is multiple threads on "why doesn't linux kernel support brightness controls on OLED panels yet" and one of them actually mentions a laptop from System76, shipping with PopOS that has an OLED panel and the brightness control works out of the box on it. We might find some clues there as well.

If I can find out how, I will try and figure out how windows is setting the brightness. But I have not got a lot of experience with WireShark apart from actual network diagnostics and I have trouble finding guides on how to apply it for something else then network readings :)

Edit:

After another reboot and icc brightness is changing the brightness of my bottom screen again.
So it's definitely possible to target the screen with the techniques the tool uses.

Using the cli directly instead of the watch/service causes no flicker, so my assumptions about something else (probably GNOME related) trying to adjust brightness (and failing) when I use the buttons right before icc-brightness does its thing is probably correct.

[s-light]

i had tested the xrandr thing to dim the bottom screen and - yes this works -
but not really:
icc-brightness and also xrandr --brightness *value*

Multiply the gamma values on the crtc currently attached to the output to specified floating value. Useful for overly bright or overly dim outputs. However, this is a software only modification, if your hardware has support to actually change the brightness, you will probably prefer to use xbacklight.

→ you loose color-quality / color-resolution if you dim this way...

and

$ xbacklight -display DP-1-2 -get
RANDR Query Version returned error -1
$ xbacklight -display eDP-1-1 -get
RANDR Query Version returned error -1

also does not work...

and if you dim the bottom screen to 0% and are in a dark place you will see that the background is still brightly shining...
same happens if you 'switch off' the screens with sleep 1s; xset dpms force off
(i have configured this as a shortcut action for Meta + C - is sometimes helpful if my screen is distracting me to much from something else ;-) )

regarding WireShark - i just have looked up - and it is not possible out of the box to capture i2c. :-(
my next idea is to try if the python smbus2 package is working on windows.....
but currently i have no time to test... :-(

[s-light]

just scrolled through the arch-wiki backlight page:

Note: Since OLED screens have no backlight, brightness cannot be controlled by changing backlight power on laptops equipped with an OLED screen. In this case see, perceived screen brightness can only be adjusted via software color correction.

I think this is partly wrong!
it is correct that OLEDs are the light-sources themselves...
and so have no discrete backlight.
but from a controll-point-of-view i think most of the panels have some additonal way to control the overall brightness - i will have to check this again -
but iam very confident in this ;-)

there are reports about pwm-flickering problems with dimmed oled-panels..
(that could be a hint to a panel-wide pwm-dimming..)

[RobinVanCauter]

there are reports about pwm-flickering problems with dimmed oled-panels..
(that could be a hint to a panel-wide pwm-dimming..)

I just noticed your comment in this thread as well on someone who did have luck with PWM based brightness control on their OLED display.

https://www.reddit.com/r/linux/comments/cmf0vi/the_state_of_oled_brightness_on_linux/

I really do hope you are right tho!

For now I'll be going with the xrandr option, at least for the main display, since icc-brightness is rather buggy and the end result is about the same (they both have the color degradation issue as well at low brightness). Found the following script which could be used to hook up the brightness keys to xrandr automatically.

#!/bin/sh

path=/sys/class/backlight/intel_backlight

luminance() {
    read -r level < "$path"/actual_brightness
    factor=$((max))
    new_brightness="$(bc -l <<< "scale = 2; $level / $factor")"
    echo "${new_brightness}"
}

read -r max < "$path"/max_brightness

xrandr --output eDP1 --brightness "$(luminance)"

inotifywait -me modify "$path"/actual_brightness | while read; do
    xrandr --output eDP1 --brightness "$(luminance)"
done

[RobinVanCauter]

i had tested the xrandr thing to dim the bottom screen and - yes this works -

This is already helpful for me to brighten up the bottom screen; seems like it's set to 0.75 by default (at least for me) which is not bright enough in daylight conditions at the office.

While the top screen is at least already consuming less energy using this method (because of how OLED works), the bottom screen will still consume full energy when using xrandr/icc-brightness since it's a LED/LCD display.

It being a LED/LCD display however, means it should be controllable through ACPI just like any other display I think. The problem is the linux kernel doesn't expect two internal displays, so it's not available by default.

I've come across similar issues with another Asus notebook from 2014, the Taichi31. It was slightly different, because it had a second screen on the back, which could be used as a tablet and thus they already had issues with having them both turned on at the same time. But I think the way it was hooked up was very similar: both using eDPI1 for main and DPI1 for second.

https://bugs.freedesktop.org/show_bug.cgi?id=73156
https://bugzilla.kernel.org/show_bug.cgi?id=68631

Which also led me to this:
https://github.com/torvalds/linux/blob/master/drivers/platform/x86/asus-nb-wmi.c

Have you tried enabling that kernel module? Also seems like it contains specific mappers for specific Asus devices and while it's mainly something to make the hotkeys work better, I think there's also more specific brightness control tools in there. at least, going off the following comment in one of those bug reports:

What happens if you change backlight using the asus-nb-wmi interface directly, i.e. sudo sh -c "echo N > /sys/class/backlight/asus-nb-wmi/brightness" where N is a value between 0 and cat /sys/class/backlight/asus-nb-wmi/max_brightness?

As for an alternative to wireshark monitoring:

I might have found something interesting in the following bug report:

If anyone can enable CONFIG_DRM_DP_AUX_CHARDEV=y and dump the DPCD using the
aux chardev (IIRC should pop up somewhere under /sys/class/drm/card0-eDP-1),
it might give some clues.

I'm definitely no expert on these things, but I already came across DP aux channel monitoring before when I was trying to find out how the interface might be potentially used to communicate back-light control, so this looks interesting.

All tho it might not be all to useful, since the goal is probably to record whatever is happening in there when we're actually changing the back-light in windows and this is linux specific. It is part of the kernel tho and some parts of the linux kernel are available in windows, so there's a slim chance we could get something like that setup in there.

[s-light]

wow - that looks promising!

i don't think i have enabled the asus_nb_wmi module... have to check..
i hope i get some time in one or two weeks to test and experiment with this a little more!
thanks for reporting your finds!

[RobinVanCauter]

Just setup the automatic xrandr script, only to find out it also causes flickering. I suspect the hotkeys are actually triggering something somewhere to reset the brightness to 1.

update
So, since you weren't having the issue using KDE and I do using GNOME, I went looking what parts of GNOME also control brightness (it's about 2 or 3 different services).

Sooo instead of disabling parts of those 3 services I thought I might try a GNOME Extension I came across while looking into the issue: OLED Dimmer

And it worked out of the box, without the flickering, which is great.
Interesting to note: it actually adjusts both screens at the same time, I'm going to check out how it works underneath the hood, so I can hopefully adjust it a bit to control both screens separately.

It's not ideal yet for the Screenpad Plus, since I'd rather have the ability to actually control the backlight instead of faking it, but definitely the best quick fix until now when using GNOME.

[s-light]

i currently have the nvidia drivers installed.

graphic: 
	product: NVIDIA TU106M [GeForce RTX 2060 Mobile]
	driver version: 435.21
	product: Intel UHD Graphics 630 (Mobile)
	driver version:

there is a newer version on the nvidia site - currently the ubuntu official ppa is installed..
the open driver did work some sort of - if i remember correctly...
but i think i read that is is slower in some aspects - and i use my system for 3d rendering - so currently need the full performance..
i also did not try to switch cards to save power...

good you have found a working solution!
i think in the issues of the icc-brightness repo there was a request to enable multi-monitor setting...

[RobinVanCauter]

For reference, I came across these, they look interesting for the main display:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831587
https://bugs.launchpad.net/ubuntu/+source/linux-oem/+bug/1844798

Also, I quickly went over the OLED dimmer code, it's a Gnome only approach and it's about 60 lines of javascript. It applies an effect on top of the entire UI so it's not screen specific either. Looking at the xrandr outputs, the effect it applies translates into the brightness values in xrandr being updated as well, causing my "max brightness" on the secondary panel to be 0.85 :(

It does play nicely with the Night Light GNOME provides by default, so I'll keep it until we figure out a decent way to control the backlights.

[moshemalawach]

Just bought the UX481FA, which is a lower end (full hd and not oled) version of the zenbook duo.

What is the recommended way to handle brightness? Normal brightness controls work well for main screen, but do nothing for the keyboard one