Bug 390295 - The active virtual desktop is no longer remembered between sessions
Summary: The active virtual desktop is no longer remembered between sessions
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 5.19.0
Platform: Arch Linux Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL: https://phabricator.kde.org/D19520
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-11 21:37 UTC by Xavion
Modified: 2021-07-26 21:10 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.15.3
kde: X11+
vlad.zahorodnii: ReviewRequest+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xavion 2018-02-11 21:37:03 UTC
With "plasma-workspace" v5.11.5 and lower, the active virtual desktop was always remembered between sessions.

I have a 2x2 desktop grid.  If I was on the fourth (i.e. bottom-right) one when I logged out, I would start back in there the next session.

Whenever I do this with v5.12.0, I always end up on the first (i.e. top-left) desktop.  This means the state isn't being saved/restored.
Comment 1 Krzysztof Gajdemski 2019-03-02 08:19:28 UTC
I can confirm it still exists in 5.14.5 (Debian Buster). It looks like the correct desktop number is saved into session/kwin* but it isn't taken into account.
Part of the session file:

[Session]                                                                                                                                                      
active=-1                                                                                                                                                      
activities1=d6660dac-e7f6-4288-9eaf-add3ca8e2f67                                                                                                               
activities2=                                                                                                                                                   
count=2                                                                                                                                                        
desktop=2                                                                                                                                                      
desktop1=4                                                                                                                                                     
desktop2=-1
[ … ]

Either way, kwin starts with desktop 1. If any other data is required to resolve this annoying bug, I'll try to provide it.
Comment 2 Vlad Zahorodnii 2019-03-04 10:58:15 UTC
> is saved into session/kwin* but it isn't taken into account.

KWin tries to activate virtual desktop stored in session, but apparently there's something wrong. I think the issue may be in

    if (!VirtualDesktopManager::self()->setCurrent(m_initialDesktop))
        VirtualDesktopManager::self()->setCurrent(1);
Comment 3 Vlad Zahorodnii 2019-03-08 08:49:08 UTC
Git commit a9e469bf13f6d99c24eb2ae24c3a0f4ec0a79d61 by Vlad Zagorodniy.
Committed on 08/03/2019 at 08:38.
Pushed by vladz into branch 'Plasma/5.15'.

Properly restore current desktop from session

Summary:
VirtualDesktopManager is initialized in two places: Workspace::init and
Workspace::initWithX11. The former method loads virtual desktops from
the config file and the latter method synchronizes VirtualDesktopManager
with RootInfo.

Both methods do

    if (!VirtualDesktopManager::self()->setCurrent(m_initialDesktop))
        VirtualDesktopManager::self()->setCurrent(1);

which makes sense in Workspace::init, but not in Workspace::initWithX11.

When Workspace::initWithX11 is called, the current virtual desktop is
the same as m_initialDesktop. So that piece of code basically makes
the first virtual desktop current no matter what.
FIXED-IN: 5.15.3

Reviewers: #kwin, davidedmundson

Reviewed By: #kwin, davidedmundson

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D19520

M  +3    -3    workspace.cpp

https://commits.kde.org/kwin/a9e469bf13f6d99c24eb2ae24c3a0f4ec0a79d61
Comment 4 Xavion 2019-03-08 20:51:22 UTC
Thanks for getting around to fixing this -- much appreciated.
Comment 5 Vlad Zahorodnii 2019-03-13 09:48:40 UTC
Git commit f7af113261f7e899e1d954b0558b2c637a9cced1 by Vlad Zagorodniy.
Committed on 13/03/2019 at 09:45.
Pushed by vladz into branch 'Plasma/5.12'.

Properly restore current desktop from session

Summary:
VirtualDesktopManager is initialized in two places: Workspace::init and
Workspace::initWithX11. The former method loads virtual desktops from
the config file and the latter method synchronizes VirtualDesktopManager
with RootInfo.

Both methods do

    if (!VirtualDesktopManager::self()->setCurrent(m_initialDesktop))
        VirtualDesktopManager::self()->setCurrent(1);

which makes sense in Workspace::init, but not in Workspace::initWithX11.

When Workspace::initWithX11 is called, the current virtual desktop is
the same as m_initialDesktop. So that piece of code basically makes
the first virtual desktop current no matter what.
FIXED-IN: 5.15.3

Reviewers: #kwin, davidedmundson

Reviewed By: #kwin, davidedmundson

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D19520

M  +3    -3    workspace.cpp

https://commits.kde.org/kwin/f7af113261f7e899e1d954b0558b2c637a9cced1
Comment 6 Xavion 2020-06-14 21:30:16 UTC
This problem has resurfaced in KWin v5.19.0.  Please don't take a year to fix it this time.
Comment 7 Armin 2021-06-16 09:43:26 UTC
(In reply to Xavion from comment #6)
> This problem has resurfaced in KWin v5.19.0.  Please don't take a year to
> fix it this time.

Unfortunately is seems to have taken more than a year already...


I can reproduce this on my Fedora 34 system. This is an extremely annoying bug!


SOFTWARE/OS VERSIONS:
 OS: Fedora 
 Kernel: x86_64 Linux 5.11.21-300.fc34.x86_64
 DE: KDE 5.82.0 / Plasma 5.21.5
 WM: KWin
 GPU: Mesa Intel(R) HD Graphics 620
Comment 8 Armin 2021-06-24 06:45:34 UTC
I just updated KDE Plasma to the latest release and this issue still persists.

SOFTWARE/OS VERSIONS:
 OS: Fedora 
 Kernel: x86_64 Linux 5.12.11-300.fc34.x86_64
 DE: KDE 5.83.0 / Plasma 5.22.1
 WM: KWin
 CPU: Intel Core i7-7600U
 GPU: Mesa Intel(R) HD Graphics 620
Comment 9 Armin 2021-06-24 06:48:11 UTC
Though not the same issue, but probably related to:
https://bugs.kde.org/show_bug.cgi?id=435357

and thus subsequently:
https://bugs.kde.org/show_bug.cgi?id=15329

The latter is a 20+ years old bug!
Comment 10 Brian Kaye 2021-07-08 20:20:42 UTC
I have this problem on fedora 34 with all the latest patches(.plasma-desktop-5.22.2.1-1.fc34.x86_6). Most applications are restored to the first virtual desktop. I have a 2x2 virtual desktop grid. The only application that seems to be restored to the proper virtual desktop is Firefox which I only run occasionally(Waterfox mostly). I created a new user, created a 2x2 virtual desktop grid and the problem occurred. So its not something peculiar to my user configuration. I did report this through the Fedora Bugzilla.
Comment 11 Brian Kaye 2021-07-09 22:44:44 UTC
I simplified my desktops by only having 1 Konsole application open in Desktop 3 (2x2 configuration). Upon restart the Konsole session was opened in Desktop 1. here is the session file for the session:

[Session]
active=3
activities1=
activities2=
activities3=726fb687-7df6-4007-a702-d1d5e4496a90
count=3
desktop=3
desktop1=-1
desktop2=-1
desktop3=3
fsrestore1=0,0,0,0
fsrestore2=0,0,0,0
fsrestore3=0,0,0,0
fullscreen1=0
fullscreen2=0
fullscreen3=0
geometry1=0,0,3840,2160
geometry2=0,2088,3840,72
geometry3=0,61,1855,1729
iconified1=false
iconified2=false
iconified3=false
keepBelow1=true
keepBelow2=false
keepBelow3=false
maximize1=0
maximize2=0
maximize3=0
opacity1=1
opacity2=1
opacity3=1
resourceClass1=plasmashell
resourceClass2=plasmashell
resourceClass3=konsole
resourceName1=plasmashell
resourceName2=plasmashell
resourceName3=konsole
restore1=0,0,3840,2160
restore2=0,2088,3840,72
restore3=0,0,1855,1790
sessionId1=106d617273000162586892600000028100000
sessionId2=106d617273000162586892600000028100000
sessionId3=106d617273000162586895400000028100007
shaded1=false
shaded2=false
shaded3=false
shortcut1=
shortcut2=
shortcut3=
skipPager1=false
skipPager2=false
skipPager3=false
skipSwitcher1=false
skipSwitcher2=false
skipSwitcher3=false
skipTaskbar1=false
skipTaskbar2=false
skipTaskbar3=false
stackingOrder1=0
stackingOrder2=1
stackingOrder3=2
staysOnTop1=false
staysOnTop2=false
staysOnTop3=false
sticky1=true
sticky2=true
sticky3=false
userNoBorder1=true
userNoBorder2=true
userNoBorder3=false
windowRole1=
windowRole2=
windowRole3=MainWindow#1
windowType1=Desktop
windowType2=Dock
windowType3=Normal
wmCommand1=
wmCommand2=
wmCommand3=
Comment 12 Brian Kaye 2021-07-09 22:55:51 UTC
In addition to my previous comment here is the description file in      ~/.config/session for the kconsole application (open in Desktop 3 before restart and Desktop 1 after restart:


[1]
Active=0
Tabs=[{"Orientation":"Horizontal","Widgets":[{"SessionRestoreId":1}]}]

[Number]
NumberOfSessions=1
NumberOfWindows=1

[Session1]
Encoding=UTF-8
LocalTab=%d : %n
Profile[$e]=$HOME/.local/share/konsole/Profile 1.profile
RemoteTab=(%u) %H
SessionGuid={dfe91696-4acf-4b94-a43b-d4ebdebe9794}
TabColor=
WorkingDir[$e]=$HOME/.config/session

[WindowProperties1]
ClassName=Konsole::MainWindow
ObjectName=MainWindow#1
RestorePositionForNextInstance=false
State=AAAA/wAAAAD9AAAAAAAABcwAAAT0AAAABAAAAAQAAAAIAAAACPwAAAABAAAAAgAAAAIAAAAWAG0AYQBpAG4AVABvAG8AbABCAGEAcgEAAAAA/////wAAAAAAAAAAAAAAHABzAGUAcwBzAGkAbwBuAFQAbwBvAGwAYgBhAHIBAAAC7/////8AAAAAAAAAAA==
StatusBar=Disabled
ToolBarsMovable=Disabled
eDP1 Height 3072x1728=1383
eDP1 Width 3072x1728=1484
eDP1 XPosition 3072x1728=0
eDP1 YPosition 3072x1728=49
Comment 13 Andrey 2021-07-26 11:52:30 UTC
Is it OK for Wayland session?
Comment 14 Brian Kaye 2021-07-26 21:10:24 UTC
Won't be switching to wayland real soon. Here are the tests I ran.

1. Configured in X firefox in desktop 3 and Konsole in desktop 4. Restart with X put Konsole in desktop 1 and firefox in proper desktop.

2. Configured as in 1. and restarted in wayland. Same problem but everything slower to start.

3. Configured in wayland as in 1. Restarted in wayland. Different problem. The Konsole application did not restart. Desktop icons took a long time to show up. 

4. Configured in wayland as in 1. Restarted in X. Different problem. The Konsole application did not show up. Took long time (~ 20 seconds) for desktop icons to show up. Login was slow. Have not tried a second login yet.