KDE aks for monitor switching on a desktop PC

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.

It’s a rc file. As the name suggests it governs the startup of plasma. Nice reading for the disbelieving: Many problems in KDE are related to its configuration.

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 :wink: for half an hour, log in with user henk.

  1. Check if I still gets the pop-up.
  2. Move ~/.local/share/kscreen, log out and login again, maybe check the contents of the moved against the new created files.
  3. Switch Kscreen2 off.
  4. Check for the pop-up to be gone.
  5. Check for dim and switch off to function or not.

And, of course, report back here.

  1. Yes, user henk still gets it (as expected)
  2. As expected ~/.local/share/lkscreen is created anew.
beneden:/home/henk/.local/share # l kscreen red-kscreen/
kscreen:
total 16
drwxr-xr-x  3 henk wij 4096 Jul  9 14:23 ./
drwxr-xr-x 24 henk wij 4096 Jul  9 14:23 ../
-rw-r--r--  1 henk wij  417 Jul  9 14:23 c21f969b5f03d33d43e04f8f136e7682
drwxr-xr-x  2 henk wij 4096 Jul  9 14:23 outputs/

red-kscreen/:
total 20
drwxr-xr-x  3 henk wij 4096 Jul  7 13:04 ./
drwxr-xr-x 24 henk wij 4096 Jul  9 14:23 ../
-rw-r--r--  1 henk wij  509 Jan  8 15:41 7a23ced8cab4046f0e014b03fe8bfa74
-rw-r--r--  1 henk wij  417 Jul  9 14:19 c21f969b5f03d33d43e04f8f136e7682
drwxr-xr-x  2 henk wij 4096 Jul  7 13:04 outputs/
beneden:/home/henk/.local/share #

and no difference

beneden:/home/henk/.local/share # diff kscreen/c21f969b5f03d33d43e04f8f136e7682 red-kscreen/c21f969b5f03d33d43e04f8f136e7682 beneden:/home/henk/.local/share #

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.

  1. Done.
  2. No further pop-ups.
  3. Dimming after 5 mins and switch off after 10 mins does not happen.

Hello Dean, see the post just above this one, where your suggestion is executed.

“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.

Same as for the original problem. KDE thinks it is a laptop (with an extra screen attached) :disapointed:

I think this supports yje idea that KDE handles this as a laptop.

On another system, that configuration screen is the same as yours, with only the Switch off option.

On new system we are talking about all the time there is also the dim and there is more there.

I assume the root cause of all the troubles is that it categorizes it as laptop >:)

Out of curiosity… what does

sudo dmidecode | grep -A3 '^Chassis'

return

beneden:~ # dmidecode | grep -A3 '^Chassis'
Chassis Information
        Manufacturer: HP
        Type: Desktop
        Lock: Not Present
beneden:~ # 

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.

I have no high expectations: https://bugs.kde.org/show_bug.cgi?id=456518

BTW, just for the record.

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.

We can but see :slight_smile:

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.

That was my intention, but I forgot it. Added it. Thanks for awakening me :wink:

@hcvv:

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 …

But it works! My wife is very glad with the system.

Apparently the generic drivers work well enough to please her. If better is desired without switching distros, current stable kernel can be installed.

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.

dcurtisfra @hcvv:

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.