Distribution (run cat /etc/os-release):
NAME="Ubuntu"
VERSION="18.04.1 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.1 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Related Application and/or Package Version (run apt policy $PACKAGE NAME):
system76-driver:
Installed: 18.04.27153368034318.04e74d1c2dev
Candidate: 18.04.27153368034318.04e74d1c2dev
Version table:
*** 18.04.27153368034318.04e74d1c2dev 500
500 http://ppa.launchpad.net/system76-dev/stable/ubuntu bionic/main amd64 Packages
500 http://ppa.launchpad.net/system76-dev/stable/ubuntu bionic/main i386 Packages
100 /var/lib/dpkg/status
But I have installed Pop-OS, just to test this, and it repros exactly the same. I normally run with gnome-session, but I have tried without and that also does not help.
Issue/Bug Description:
On Oryx4-b (only) the System76 driver adjusts a mode byte (function apply_dpcd_pwm_fix in daemon.py). It does this repeatedly, in case it resets itself.
But this driver stops trying to do this after 60 seconds. After that, if the mode resets the backlight goes to max brightness, and all brightness controls (except xrandr --brightness, oddly) cease to have any effect.
There are many things that can cause this mode to reset.
Steps to reproduce (if you know):
You need to wait at least 60 seconds after logging in before attempting to repro this.
After that, you can put the computer to sleep and awaken it, and that will usually trigger this. Changing screen resolutions can also trigger it, but I find it sometimes takes several tries for this to work.
The Linux port of Doom 3 (package dhewm3) triggers this issue for more almost every time I start it; I note that I play this game at a lower-than-native-resolution due to the game's aspect ratio issue. Also note that the game actually has to start, so you do need the Doom 3 data files installed to repro this way. But if you can play Doom 3 like this, it's the most reliable repro. Even this is not 100% guaranteed.
Expected behavior:
Ideally, the Oryx4 should not go to max brightness unless commanded by the user, and the brightness controls should all always affect the screen brightness.
Looking at the code, my expectations are a bit lower- events that trigger this problem will cause the laptop to go to max brightness for at most 3 seconds, then resume normal function. Brightness controls should work again after normal service is resumed.
Other Notes:
I've been working with System76 support on this issue.
You can restore proper backlight function temporarily by restarting the System76 driver, via 'systemctl restart system76-driver.service'. After 60 seconds, you will again be able repro.
I found a workaround for this; the relevant code for this is installed at /usr/lib/python3/dist-packages/system76driver/daemon.py. Edit this file and find line 627, which is "if nhash != chash:"; change this to "if True:" instead (preserve the indentation though, because Python). This defeats the check on the login.sessions (whatever they are) and keeps restarting the 60-second loop forever.
Now, if the mode ever changes, it will be reset within 3 seconds or so. Of course, this is terribly poll-tastic, and will waste a tiny bit of CPU while it keeps Python 3 resident in memory forever. This is still much better than a busted backlight.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent