Bug 1956916 - KDE Session Not restored properly
Summary: KDE Session Not restored properly
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-workspace
Version: 36
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: KDE SIG
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2021-05-04 16:15 UTC by Brian Kaye
Modified: 2022-08-26 08:56 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
KDE Software Compilation 437551 0 NOR UNCONFIRMED Session restore doesn't restore windows to the correct activity/desktop 2021-05-25 09:14:44 UTC

Description Brian Kaye 2021-05-04 16:15:41 UTC
Description of problem:workspaces not restored to proper desktop

Version-Release number of selected component (if applicable):

Fedora 34 Plasma 5.21.4-1.fc34.x86_64  using X11
How reproducible:
Every time

Steps to Reproduce:
1. Shutdown system
2. Reboot

Actual results:
All windows are started in the first desktop

Expected results:
All windows should be started in their original desktop.

Additional info:
New upgrade of fedora 34 from fedora 33.

I have 4 virtual desktops configured. On restart all the workspaces are restored to the first virtual desktop.

Comment 1 John Griffiths 2021-05-05 00:56:14 UTC
I upgraded from FC32 to FC34 and have similar problem.

I have 6 desktops. All got jammed into one. The mouse and keyboard become unresponsive.

I was using KDM. Switched to SDDM which did not actually start my desktop. Switched to GDM which also messed up when I tried to run a plasma session.

Comment 2 Brian Kaye 2021-05-05 02:45:04 UTC
I am using sddm. Did not have a problem with my mouse or keyboard. I am using X11 and not Wayland

Comment 3 John Griffiths 2021-05-05 16:13:05 UTC
I got the kde desktop to display under GDM by selecting the Plasma Wayland but after a while, the display became unresponsive; no mouse pointer movement or response to keyboard. 

I connected by ssh from a f32 system and ran top. plasmashell is running away.

296991 jrg3      20   0 2258508 215112 130524 S 100.0   1.3  36:50.27 plasmashell

Comment 4 Brian Kaye 2021-05-06 01:24:35 UTC
Sounds like a different problem. Did you try Alt+Ctrl+F3 to get a new console?

