Linux: Screen blanking using xset no longer working on new kernel 4.14.30-v7+
I've been using the following for providing a basic screen blanking function:
xset -display :0 dpms force [on/off]
This has worked fantastically good, until the last kernel update.
Now nothing happen, except for an extremely brief screen flash.
There are no errors anywhere...
- Any ideas what has changed?
- Any idea how to replace this function?
E3V3A
All 18 comments
Are you sure just the kernel change provoked this behaviour? (and not other packages being updated)
Can you report the last kernel that was working as desired?
popcornmix
on 19 Apr 2018
No, not sure, since I don't know what own that file.
It was working all along until after update. I.e. Working kernel was 4.9.80.
Start-Date: 2018-04-16 09:18:49
Commandline: apt-get upgrade
Requested-By: pi (1000)
base-files:armhf (9.9+rpi1+deb9u3, 9.9+rpi1+deb9u4)
curl:armhf (7.52.1-5+deb9u4, 7.52.1-5+deb9u5)
fonts-piboto:armhf (1.0, 1.2)
libcurl3:armhf (7.52.1-5+deb9u4, 7.52.1-5+deb9u5)
libcurl3-gnutls:armhf (7.52.1-5+deb9u4, 7.52.1-5+deb9u5)
libicu57:armhf (57.1-6+deb9u1, 57.1-6+deb9u2)
libperl5.24:armhf (5.24.1-3+deb9u2, 5.24.1-3+deb9u3)
libraspberrypi0:armhf (1.20180313-1, 1.20180328-1)
libraspberrypi-bin:armhf (1.20180313-1, 1.20180328-1)
libraspberrypi-dev:armhf (1.20180313-1, 1.20180328-1)
libraspberrypi-doc:armhf (1.20180313-1, 1.20180328-1)
libsmbclient:armhf (2:4.5.12+dfsg-2+deb9u1, 2:4.5.12+dfsg-2+deb9u2)
libssl1.0.2:armhf (1.0.2l-2+deb9u2, 1.0.2l-2+deb9u3)
libvorbis0a:armhf (1.3.5-4+deb9u1, 1.3.5-4+deb9u2)
libvorbisenc2:armhf (1.3.5-4+deb9u1, 1.3.5-4+deb9u2)
libvorbisfile3:armhf (1.3.5-4+deb9u1, 1.3.5-4+deb9u2)
libwbclient0:armhf (2:4.5.12+dfsg-2+deb9u1, 2:4.5.12+dfsg-2+deb9u2)
linux-libc-dev:armhf (4.9.51-1+rpi3, 4.9.82-1+deb9u3+rpi1)
lxinput:armhf (0.3.5-1+rpi2, 0.3.5-1+rpi3)
openssl:armhf (1.1.0f-3+deb9u1, 1.1.0f-3+deb9u2)
perl:armhf (5.24.1-3+deb9u2, 5.24.1-3+deb9u3)
perl-base:armhf (5.24.1-3+deb9u2, 5.24.1-3+deb9u3)
perl-modules-5.24:armhf (5.24.1-3+deb9u2, 5.24.1-3+deb9u3)
python3-automationhat:armhf (0.0.4, 0.1.0)
python3-envirophat:armhf (0.0.6, 1.0.0)
python3-microdotphat:armhf (0.1.3, 0.2.1)
python3-scrollphathd:armhf (1.2.0, 1.2.1)
python-automationhat:armhf (0.0.4, 0.1.0)
python-envirophat:armhf (0.0.6, 1.0.0)
python-microdotphat:armhf (0.1.3, 0.2.1)
python-scrollphathd:armhf (1.2.0, 1.2.1)
raspberrypi-bootloader:armhf (1.20180313-1, 1.20180328-1)
raspberrypi-kernel:armhf (1.20180313-1, 1.20180328-1)
raspberrypi-sys-mods:armhf (20180312, 20180328+1)
raspi-config:armhf (20180228, 20180406+1)
rc-gui:armhf (1.15, 1.16)
rpd-icons:armhf (0.14, 0.15)
rpi-chromium-mods:armhf (20180302, 20180409)
samba-common:armhf (2:4.5.12+dfsg-2+deb9u1, 2:4.5.12+dfsg-2+deb9u2)
samba-libs:armhf (2:4.5.12+dfsg-2+deb9u1, 2:4.5.12+dfsg-2+deb9u2)
End-Date: 2018-04-16 09:27:44
Actually its installed by:
x11-xserver-utils: /usr/bin/xset
So there must be some 2nd hand dependencies that have changed something.
Any idea how to check?
E3V3A
on 19 Apr 2018
Last line, seem to indicate that the monitor is off, but this is not true.
# xset -display :0 -q
Keyboard Control:
auto repeat: on key click percent: 0 LED mask: 00000000
XKB indicators:
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
03: Compose: off 04: Kana: off 05: Sleep: off
06: Suspend: off 07: Mute: off 08: Misc: off
09: Mail: off 10: Charging: off 11: Shift Lock: off
12: Group 2: off 13: Mouse Keys: off
auto repeat delay: 500 repeat rate: 33
auto repeating keys: 00ffffffdffffbbf
fadfffefffedffff
9fffffffffffffff
fff7ffffffffffff
bell percent: 50 bell pitch: 400 bell duration: 100
Pointer Control:
acceleration: 20/10 threshold: 10
Screen Saver:
prefer blanking: yes allow exposures: yes
timeout: 600 cycle: 600
Colors:
default colormap: 0x20 BlackPixel: 0x0 WhitePixel: 0xffffff
Font Path:
/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,built-ins
DPMS (Energy Star):
Standby: 0 Suspend: 0 Off: 0
DPMS is Enabled
Monitor is Off
There are also some X issues in the logs:
[ 11.156] (WW) The directory "/usr/share/fonts/X11/misc" does not exist.
[ 11.156] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 11.158] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[ 11.160] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[ 11.356] (WW) Falling back to old probe method for fbturbo
[ 11.365] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 11.536] (II) AIGLX: Screen 0 is not DRI2 capable
[ 11.536] (EE) AIGLX: reverting to software rendering
Hard to debug this one. Just some findings:
# sudo dpkg --list |grep x11
ii dbus-x11 1.10.26-0+deb9u1 armhf simple interprocess messaging system (X11 deps)
ii gsfonts-x11 0.24 all Make Ghostscript fonts available to X11
ii libqt5x11extras5:armhf 5.7.1~20161021-2 armhf Qt 5 X11 extras
ii libva-x11-1:armhf 1.7.3-2 armhf Video Acceleration (VA) API for Linux -- X11 runtime
ii libx11-6:armhf 2:1.6.4-3 armhf X11 client-side library
ii libx11-data 2:1.6.4-3 all X11 client-side library
ii libx11-xcb1:armhf 2:1.6.4-3 armhf Xlib/XCB interface library
ii libxkbcommon-x11-0:armhf 0.7.1-2~deb9u1 armhf library to create keymaps with the XKB X11 protocol
ii x11-common 1:7.7+19 all X Window System (X.Org) infrastructure
ii x11-utils 7.7+3 armhf X11 utilities
ii x11-xkb-utils 7.7+3 armhf X11 XKB utilities
ii x11-xserver-utils 7.7+7 armhf X server utilities
However, the x11-common service has been masked. (Unmasking it doesn't work!)
# systemctl status x11-common.service
● x11-common.service
Loaded: masked (/dev/null; bad)
Active: inactive (dead)
In addition, there is some weird interference between these:
sudo tvservice -o
sudo tvservice -p
xset -display :0 dpms force on
Before I could use them independently. Now I need to mix them to get immediate result, and the logic is reversed. For example, if I want to blank the screen and then turn it back on, I have to do this:
sudo tvservice -o # to turn off HDMI
sudo tvservice -p # to turn on HDMI, but remains blank (didn't happen before)
xset -display :0 dpms force off # to turn off DPMS, but actually turns screen back on (used to do the opposite)
Finally solved this funky bug! However, it is still unknown what package update caused it.
There are (at least) two files that are setting some x related color schemes:
# cat /home/pi/.config/lxsession/LXDE-pi/desktop.conf |grep ColorScheme
sGtk/ColorScheme=selected_bg_color:#4d4d9898f5f5\nselected_fg_color:#ffffffffffff\nbar_bg_color:#ededececebeb\nbar_fg_color:#000000000000\n
# cat /usr/share/themes/PiX/gtk-2.0/gtkrc |grep color-scheme
gtk-color-scheme = "base_color:#FFFFFF\nfg_color:#2E3436\nbg_color:#EDEDED\ntext_color:#313739\nselected_fg_color:#FFFFFF\nselected_bg_color:#4D98F5\ninsensitive_bg_color:#F4F4F2\ntooltip_fg_color:#FFFFFF\ntooltip_bg_color:#A0A0A0"
The following procedure, will (at least temporarily) restore the xset functionality.
xset -display :0 s noblank # Screen Saver: prefer blanking: no allow exposures: yes
xset -display :0 s off # DPMS (Energy Star): Standby: 0 Suspend: 0 Off: 0
xset -display :0 -dpms # DPMS (Energy Star): DPMS is Disabled
xset -display :0 s 0 0 # Screen Saver: timeout: 0 cycle: 0
xset -display :0 dpms 0 0 0 # DPMS (Energy Star): DPMS is Enabled Monitor is On
xset -display :0 dpms force off # Now screen saver is on, but screen is a fine checkered gray pattern
xset -display :0 dpms force on # Now screen saver is off, i.e. back to normal screen.
- What is the background for screen saver?
Who knows, but use:
xsetroot -display :0 -solid Black
Now you can use xset as in OP again!
When this is done, the correct output of xset -q should be:
# xset -q -display :0
Keyboard Control:
auto repeat: on key click percent: 0 LED mask: 00000000
XKB indicators:
00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off
03: Compose: off 04: Kana: off 05: Sleep: off
06: Suspend: off 07: Mute: off 08: Misc: off
09: Mail: off 10: Charging: off 11: Shift Lock: off
12: Group 2: off 13: Mouse Keys: off
auto repeat delay: 500 repeat rate: 33
auto repeating keys: 00ffffffdffffbbf
fadfffefffedffff
9fffffffffffffff
fff7ffffffffffff
bell percent: 50 bell pitch: 400 bell duration: 100
Pointer Control:
acceleration: 20/10 threshold: 10
Screen Saver:
prefer blanking: no allow exposures: yes
timeout: 0 cycle: 0
Colors:
default colormap: 0x20 BlackPixel: 0x0 WhitePixel: 0xffffff
Font Path:
/usr/share/fonts/X11/100dpi/:unscaled,/usr/share/fonts/X11/Type1,/usr/share/fonts/X11/100dpi,built-ins
DPMS (Energy Star):
Standby: 0 Suspend: 0 Off: 0
DPMS is Enabled
Monitor is On
Thanks for update.
Looks like a distribution rather than kernel issue.
Ping @XECDesign @spl237 who may have ideas why this behaviour changed.
popcornmix
on 5 May 2018
@popcornmix
Thanks for update.
My pleasure! :)
To all or anyone:
However, having looked briefly and searched heavily on and about all the available x related screen settings files and config files and what else have you, it is extremely confusing to know what goes where.
I've counted at least ~10 different config files that may or may not influence the way the screen settings and screen savers are are used, and its nearly impossible to tell what order they are used, if at all, and what precedence these take.
In this regard, I would like to know which one file we can use to set custom screen settings?
In addition and hopefully that file will:
(a) not be over written after reboot and
(b) not over written after updates.
E3V3A
on 6 May 2018
There are (at least) two files that are setting some x related color schemes:
cat /home/pi/.config/lxsession/LXDE-pi/desktop.conf |grep ColorScheme
sGtk/ColorScheme=selected_bg_color:#4d4d9898f5f5\nselected_fg_color:#ffffffffffff\nbar_bg_color:#ededececebeb\nbar_fg_color:#000000000000\n
cat /usr/share/themes/PiX/gtk-2.0/gtkrc |grep color-scheme
gtk-color-scheme = "base_color:#FFFFFF\nfg_color:#2E3436\nbg_color:#EDEDED\ntext_color:#313739\nselected_fg_color:#FFFFFF\nselected_bg_color:#4D98F5\ninsensitive_bg_color:#F4F4F2\ntooltip_fg_color:#FFFFFF\ntooltip_bg_color:#A0A0A0"
For reference, neither of those files are setting anything to do with X - they are setting the colour scheme which is applied to applications written with the GTK toolkit. The values in the lxsession file override the defaults in the GTK theme file. This gets massively complicated, because applications written in version 2 of GTK use different theming and colour information from apps written in version 3 of GTK, and then any apps which don't use GTK at all need colour theming information written in yet more places.
Unfortunately, the idea of a single file where this can be set is impossible in the environment as it stands, which is why one of the first things I did was to write the pipanel (Appearance Settings) application to enable a setting to be made in a single place by the user and to have all the relevant files update as a result.
spl237
on 7 May 2018
Unfortunately, the idea of a single file where this can be set is impossible in the environment as it stands, which is why one of the first things I did was to write the pipanel (Appearance Settings) application to enable a setting to be made in a single place by the user and to have all the relevant files update as a result.
OMG! I can only imagine. Sound like a mega project. :1st_place_medal:
Which file is that?
$ pipanel --help
I/O warning : failed to load external entity "/home/pi/.config/libreoffice/4/user/registrymodifications.xcu"
(pipanel:24256): Gtk-WARNING **: cannot open display:
$ man pipanel
No manual entry for pipanel
See 'man 7 undocumented' for help when manual pages are not available.
I uninstalled libreoffice long time ago, so I have no idea why pipanel would have anything to do with that...
Currently after reboot, I always have to do this:
xset -display :0 s noblank
xset -display :0 s off
xset -display :0 s 0 0
xset -display :0 dpms 0 0 0
xsetroot -display :0 -solid Black
- Where is the
correctbest place to put these lines?
E3V3A
on 8 May 2018
pipanel is an application, not a file - it is what is launched if you select Preferences->Appearance Settings from the main menu, or Desktop Preferences when right-clicking the desktop. It manages changes to all relevant config files when a setting is changed in the GUI.
The error message you see is because one of the places it needs to make changes is in a libreoffice configuration file - if LO is not installed, then it doesn't matter if it can't change the file, as the setting in question (toolbar icon size, IIRC) then isn't required.
spl237
on 8 May 2018
@spl237 Thanks Simon, I appreciate your feedback.
pipanel is an application, not a file
I know, but I meant the config file that it is using. The one you mentioned above. So that I can remove the LO reference, for example.
E3V3A
on 8 May 2018
It doesn't use a single config file - the whole point of pipanel is that it accesses multiple config files and makes changes to them all. There is no config file for pipanel itself; it reads the current configuration from the existing configuration files and writes back to them. Creating yet another config file would only make the problem worse...
spl237
on 8 May 2018
Ha ha ha! Now I got it. Thanks again for explaining.
E3V3A
on 8 May 2018
@spl237
I manged to get the xset options sorted out, but I still have not found the right place for the xsetroot -display :0 -solid black. However, and interestingly, I found this error:
# sudo cat /var/log/lightdm/seat0-greeter.log
/usr/share/themes/PiX/gtk-2.0/gtkrc:1072: Invalid symbolic color 'bar_bg_color'
/usr/share/themes/PiX/gtk-2.0/gtkrc:1072: error: invalid identifier 'bar_bg_color', expected valid identifier
...
Looking in that file we find:
# mygrep "bar_bg_color" /usr/share/themes/PiX/gtk-2.0/gtkrc
/usr/share/themes/PiX/gtk-2.0/gtkrc:1072: bg[NORMAL] = shade (1.04, @bar_bg_color)
/usr/share/themes/PiX/gtk-2.0/gtkrc:1073: bg[ACTIVE] = shade (0.85, @bar_bg_color)
/usr/share/themes/PiX/gtk-2.0/gtkrc:1083: bg[NORMAL] = @bar_bg_color
The only other place this is referenced, is in:
/etc/xdg/lxsession/LXDE-pi/desktop.conf:27:sGtk/ColorScheme=selected_bg_color:#4d4d9898f5f5\nselected_fg_color:#ffffffffffff\nbar_bg_color:#ededececebeb\nbar_fg_color:#000000000000\n
/home/pi/.config/lxsession/LXDE-pi/desktop.conf:27:sGtk/ColorScheme=selected_bg_color:#4d4d9898f5f5\nselected_fg_color:#ffffffffffff\nbar_bg_color:#ededececebeb\nbar_fg_color:#000000000000\n
OK, that's not really surprising...
bar_bg_color is the colour used for the background of the taskbar. The gtk theme which refers to it is 99% of the time only ever used once the lxsession xsettings daemon is running, which then provides the value of bar_bg_color which is set in the lxsession conf file you identified above to any GTK applications which use the theme - this is how the bar colour can be changed in real time without changing the theme file itself.
The 1% of the time when the lxsession daemon isn't running is when the lightdm greeter is running,as this happens before lxsession starts the daemon - at this point, there is no user logged in, so per-user lxsession settings can't be used. However, the greeter doesn't show a taskbar and so makes not use of this colour anyway, so the error message doesn't indicate an actual problem.
It's easy enough to make the error message go away - adding a dummy bar_bg_color to the theme file, which will be overridden once lxsession is running, will do it - I'll add one next time I do an update just to fix the message.
Thanks for spotting it!
spl237
on 9 May 2018
I know workarounds have already been posted for this, but wanted to add one I found on the Pi forum that works for me:
Create archive /etc/X11/xorg.conf with this content:
Section "ServerFlags" Option "blank time" "0" Option "standby time" "0" Option "suspend time" "0" Option "off time" "0" EndSectionSave and restart.
t1m0thyj
on 9 May 2018
@t1m0thyj
Yeah, that would take care of the screensaver/blanking stuff, but it doesn't address the blanking background (?) color, which is bright beige (or is it gray?), unless I issue: xsetroot -display :0 -solid black.
I wish I could understand where the heck this color is "stored" when that command is executed, so that I could make it permanent. (As it was 2 months ago.)
In regard to using yet another X location of /etc/X11/xorg.conf, I already managed to set those in /home/pi/.config/lxsession/LXDE-pi/autostart.
E3V3A
on 10 May 2018
Related issues
ensarkarabudak
·
7Comments
Joulinar
·
5Comments
wudo94
·
5Comments
pssc
·
9Comments
incyi
·
9Comments
Most helpful comment
Finally solved this funky bug! However, it is still unknown what package update caused it.
There are (at least) two files that are setting some x related color schemes:
The following procedure, will (at least temporarily) restore the xset functionality.
Who knows, but use:
Now you can use xset as in OP again!
When this is done, the correct output of
xset -qshould be: