screen brightness #1
Comments
|
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! |
|
hello @T-Grave , i have setup icc-brightness just as in the orig. repository readme. i dont see any flickering.. for the bottom screen i have currently no way to dim it. there are some basic information out there:
for me that is what i tried so far: but i had no time to try the fix mentioned for nvidia cards yet.. 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... |
|
I also checked out
So I guess DDC won't be an option 😞 Below the full output of |
|
An update on using 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. 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. |
|
i had tested the xrandr thing to dim the bottom screen and - yes this works -
→ you loose color-quality / color-resolution if you dim this way... and 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... regarding WireShark - i just have looked up - and it is not possible out of the box to capture i2c. :-( |
|
just scrolled through the arch-wiki backlight page:
I think this is partly wrong! there are reports about pwm-flickering problems with dimmed oled-panels.. |
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 |
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 Which also led me to this: 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:
As for an alternative to wireshark monitoring: I might have found something interesting in the following bug report:
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. |
|
wow - that looks promising! i don't think i have enabled the asus_nb_wmi module... have to check.. |
|
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 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. 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. |
|
i currently have the nvidia drivers installed. there is a newer version on the nvidia site - currently the ubuntu official ppa is installed.. good you have found a working solution! |
|
For reference, I came across these, they look interesting for the main display: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1831587 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. |
|
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 |
|
we currently do not have any working solution as far as i know! under windows asus has a custom tool/ui for the second screen brightness. if you find any additional information please let us know! |
|
Until someone figures out how to actually drive the second display's backlight, you can always setup a You could even go as far as setting up keybindings for it. |
|
My issue is that current brightness is quite low currently so I am trying to get it higher (and I removed windows already).
\-------- Message d'origine --------
On 2 mars 2020 à 18:09, Robin Van Cauter < notifications@github.com > a écrit :
Until someone figures out how to actually drive the second display's backlight, you can always setup a `xrandr` cli script to fake the brightness down. This does cause washed out colors at lower values and still uses the exact same amount of power as full brightness for all values. But it does help a bit for the eyes at night :)
You could even go as far as setting up keybindings for it.
—
You are receiving this because you commented.
Reply to this email directly, [view it on GitHub][], or [unsubscribe][].![AJXOYWYIZOSJEBS35WWUFZ3RFPR5HA5CNFSM4JXPVL52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQD6PA.gif][]
[view it on GitHub]: #1?email_source=notifications&email_token=AJXOYWZEXZ2WYILT4KBUFP3RFPR5HA5CNFSM4JXPVL52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQD6PA#issuecomment-593510204
[unsubscribe]: https://github.com/notifications/unsubscribe-auth/AJXOYW7KZJGPVCESSZ3N6E3RFPR5HANCNFSM4JXPVL5Q
[AJXOYWYIZOSJEBS35WWUFZ3RFPR5HA5CNFSM4JXPVL52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQD6PA.gif]: https://github.com/notifications/beacon/AJXOYWYIZOSJEBS35WWUFZ3RFPR5HA5CNFSM4JXPVL52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQD6PA.gif
|
|
@moshemalawach I had the same issue, the default screen brightness was set to 0.75 for the second screen. Setting it to 1 (using |
|
Issue is base brightness of second display is low on my computer and I don't have windows installed anymore to bring it higher :/ |
|
It's already at 1 |
|
I've been able to get my screen brightness on both screens to work for me. I've created a new repository with my code so feel free to check it out and use it: My solution takes care of the issue that the bottom display is dimmer than the top display. I was able to get the 2 displays to be pretty much the same brightness I haven't done any testing on any other systems, only mine: Also, here is a demo video of it working on my system: |
|
@rayperea Thanks for sharing! Does it work well with Night Light enabled inside Gnome? |
|
@T-Grave Good news though... getting it work work with Night Light should be easy peasy. We just have to take the current Night Light setting into consideration when setting the brightness using xrandr. When I get a minute or two, I'll update the repo... or, if someone wants to write the code, pull requests are welcome |
|
Hi there, I bought the 14 inch model (UX481) last week and while those two are fairly different (for instance my main screen is LCD, not OLED, and brightness control for the main screen worked out of the box) the problem with the brightness of the lower screen is quite similar: under Linux, it was stuck at around 50% brightness and I couldn't control it (or turn it off). So I did some digging through the DSTS code and also watched the behavior of the ASUS Windows software and finally found a way to control the bottom screen brightness in Linux. Using it is quite hack-ish at the moment (it will have to be built into the kernel to work nicely), but it's usable and I think there is a good chance that it also works at the UX581 – I don't see why ASUS should use a different method as the driver software used in Windows is identical for both models. So, here is how I managed to control bottom screen brightness on my device (use at your own risk):
I added the acpi_call module to my I hope it also works for you! |
|
Wow!! for the integration: could this be something to go into the |
|
Works perfectly on my UX481, thank you very much, that's exactly what I was searching for :)
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
…On Friday 22 May 2020 20:21, Plippo ***@***.***> wrote:
Hi there,
I bought the 14 inch model (UX481) last week and while those two are fairly different (for instance my main screen is LCD, not OLED, and brightness control for the main screen worked out of the box) the problem with the brightness of the lower screen is quite similar: under Linux, it was stuck at around 50% brightness and I couldn't control it (or turn it off). So I did some digging through the DSTS code and also watched the behavior of the ASUS Windows software and finally found a way to control the bottom screen brightness in Linux. Using it is quite hack-ish at the moment (it will have to be built into the kernel to work nicely), but it's usable and I think there is a good chance that it also works at the UX581 – I don't see why ASUS should use a different method as the driver software used in Windows is identical for both models.
So, here is how I managed to control bottom screen brightness on my device (use at your own risk):
- install the acpi_call kernel module using the package from your distribution. In Debian, Ubuntu etc. the package is called `acpi-call-dkms`
- load the module using `sudo modprobe acpi_call`
- use the following commands to control the bottom screen (they all have to be executed as root - instead of using sudo, you can of course also use a root shell):
- Change Brightness of the screen:
`echo '\_SB.ATKD.WMNB 0x0 0x53564544 b32000500xx000000' | sudo tee /proc/acpi/call`
where xx is a value between 00 and FF (00 being darkest, FF brightest, 77 in between etc.)
So for maximum brightness, use:
`echo '\_SB.ATKD.WMNB 0x0 0x53564544 b32000500FF000000' | sudo tee /proc/acpi/call`
- Turn off the screen:
`echo '\_SB.ATKD.WMNB 0x0 0x53564544 b3100050000000000' | sudo tee /proc/acpi/call`
- To turn the screen back on again, just send a brightness command.
I added the acpi_call module to my `/etc/modules` file so it is loaded at system startup and added the following line to `/etc/rc.local` in order to turn the screen to full brightness at system start:
`echo '\_SB.ATKD.WMNB 0x0 0x53564544 b32000500FF000000' > /proc/acpi/call`
I hope it also works for you!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.[https://github.com/notifications/beacon/AJXOYW3QTR25BZDVC746WFLRS27C5A5CNFSM4JXPVL52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEW4FXEA.gif]
|
I suppose that's the best place, but I didn't have time yet to look into where exactly to put it... as userspace most likely isn't prepared for having two backlight devices, it'll probably have to be as an LED device or something like that. |
|
just checked - it works for me :-) |
|
I've added support for brightness control to the asus-wmi kernel module. To test it, you can build and load the module using DKMS. I've described the process here: https://github.com/Plippo/asus-wmi-screenpad/blob/master/README.md |
|
looks great!! just a side note: out of interesst: could you describe a bit more in detail what you have done to find these calls?! |
|
my curiosity was to big - so i tried it direclt - but it failed during compile time: stefan@stefan-Zen:~/mydata/github$ git clone https://github.com/Plippo/asus-wmi-screenpad.git
Cloning into 'asus-wmi-screenpad'...
remote: Enumerating objects: 32, done.
remote: Counting objects: 100% (32/32), done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 32 (delta 11), reused 17 (delta 3), pack-reused 0
Unpacking objects: 100% (32/32), done.
stefan@stefan-Zen:~/mydata/github$ sudo ln -sf ~/mydata/github/asus-wmi-screenpad/ /usr/src/asus-wmi-1.0
stefan@stefan-Zen:~/mydata/github$ ll /usr/src/asus*
lrwxrwxrwx 1 root root 46 2020-05-24 23:20:06.270 /usr/src/asus-wmi-1.0 -> /home/stefan/mydata/github/asus-wmi-screenpad//
stefan@stefan-Zen:~/mydata/github$ sudo lsudo dkms add -m asus-wmi -v 1.0
Creating symlink /var/lib/dkms/asus-wmi/1.0/source ->
/usr/src/asus-wmi-1.0
DKMS: add completed.
stefan@stefan-Zen:~/mydata/github$ sudo dkms build -m asus-wmi -v 1.0
Kernel preparation unnecessary for this kernel. Skipping...
Building module:
cleaning build area...
make -j16 KERNELRELEASE=5.3.0-55-generic -C /lib/modules/5.3.0-55-generic/build M=/var/lib/dkms/asus-wmi/1.0/build...(bad exit status: 2)
ERROR (dkms apport): binary package for asus-wmi: 1.0 not found
Error! Bad return status for module build on kernel: 5.3.0-55-generic (x86_64)
Consult /var/lib/dkms/asus-wmi/1.0/build/make.log for more information.
stefan@stefan-Zen:~/mydata/github$ cat /var/lib/dkms/asus-wmi/1.0/build/make.log
DKMS make.log for asus-wmi-1.0 for kernel 5.3.0-55-generic (x86_64)
So 24. Mai 23:20:52 CEST 2020
make: Entering directory '/usr/src/linux-headers-5.3.0-55-generic'
CC [M] /var/lib/dkms/asus-wmi/1.0/build/asus-wmi.o
CC [M] /var/lib/dkms/asus-wmi/1.0/build/asus-nb-wmi.o
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c: In function ‘charge_control_end_threshold_store’:
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c:398:30: error: ‘ASUS_WMI_DEVID_RSOC’ undeclared (first use in this function); did you mean ‘ASUS_WMI_DEVID_UWB’?
398 | ret = asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, value, &rv);
| ^~~~~~~~~~~~~~~~~~~
| ASUS_WMI_DEVID_UWB
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c:398:30: note: each undeclared identifier is reported only once for each function it appears in
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c: In function ‘asus_wmi_battery_add’:
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c:437:24: error: ‘ASUS_WMI_DEVID_RSOC’ undeclared (first use in this function); did you mean ‘ASUS_WMI_DEVID_UWB’?
437 | asus_wmi_set_devstate(ASUS_WMI_DEVID_RSOC, 100, NULL);
| ^~~~~~~~~~~~~~~~~~~
| ASUS_WMI_DEVID_UWB
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c: In function ‘asus_wmi_battery_init’:
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c:459:36: error: ‘ASUS_WMI_DEVID_RSOC’ undeclared (first use in this function); did you mean ‘ASUS_WMI_DEVID_UWB’?
459 | if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_RSOC)) {
| ^~~~~~~~~~~~~~~~~~~
| ASUS_WMI_DEVID_UWB
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c: In function ‘asus_fan_set_auto’:
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c:1387:34: error: ‘ASUS_WMI_DEVID_CPU_FAN_CTRL’ undeclared (first use in this function); did you mean ‘ASUS_WMI_DEVID_FAN_CTRL’?
1387 | status = asus_wmi_set_devstate(ASUS_WMI_DEVID_CPU_FAN_CTRL,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| ASUS_WMI_DEVID_FAN_CTRL
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c: In function ‘fan1_input_show’:
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c:1479:37: error: ‘ASUS_WMI_DEVID_CPU_FAN_CTRL’ undeclared (first use in this function); did you mean ‘ASUS_WMI_DEVID_FAN_CTRL’?
1479 | ret = asus_wmi_get_devstate(asus, ASUS_WMI_DEVID_CPU_FAN_CTRL,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| ASUS_WMI_DEVID_FAN_CTRL
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c: In function ‘pwm1_enable_store’:
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c:1551:31: error: ‘ASUS_WMI_DEVID_CPU_FAN_CTRL’ undeclared (first use in this function); did you mean ‘ASUS_WMI_DEVID_FAN_CTRL’?
1551 | ret = asus_wmi_set_devstate(ASUS_WMI_DEVID_CPU_FAN_CTRL,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| ASUS_WMI_DEVID_FAN_CTRL
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c: In function ‘asus_wmi_fan_init’:
/var/lib/dkms/asus-wmi/1.0/build/asus-wmi.c:1681:36: error: ‘ASUS_WMI_DEVID_CPU_FAN_CTRL’ undeclared (first use in this function); did you mean ‘ASUS_WMI_DEVID_FAN_CTRL’?
1681 | if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_CPU_FAN_CTRL))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
| ASUS_WMI_DEVID_FAN_CTRL
make[1]: *** [scripts/Makefile.build:288: /var/lib/dkms/asus-wmi/1.0/build/asus-wmi.o] Error 1
make: *** [Makefile:1656: _module_/var/lib/dkms/asus-wmi/1.0/build] Error 2
make: Leaving directory '/usr/src/linux-headers-5.3.0-55-generic'
stefan@stefan-Zen:~/mydata/github$did not dig deeper for now... maybe you have an idea what i have missed... |
|
Oh the problem is probably that I based the module on kernel 5.4 and it is using some symbols that aren't there yet in 5.3. I'll try to create a version for 5.3 tomorrow. |
|
Could it provide a backlight class interface too?
Envoyé depuis ProtonMail mobile
|
|
@Plippo thanks - but don't invest to much time into 5.3 ... |
No worries, didn't have to invest much - I created a branch for 5.3 which you find here: https://github.com/Plippo/asus-wmi-screenpad/tree/5.3 |
I plan on trying that too, but I don't have much hope that it'll work well. We'll see... |
Basically what I did is the following:
Well, that's all. I hope this helps you find out more about your main screen backlight! |
I tried it out, but as I feared, userspace doesn't go along well with having two backlight devices. At least Gnome can only control one, and I don't think you can pick which - I was no longer able to control the main screen using the backlight keys, only the screenpad. If you want you can try it out, I added a "backlight" branch to my repository. Just remove the module using `sudo dkms remove asus-wmi/1.0 --all', remove the /usr/src/asus-wmi-1.0 folder and then follow the instructions from the backlight branch |
I will open a bug about it in gnome shell, we need to fix this upstream :) In the meantime we can make a gnome extension to support it correctly. |
|
Cross referencing issue in gnome shell: |
|
Thanks for creating that issue! |
|
@Plippo thanks for your detailed description!! i can not test the 5.3 branch anymore - today i tested your backlight branch - i searched a bit regarding multi-screen-brightness control -
|
|
tested your script today :-) |
|
Tested the bottom screen backlight adjustment on my machine as well UX581GV Ubuntu 20.04. Works great. Thank you for figuring it out. |
|
Great discovery @Plippo . Working perfectly. Thank you for your efforts. I am planning to make some UI tool for screenpad similar to windows for adjusting brightness and managing app windows in efficient manner. Any suggestions on what stack should be used ? I am thinking to do it with electron. Also, should it be integrated with any desktop environment like KDE or GNOME or independent programme ? |
|
i understand your idea to use electron as it is a nice environment to work with... for KDE you don't need any fancy tools for the window screen management i thinkg - for the brightness i hope that i find some time in the next weeks to test and read some deeper what it needs to include the second screen into the normal brightness-management. |
|
In Gnome there's a component called gnome-settings-daemon that is responsible for things like backlight control. I've already looked into it and unfortunately it is not at all prepared for handling multiple backlight devices, so probably needs to be changed quite a bit. I suppose there's a similar component in KDE. Unfortunately, I don't have much time at the moment to work on this. |
|
For KDE I came up with a script to do the brightness control. Thought I'd post it here for anyone that might find such a thing useful. I bound the brightness up/down keys to execute step.sh#!/bin/sh
# Check whether the steps parameter is entered
STEPS=$1
if [ -z $STEPS ]; then
echo "Usage: step.sh <nsteps>"
exit 1
fi
# Gets the brightness, max brightness and brightness steps setting from KDE
BRIGHTNESS=$(qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/Actions/BrightnessControl org.kde.Solid.PowerManagement.Actions.BrightnessControl.brightness)
MAX_BRIGHTNESS=$(qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/Actions/BrightnessControl org.kde.Solid.PowerManagement.Actions.BrightnessControl.brightnessMax)
BRIGHTNESS_STEPS=$(qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/Actions/BrightnessControl org.kde.Solid.PowerManagement.Actions.BrightnessControl.brightnessSteps)
BRIGHTNESS_STEP_SIZE=$(($MAX_BRIGHTNESS / $BRIGHTNESS_STEPS))
# Check whether the KDE parameters could be retrieved
if [ -z $BRIGHTNESS ] || [ -z $MAX_BRIGHTNESS ] || [ -z $BRIGHTNESS_STEP_SIZE ]; then
echo "Missing a parameter from KDE"
exit 1
fi
# Calculate new brightness after applying x steps
BRIGHTNESS=$(($BRIGHTNESS + $STEPS * $BRIGHTNESS_STEP_SIZE))
if [ 0 -gt $BRIGHTNESS ]; then
BRIGHTNESS=0
elif [ $BRIGHTNESS -gt $MAX_BRIGHTNESS ]; then
BRIGHTNESS=$MAX_BRIGHTNESS
fi
echo "Setting brightness through a step to $BRIGHTNESS"
# Set the KDE brightness value
qdbus org.kde.Solid.PowerManagement /org/kde/Solid/PowerManagement/Actions/BrightnessControl org.kde.Solid.PowerManagement.Actions.BrightnessControl.setBrightness $BRIGHTNESS
# Calculate the brightness as a percentage
PERC=$(echo "scale=2;$BRIGHTNESS / $MAX_BRIGHTNESS" | bc)
echo "Setting brightness to $BRIGHTNESS/$MAX_BRIGHTNESS: $PERC"
# Set the brightness of both laptop screens
xrandr --output "DP-2" --brightness $PERC
xrandr --output "eDP-1" --brightness $PERC |
|
@chrislemaire Your script is using software based approach. Try hardware based approach provided by @Plippo and you will notice how much quality difference it makes. |
|
@s-light I appreciate your views and agree on electron is too heavy for such a simple use case. I am using script provided by @Plippo : https://github.com/Plippo/screenpad-tools and it works quite perfectly well to satisfy the need with keyboard shortcuts. So I have dropped idea of making dedicated UI. Thank you once again for your efforts @Plippo . |
The script ux581_brightness.sh reads the currently requested brightness and the maximum brightness and generates a percent representation. There is a min/max percent brightness for both the OLED and Screenpad displays and the percentage is scaled accordingly. The Screenpad brightness is then scaled to 0-255 (0x00-0xFF) for the /proc/acpi/call request that Plippo documented in s-light#1 The path and service files have been included for SystemD to set up inotifywatch on the brightness file and an INSTALL text file has been included to show where to place the files and what to run to enable them on startup.
The script ux581_brightness.sh reads the currently requested brightness and the maximum brightness and generates a percent representation. There is a min/max percent brightness for both the OLED and Screenpad displays and the percentage is scaled accordingly. The Screenpad brightness is then scaled to 0-255 (0x00-0xFF) for the /proc/acpi/call request that Plippo documented in s-light#1 The path and service files have been included for SystemD to set up inotifywatch on the brightness file and an INSTALL text file has been included to show where to place the files and what to run to enable them on startup.
|
@Plippo #!/bin/bash
set -euxo pipefail
BASE_DIR="$(dirname -- "$(readlink -f -- "$0")")"
BRIGHTNESS="${1?no brightness, 00..FF}"
if [[ ! "$BRIGHTNESS" =~ ^[0-9A-F]{2}$ ]]; then
echo "$0: fatal: brightness must be a hexadecimal two-digit number" >&2
exit 1
fi
bash "$BASE_DIR"/ensure-acpi-call.sh
echo "\\_SB.ATKD.WMNB 0x0 0x53564544 b32000500${BRIGHTNESS}000000" \
| sudo tee /proc/acpi/callSince it's now three years since the original discussion, I don't want bother @Plippo or anybody else here, but could anybody please tell, how should I read the current brightness value from |
research how screenbrightness is handled by windows..
then implement for linux.
The text was updated successfully, but these errors were encountered: