Monitor settings lost at login


I’ve a dual monitor setup and its been working great under Tumbleweed for quite some time. But after I recent zupper -dup I got some problems. There has been several updates since then but the problem remains.

I have two monitors and a extended desktop that uses both of them, the left monitor is rotated into portrait mode and the right one is in landscape. I’ve set everything up using the monitor settings in systemsettings5. Resolutions, rotation and offset of the monitors (related to each other) is all set up by the monitor settings. But since a while back Plasma forgets and resets the offset/postion settings at every logout/login. I need to launch systemsettings and manually reposition one of the monitors after every login or else will the monitors partly overlap.



Does this problem exist with a newly created useraccount ? If not:

you could try this
logout, hit Ctrl+Alt+F2
login with username and password

rm -rf ~/.local/share/kscreen

hit Ctrl+D to logout
hit Ctrl+Alt+F7 to login screen
login and try again to setup things the way you want them.

Tried to add a new user but it also experience the same problem.

// Hans

Try the same procedure as comment 2, but with a slightly different command:

rm -rf ~/.cache/*

To me this smells like a permissions problem preventing proper saving of settings, but this seems quite unlikely to reproduce with a new user. :frowning: How was the new user created, YaST? Will this reproduce if you try using the root user? If not, it supports the theory of a permissions problem

It might be useful for us to see pasted here using code tags some information collected while the screens are not running as desired:

xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
inxi -Gxx

Likely the inxi info gathering script needs to be installed first.
In the same vein, please show us /var/log/Xorg.0.log via upload to or or equivalent. Try

susepaste -n habr71 -e 10080 /var/log/Xorg.0.log

first. It’s easier than browser uploading, when it works. That server is flaky. :stuck_out_tongue:

Tried to clean the cache-direcory but with same result as before.

The new user was created using Yast.

Same problem appears for root as well so I dont think its a permission problem

xrandr | egrep 'onnect|creen|\*' | grep -v disconn | sort -r
Screen 0: minimum 320 x 200, current 2527 x 2236, maximum 16384 x 16384
DVI-I-1 connected primary 1920x1080+607+1156 (normal left inverted right x axis y axis) 531mm x 299mm
DVI-D-1 connected 1080x1920+0+0 left (normal left inverted right x axis y axis) 477mm x 268mm
   1920x1080     60.00*+  59.96    50.00    59.94    59.93  
   1920x1080     60.00 +  59.96    50.00    59.94    59.93* 
inxi -Gxx
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Bonaire XTX [Radeon R7 260X/360] vendor: XFX Pine driver: radeon 
           v: kernel bus ID: 01:00.0 chip ID: 1002:6658 
           Display: x11 server: X.Org 1.20.5 driver: modesetting unloaded: fbdev,vesa alternate: ati 
           compositor: kwin_x11 resolution: 1920x1080~60Hz 
           OpenGL: renderer: AMD BONAIRE (DRM 2.50.0 5.3.9-1-pae LLVM 9.0.0) v: 4.5 Mesa 19.2.3 direct render: Yes

susepaste was not happy tonight… serveral tries and all failed. So here is a pastebin link the xorg.0.log

1002:6658 is GCN2, so most likely should be using the DDX from xf86-video-amdgpu, while inxi reports you’re using the default modesetting DDX. If xf86-video-amdgpu is not installed, see if installing it helps. If it’s already installed, amdgpu may need explicit configuration via a Driver line in /etc/X11/xorg.conf.d/50-device.conf, and/or a cmdline option or two, maybe radeon.si_support=0 amdgpu.si_support=1.

I’ve never seen both DVI-I-1 and DVI-D-1 reported simultaneously, so to me is suspect to being mishandled in several places.

That shows you’re running a 32 bit kernel. What is output from?

inxi -C

xf86-video-amdgpu is installed.

inxi -C
CPU:       Topology: Quad Core model: AMD A8-6600K APU with Radeon HD Graphics bits: 64 type: MCP L2 cache: 2048 KiB 
           Speed: 1896 MHz min/max: 1900/3900 MHz Core speeds (MHz): 1: 1896 2: 1896 3: 1896 4: 1878 

Let’s try using xrandr “directly”, via a startup miniscript, instead of going through desktop settings, and for now, not fuss over which DDX is in use. Create the miniscript using superuser permission as:


Make it executable

sudo chmod 755 /etc/X11/xinit/xinitrc.d/

Try this as initial content:

xrandr --output DVI-D-1 --mode 1920x1080 --primary --output DVI-I-1 --mode 1920x1080 --left-of DVI-D-1 --rotate right

Whether it works correctly on startup, it can be run from an X terminal:

sudo /etc/X11/xinit/xinitrc.d/

If the left display is upside down, change rotate right to rotate left. If the display positions are swapped, swap the output parameters and run the miniscript again.

On the opensuse-factory mailing list it was announced that Mesa version 19.2.3 since TW20191110 has a “critical bug”, but didn’t describe what it is. I have it on several installations and no idea what is supposedly wrong. 19.2.4 is in the Xorg:X11 repo for any wishing to have a patched version.

The amdgpu DDX should be able to be forced using this file:


Containing this content:

Section "Device"
    Identifier "DefaultDevice"
#	Driver	"modesetting"

If it fails, the following or something similar might be required on the kernel cmdline:

radeon.si_support=0 amdgpu.si_support=1

BTW, in the standard TW OSS repo is the utility arandr. It can be used to generate the script to be used as /etc/X11/xinit/xinitrc.d/ When used arandr can save the script as a file in ~/.screenlayout/ (or anywhere else writable that you choose), then copied, renamed, edited, and if necessary, re-permissioned.

When you configure screen layout in /etc/X11/xinit/xinitrc.d/, it will be applied to any desktop session type you select, not just Plasma. is an arbitrary name. You can make it any name you please. A number at its start can affect when it gets run during X startup.

Added the script as described. Rebooted but with no change in result. Tried to execute the script from X-terminal and it just gives me an error “Can’t open display”


Tried to execute the script from X-terminal and it just gives me an error “Can’t open display”
Possibly our definitions for X terminal are out of sync. In Plasma the script should be run from Konsole, Xterm or Alt-F2, not one of the virtual terminals reached via Ctrl-Alt-Fn, which is where “cannot open display” errors typically come from.

Today I got a notification that I got ~700 packages to upgrade. Run the zypper dup and since then the problem is gone.


Yes! Thanks for your help and support. Very much appreciated!