The kscreen configuration files located at “~/.local/share/kscreen” are unique to that installation. They contain information about the screen(s) such as size, refresh rate, orientation etc. If they are restored from a different system, unless that is hardware identical there could well be problems.
On your troublesome systems you could, as suggested, try stopping or disabling kscreen, deleting the contents of “~/.local/share/kscreen”, then starting or re-enabling kscreen, to see if that effects a cure. Although I note from your post above you wrote:
The system was installed and user henk was added during installation as usual.
Using user henk in KDE presented me with the problem of the kscreen pop-up from the beginning.
so I’m not too optimistic it will make any difference, perhaps kscreen misreads, or misinterprets the hardware setup.
I accept that permanently disabling kscreen is not a bug fix, but a bug workaround.
My own view though is that kscreen is redundant on a single monitor desktop setup, and as such I always disable it, thus saving, albeit a very small amount of system resources; and avoiding any of kscreens quirks that may arise from time to time.
I agree. And you are correct, the problem was right from the start with a fresh user (henk) created during system installation and a pristine KDE login. So any suggestions of the often very useful “try a new user” kind, can be answered by that.
So while your suggestion of not using ~/.local/share/kscreen from the old system (as is the case at this moment), might be something to try just because it is logical to let it generate anew on other hardware, but it will most probably not avoid the problem.
I also have something that might be related. The settings for energy are that the screen should dim after 5 and switched off after 10 mins. This did not happen, because when it pops-up every 5 mins, my interpretation is that that will not be seen. But now it still does not work. I have switched this off and on again, but still no dim, etc.
My next action will be to grab the system from my wife for half an hour, log in with user henk.
Check if I still gets the pop-up.
Move ~/.local/share/kscreen, log out and login again, maybe check the contents of the moved against the new created files.
Same for the one with the same name in /outputs.
Thus in my conclusion: in this case it does not matter if it is created new or a copy from the earlier system.
Done.
No further pop-ups.
Dimming after 5 mins and switch off after 10 mins does not happen.
“Power Management”, “Energy Saving” on (one of) my desktop systems. - https://paste.opensuse.org/view/raw/83ef4dc0 edit: I will add that the “Switch of after:” works as expected.
I only have “Dim” options, plus alternate settings for “Battery” and “Low Battery” on my laptop.
I think “powerdevil5”, which handles energy saving, is getting confused… it thinks your desktop is a laptop. I don’t have a solution, or even a bodge, for that one.
So… it does look as if the blame lies with KDE and a bug report probably is in order - but I’ve no idea what component that would be against.
Probably easier to initially concentrate on the Power Management / Energy Saving and file against powerdevil5, let the KDE developers reassign as seen fit.
Because browsing through KDE bugs for a while, I found mentioning HDMI sometimes being in the line of problems.
Thus I tried what I suggested earlier, shutdown the system, replaced HDMI by VGA and started again. Checked with the Energy saving settings. It is the same as before: laptop inspired.
It might be worth adding the output of “dmidecode | grep -A3 ‘^Chassis’” to show that, at least as far as the DMI/SMBIOS table is concerned, the machine is a Desktop.
Yes, but , fine – we’re still left with the issue of the Linux Kernel being able to support an AMD “Cezanne” APU …
On this Leap 15.4 Laptop, the “kernel-firmware-amdgpu” package contains in the directory ‘/lib/firmware/amdgpu/’ Firmware for the AMD “Renoir” APUs (the series immediately preceding the “Cezanne” series) but, nothing for the “Cezanne” APUs …
AFAICS, support for AMD “Cezanne” APUs was first made available with the Linux Kernel version 5.16 and/or 5.17 …
My personal current working view is that, to support your Hardware, you’ll have to move to Tumbleweed
, for the time being …
I have no idea what we should experience with “better”.
In any case, when you gentlemen are curious on how the situation is now on the system, please ask me to execute commands that list information you want to see. I will be glad to provide it.
Yes, but , fine – we’re still left with the issue of the Linux Kernel being able to support an AMD “Cezanne” APU …
On this Leap 15.4 Laptop, the “kernel-firmware-amdgpu” package contains in the directory ‘/lib/firmware/amdgpu/’ Firmware for the AMD “Renoir” APUs (the series immediately preceding the “Cezanne” series) but, nothing for the “Cezanne” APUs …
AFAICS, support for AMD “Cezanne” APUs was first made available with the Linux Kernel version 5.16 and/or 5.17 …
My personal current working view is that, to support your Hardware, you’ll have to move to Tumbleweed
, for the time being … >
Isn’t the VEGA Cezanne firmware in the green_sardine* files that are included in Leap 15.4 ?
ls -l /lib/firmware/amdgpu/green_sardine*
-rw-r--r-- 1 root root 34208 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_asd.bin.xz
-rw-r--r-- 1 root root 11356 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_ce.bin.xz
-rw-r--r-- 1 root root 68252 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_dmcub.bin.xz
-rw-r--r-- 1 root root 29276 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_me.bin.xz
lrwxrwxrwx 1 root root 24 23. Mai 16:09 /lib/firmware/amdgpu/green_sardine_mec2.bin.xz -> green_
sardine_mec.bin.xz
-rw-r--r-- 1 root root 26684 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_mec.bin.xz
-rw-r--r-- 1 root root 35084 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_pfp.bin.xz
-rw-r--r-- 1 root root 9196 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_rlc.bin.xz
-rw-r--r-- 1 root root 7540 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_sdma.bin.xz
-rw-r--r-- 1 root root 11756 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_ta.bin.xz
-rw-r--r-- 1 root root 252172 23. Mai 16:06 /lib/firmware/amdgpu/green_sardine_vcn.bin.xz
The graphic performance for games and video stuff would be of course better if the amdgpu driver can be used. And the 1920x1080 resolution might have worked without a GRUB tweak.