Comment 5 John Griffiths 2021-05-06 15:24:58 UTC
(In reply to Brian Kaye from comment #4)
> Sounds like a different problem. Did you try Alt+Ctrl+F3 to get a new
> console?

Yes. Like I said, the keyboard and mouse were both unresponsive.

Comment 6 Ondrej Mosnacek 2021-05-25 09:14:45 UTC
FWIW, I'm also facing the session restore issue. I've filed a bug upstream, so far there has been no response:

Comment 7 Jiannan Liu 2021-07-24 16:30:29 UTC
Hello, I am having this problem as well. I upgraded from Fedora 33 to 34. Session restoration worked well under Fedora 33 but only currently restores to the first virtual workspace under Fedora 34. I am using X11 and sddm in both Fedora 33 and 34, and plasma-workspace-5.22.3-2.fc34.x86_64 if they are relevant.

Comment 8 Brian Kaye 2021-07-24 19:15:03 UTC
Any idea of where one can find the format of ~/.config/session/'kwin_saved at previous logout_'. Only firefox seems to go to the right virtual desktop.

Comment 9 John Griffiths 2021-07-24 20:05:08 UTC
I believe this must be related to Wayland and display managers other than kdm.

I experienced scrambled desktops under Wayland and either gdm and sddm.

I switched back to kdm and open the session with kde in X. 

Since the desktops had been scrambled,I reset my desktops. Now all is ok, but I am afraid to use sddm, gdm  or Wayland with kde.

Comment 10 Brian Kaye 2021-07-25 11:56:58 UTC
There must be a bug in either the session saver or the session restore. If we knew what the format of the session file was then we could tell where the problem lays. 

I use sddm and start kde with X. The oddity that firefox is restored to the right desktop is confusing. I did try with a new user, creating 4 desktops and the problem reoccurred. This is really getting tiresome. Every time a new kernel is put out and one reboots the problem raises it ugly head. 

Since you know how to bypass the problem, maybe you could do a controlled experiment by only changing one of the things at a time. 

I have not tried kdm in years. It used to be quite buggy.

Comment 11 Brian Kaye 2021-07-25 13:21:15 UTC
SDDM is the default window manager for KDE. KDM does not appear to be actively maintained except for severe bugs. So there may be some risk using KDM going forward.

Comment 12 Rex Dieter 2021-07-25 13:43:08 UTC
In my experience, the display manager has little to do with session management, ie, testing kdm is likely not a good use of your time.

Upstream kde is aware of the issue.

Comment 13 Brian Kaye 2021-07-25 16:33:03 UTC
I just tried kdm and problem seems to persist there so I switched back.

Comment 14 John Griffiths 2021-07-25 16:44:45 UTC
I had to reconstruct my desktops after switch to kdm and when starting at login use X and not Wayland. Kdm will not reconstruct the desktops to what they were before they were corrupted. You have to remake them yourself.

As far as kdm being end of life, at least the code in it must be reading and writing the correct format for saving and restoring sessions.

Comment 15 Brian Kaye 2021-07-25 16:55:56 UTC
I logged using kdm. Switched all my apps to the desired desktops and re-logged in. The problem persisted. Small non detailed test.

Comment 16 John Griffiths 2021-07-25 20:58:23 UTC
I had to delete the .kde directory from an ssh log in, then logged in, arranged desktops, logged out, and logged back in. Everything was as I had set it.

I tried gdm and it scrambled my desktops again.

I repeated deleting the .kde directory and the process and have been using kde with kdm since.

Comment 17 Rex Dieter 2021-07-25 23:08:07 UTC
Fyi: .kde/ for used only by legacy kde3/kde4 applications.  Modern plasma uses xdg-related dirs like .cache, .config, and .local

Comment 18 John Griffiths 2021-07-25 23:35:19 UTC
I just related what I did.
It worked.
I am using kde with kdm under X on Fedora 34 every day.

Comment 19 John Griffiths 2021-07-25 23:55:40 UTC
I find it interesting that since modern plasma doesn't use the .kde directory that the .kde is being re-created after it is deleted. Something must think it is necessary. Not only that, the data in the .kde/share/config/kdeglobals file is updated. That does appear to be the only file that is updated.

Comment 20 Brian Kaye 2021-09-30 15:55:28 UTC
It is interesting that a lot of people are not complaining about this issue. Just updated a   lot of plasma rpms ( e.g. plasma-desktop.x86_64      5.22.5-1.fc34 ) and the problem persists. This suggests that it something peculiar to my setup.  Earlier I did create a new user on my system with 4 virtual desktops and the problem was there. This suggests something in the global part of my setup.

Comment 21 Ondrej Mosnacek 2021-11-20 20:14:02 UTC
Seems to be finally fixed for me after update to Plasma 5.23.2 (or 5.23.3, not sure which one exactly). Yay!

Comment 22 Brian Kaye 2021-11-21 16:41:52 UTC
Plasma 5.23.3 on my system seemed to have fixed it after upgrading my Fedora system to FC35. But after logging out and on it seems to have reverted to the old behaviour. 

First boot after upgrade was to old behaviour. Had to rebuild grub.cfg to pick up the FC35 kernel. Next reboot showed the correct behaviour. Started "System Settings" on Desktop 1 and moved it to Desktop 4. Started "waterfox" (branch of firefox) on Desktop 2 and logged out in an attempt to check if it was fixed. The old behaviour returned.

Comment 23 Brian Kaye 2021-11-22 02:29:13 UTC
After a little research here is the situation on my machine (lenovo P50 running Fedora 35 as of today). If I delete all of the files in .config/session and start applications in each of my 4 virtual desktops, then logout and login all  4 applications (Konsole, system settings, dolphin and kpatience) are started in their correct virtual desktop. If I then immediately logout and login it reverts to the old behaviour. So it looks like there is a step in the right direction but it is not solved yet. 

So with an empty .config/session directory the save/restore session works fine. But with files already  in .config/session either the "save session" messes up the files already there or  "restore session" process is confused about the second set of files saved.

Comment 24 Allen Akin 2022-02-23 00:01:57 UTC
Just to add to the chorus:  I also have this problem, and have had it for several months.  I'm running up-to-date Fedora 34, X11 with the NVIDIA driver.

My session is saved automatically on logout.  Upon login, the Konsole windows open with the correct size and correct placement on screen, but all on virtual desktop 1 instead of their previous locations.  

This is 100% reproducible.

Chrome windows restore to the correct virtual desktop, so perhaps this problem is limited to KDE apps.

Comment 25 Ben Cotton 2022-05-12 15:36:21 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 26 Allen Akin 2022-05-12 16:22:40 UTC
This is still present in Fedora 35, so if possible, please update the version number.

Comment 27 Ondrej Mosnacek 2022-08-26 08:51:38 UTC
Migrating my FAS address to omosnacek...

Note You need to log in before you can comment on or make changes to this bug.