Bug 413645

Created attachment 123603 [details]
Desktop after update

For me, the issue is resolved in KDE Plasma 5.17.2

No still present for me with 5.17.2.

Out of curiosity, what's your screen resolution?

1920x1200

Thanks.

I had this happen yesterday. :/

*** Bug 416552 has been marked as a duplicate of this bug. ***

*** Bug 375229 has been marked as a duplicate of this bug. ***

*** Bug 414761 has been marked as a duplicate of this bug. ***

*** Bug 392845 has been marked as a duplicate of this bug. ***

OT: Where can I file a bug against this project being flown blind? This bug was filed (duplicate) in January 2017. And so far we have been told it was difficult to solve. Fine, by all means. 
But it was working (though more constraint) in Plasma 4. 
So nobody was able to see this cliff coming during the design phase of Plasma 5? Nobody thought about the consequences of icon placement at resolution change? Nobody tried resolution change before rolling out Plasma 5 as 'production'?

*** Bug 365286 has been marked as a duplicate of this bug. ***

*** Bug 363855 has been marked as a duplicate of this bug. ***

*** Bug 412640 has been marked as a duplicate of this bug. ***

*** Bug 393881 has been marked as a duplicate of this bug. ***

*** Bug 393270 has been marked as a duplicate of this bug. ***

*** Bug 389141 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 433799 ***

*** Bug 435282 has been marked as a duplicate of this bug. ***

Don't think this is a duplicate of Bug 433799, and also we should try not to forward-dupe an old bug with a bunch of dupes to a new one without them, and also that one doesn't seem fixed. :/

*** Bug 451487 has been marked as a duplicate of this bug. ***

*** Bug 433799 has been marked as a duplicate of this bug. ***

I also have the same or a similar problem: After the last update (strangely enough from 5.24.2 to 5.24.3), my Desktop widget (a clock) keeps getting reset after every restart to the upper left corner of my screen.

*** Bug 453259 has been marked as a duplicate of this bug. ***

*** Bug 456613 has been marked as a duplicate of this bug. ***

*** Bug 456497 has been marked as a duplicate of this bug. ***

Bug 456497 has a detailed reproducible test case.

Something I just tried:
I have a pesky single org.kde.plasma.notifications widget that never saved its position (even when re-creating it).
When I manually edited the Containment's ItemGeometries-<myres> line by appending an entry of where I wanted it and did a shell restart. It worked. And now all of a sudden the entry is updated when moving the widget.

Before the Entry was missing and I had the widget in the upper left corner (like the other reports).

*** Bug 457304 has been marked as a duplicate of this bug. ***

*** Bug 457358 has been marked as a duplicate of this bug. ***

*** Bug 458038 has been marked as a duplicate of this bug. ***

I believe I've located the source of this bug. Using a clean install of Kubuntu 22.04 in a virtual machine with a screen resolution of 2560x1600.

In /home/user/.config/plasma-org.kde.plasma.desktop-appletsrc:

> [Containments][1]
> ItemGeometries-2560x1600=Applet-24:767.806,688.073,224,208,0;
> ItemGeometriesHorizontal=Applet-24:767.806,688.073,224,208,0;
> activityId=24ffa803-0000-40a5-94cb-76f0419052d1
> formfactor=0
> immutability=1
> lastScreen=0
> location=0
> plugin=org.kde.plasma.folder
> wallpaperplugin=org.kde.image
>
> [Containments][1][Applets][24]
> immutability=1
> plugin=org.kde.plasma.notifications
>
> [Containments][1][Applets][24][Configuration]
> PreloadWeight=6

"Applet-24" is a Notifications widget that I've plopped somewhere in the middle of the desktop.
If I log out and log back in at this point, I watch the widget initially render where it belongs. It then appears to "wander" around (moving very noticeably all on its own), then suddenly snaps to the edge of the screen (usually into the lower-right corner). I think I'm capturing this movement because I'm using a VM.

If I remove the "ItemGeometriesHorizontal" line entirely from the file, then save it, close everything (but leave the widget in the middle of the screen), then log out and log back in, the widget stays where it was left last time.

However, the "ItemGeometriesHorizontal" line appears to be automatically recreated, and if I log out and log back in again without modifying the file, the widget again "wanders" then snaps into the wrong location. I have attempted to and succeeded in reproducing this behavior twice. This leads me to believe that the "ItemGeometriesHorizontal" entry is the source of the problem.

I can also resolve the problem by entirely removing the "ItemGeometries" line and leaving the "ItemGeometriesHorizontal" line. However, again, this line is recreated at login, and if left at logout, the widget will again "wander" and then snap. So something about the two entries coexisting is causing things to go wrong.

(In reply to Aaron Rainbolt from comment #34)
> I can also resolve the problem by entirely removing the "ItemGeometries"
> line and leaving the "ItemGeometriesHorizontal" line. However, again, this
> line is recreated at login, and if left at logout, the widget will again
> "wander" and then snap. So something about the two entries coexisting is
> causing things to go wrong.

Those floating-point values look suspect.  Does manually setting them to integer values (767 and 688) help?  If not or if it doesn't stick, try the following...

This bug has been around awhile, but there was a workaround I initially described in https://bugs.kde.org/show_bug.cgi?id=389141 that (with a bit of updating) presumably still works (see below):

With the plasmoids in the desired location (either with the ItemGeometries lines deleted or with them set as desired, not sure which), set plasma-org.kde.plasma.desktop-appletsrc (normally found in ~/.config unless you set $XDG_CONFIG_HOME) read-only.   This should prevent it from being overwritten with the bad config but unfortunately you'll still need to manually restart the initially started mixed-up plasmashell (plasmashell --replace, unfortunately at each login, tho it can be scripted as described below) in ordered to get it to take, since that initial start is what goes haywire.

You can try the --replace from krunner.  If that works as I expect it will, automate it with a script set to autostart (see the autostart kcontrol/systemsettings module), with a few seconds sleep to let the system stabilize before the --replace command.

Of course with the desktop-appletsrc file set readonly reconfiguring things will work only for that plasmshell session so you'll have to remember to toggle it back read-writable if you want to reconfigure...

(I believe the bug trigger here was a multi-monitor setup with different resolutions for each monitor, one full-HD one 4K.  When I upgraded to matching-resolution 4Ks it stopped triggering for me so I've not seen the bug in awhile.  Thus the "presumably still works" qualification above.)

> (I believe the bug trigger here was a multi-monitor setup with different resolutions for each monitor, one full-HD one 4K.  When I upgraded to matching-resolution 4Ks it stopped triggering for me so I've not seen the bug in awhile.  Thus the "presumably still works" qualification above.)

I think this is probably a race condition, because when my VM window was in a lower resolution (close to but not quite 1366x768), the bug didn't occur. When I set it to a high resolution, then it occurred. I'm guessing with 2 4K monitors, things must initialize quickly enough to hide the condition, but with mismatched monitors, the initialization goes slower and the condition appears.

Changing the floating-point values to whole numbers had no effect.

In https://invent.kde.org/plasma/plasma-workspace/-/blob/Plasma/5.25/components/containmentlayoutmanager/appletslayout.cpp, lines 83-88:

>    } else if (!m_geometryBeforeResolutionChange.isEmpty()) {
>        m_layoutManager->layoutGeometryChanged(newGeom, m_geometryBeforeResolutionChange);
>        m_geometryBeforeResolutionChange = QRectF();
>    
>        // Heuristically relayout items only when the plasma startup is fully completed
>    } else {

Commenting out the "else if" in this section of code causes the bug to disappear.

Looking at my previous comment, it may appear misleading - the comment within the "else if" block actually applies to the following "else" block if I'm understanding correctly. Here's the snippet of code (including the offending else if block) with more context:

>         } else if (m_layoutChanges & SizeChange) {
>             const QRect newGeom(x(), y(), width(), height());
>             // The size has been restored from the last one it has been saved: restore that exact same layout
>             if (newGeom.size() == m_savedSize) {
>                 m_layoutManager->resetLayoutFromConfig();
>    
>                 // If the resize is consequence of a screen resolution change, queue a relayout maintaining the distance between screen edges
>             } else if (!m_geometryBeforeResolutionChange.isEmpty()) {
>                 m_layoutManager->layoutGeometryChanged(newGeom, m_geometryBeforeResolutionChange);
>                 m_geometryBeforeResolutionChange = QRectF();
>    
>                 // Heuristically relayout items only when the plasma startup is fully completed
>             } else {
>                 polish();
>             }
>         }
>         m_layoutChanges = NoChange;
>     });

From https://invent.kde.org/plasma/plasma-workspace/-/blob/Plasma/5.25/components/containmentlayoutmanager/appletslayout.cpp, lines 76 to 93.

Hi,

read up stuff above. That's what I wrote earlier: that it's a race condition. Thanks anyway, though, seriously! 
Could you please file an appropriate 'diff -u' or similar, including plasma version, for me / for us to try out?

Instead of vi or likewise, I'd rather
cp xyz xyz.orig 
and then apply a unified patch file . So roll-back is much easier; and no need to interpret verbal instructions.

Thanks in advance!

The patch: https://termbin.com/kv20
Plasma version - 5.25.5 (built from source with kdesrc-build with build-group set to stable-kf5-qt5)

WARNING: I do not know C++. All this patch does is comment out a chunk of code - while this has the result of eliminating the bug in my testing, it also has the result of disabling whatever functionality was served by the code being commented out, and it might have unforseen consequences. Treat this like actively reacting uranium. Use in a VM or dedicating testing machine is highly encouraged!

(In reply to Aaron Rainbolt from comment #40)
> The patch: https://termbin.com/kv20
> Plasma version - 5.25.5 (built from source with kdesrc-build with
> build-group set to stable-kf5-qt5)
> 
> WARNING: I do not know C++. All this patch does is comment out a chunk of
> code - while this has the result of eliminating the bug in my testing, it
> also has the result of disabling whatever functionality was served by the
> code being commented out, and it might have unforseen consequences. Treat
> this like actively reacting uranium. Use in a VM or dedicating testing
> machine is highly encouraged!

:facepalm: Forgot to give the file path. Assuming you have everything set up according to https://community.kde.org/Get_Involved/development, the file you want to patch is ~/kde/src/plasma-workspace/components/containmentlayoutmanager/appletslayout.cpp.

So, looking at the logic here, I think the problem might actually be the result of a resolution change during early startup - for instance, on an NVIDIA machine of mine, the SDDM display on bootup is rather distorted (renders in 640x480, maybe?), but the resolution changes during early startup to match the screen's correct resolution. I think when this happens with a big enough screen, it causes the relayout to trigger at the wrong time and thus scrambles the widgets. If this is the case, the problematic else if statement may simply need to check for the presence of a component of KDE that only finishes loading after any early-startup resolution changes. Perhaps checking for KWin's presence would be sufficient here?

That seems quite likely.

(In reply to Aaron Rainbolt from comment #42)
> [T]he problem might actually be the
> result of a resolution change during early startup

Yes.  In my (different resolution dual-monitor) case the problem was definitely the resolution switch, in that case on the high resolution monitor (actually a 4K TV), switching from the resolution of the low-resolution monitor (a Full-HD TV).  What was happening is that all the widgets on the high-res monitor were moved to fit within the confines of the low-res monitor, thus all repositioning in the top-left quadrant of the high-res monitor.  It was pretty obvious -- once I noticed it. =:^\

The problem went away when I switched to both 4K monitors so there wasn't a resolution-switch.  Before that I worked around it by setting the rc-file read-only (so the bad startup wouldn't overwrite the good config) and setting up a start-up script that slept for a few seconds then did a plasmashell restart, basically doing via user script exactly what you suggested, waiting until after the resolutions settled in before (re)starting plasmashell.

I'm afraid of repeating myself for the umpteenth time; and here in order to partly support #42. 

In my case the scrambling happens in an irregular manner; sometimes at boot it does, sometimes it doesn't. My initial display (built-in) is 1920x1080; my secondary display 2560x1440 is connected via HDMI, but defined as primary display. Sometimes the icons on the 2560x1440 are squeezed into 1920x1080; sometimes not.
This goes along to the SDDM and subsequent resolution change(s) in #42. So it seems that sometimes the initial display comes up, squeezes the icons, and sometimes it doesn't. So I have to assume the logical: it has never seen any 1920x1080 during boot in those cases. 
Since it is a static setup of the PC and the peripherals, I assumed a race condition. First part of remark.

Still less frequently, this same happens in yet another 'fashion': the desktop returns to the well-known default background, the coloured grayish diagonal one, with all icons and desktop objects arranged in line starting from the upper left corner. Second part of the remark.

So it looks like we have to do with at least TWO such undefined (race?) conditions at startup. Seemingly the initial display is at times activated during bootup, sometimes the bootup ends directly at the primary (peripheral) display. 
Plus, we seem to encounter another potentially undefined condition, in which the previous settings are considered unavailable or damaged or whatnot; so a fall-back to the pre-defined default layout of the screen is initiated. 

Sometimes the final resolution on the

Looks like the resolution change was indeed (at least part of) the problem. Changing AppletsLayout::AppletsLayout to ignore any screen resolution changes the first time it is ran fixed the bug, while still allowing the widgets to be repositioned when the user intentionally changes the screen resolution. I've only tested this in a single-monitor setup within a VM, but it entirely resolved the problem for me.

Expect a merge request soon. \o/

Crud. Well the solution that I was about to post a merge request for turned out to only solve the problem partway. While the widgets are no longer scrambled on startup, you can still cause them to be scrambled by starting KDE in a way where the resolution *doesn't* change during early startup, then change the resolution (tested by increasing the resolution). Bam, the widgets go crazy again. So the situation has been much improved, but there's still a bug lurking somewhere (probably in AbstractLayoutManager). :-(

Er, no, probably in GridLayoutManager. (Note to self, look at code before declaring where you think a bug is.)

Nevermind, I guess the bug seeming to still be there was a fluke? Now I can't get the wrong behavior to happen anymore. :/ Task failed successfully, I guess.

Bah, and now there it is again! Fickle thing. Alright, sorry for bug spam. I'll be back once I figure out what it's doing this time.

Alright, looks like everything's now working right! Merge request: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2118

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2120

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1150

Git commit ef57cd3d50f729f22558a20b03172da539e3bb71 by Marco Martin.
Committed on 23/09/2022 at 10:04.
Pushed by mart into branch 'master'.

Introduce a lock that blocks relayouts and config writes

The resize of the layout area can happen either by screen resolution
change or available screen area change (a panel appears or is resized)
This is not an atomic operation, as width and height are usually set in
2 different operations, and even worse the layout area is resized to
match the available one with an animation, so many intermediate resizes
that should never cause a relayout happen.

In normal operation an event compression timer limits the actual
relayouts to hopefully one, but if the system is really slowed down
(for instance, startup) the timer may expire and cause relayouts in
non useful sizes, losing the needed configuration.

In combination with
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1150

The lock blocks all relayout and config writes when the size of the
layout area doesn't correspond to corona availablescreenrect, which are
the only "settled" cases.

M  +23   -2    components/containmentlayoutmanager/appletslayout.cpp
M  +7    -0    components/containmentlayoutmanager/appletslayout.h

https://invent.kde.org/plasma/plasma-workspace/commit/ef57cd3d50f729f22558a20b03172da539e3bb71

Git commit bd676333cf57659bc885928afe5d3fe908589e79 by Marco Martin.
Committed on 23/09/2022 at 10:05.
Pushed by mart into branch 'master'.

Use relayout locking

This makes use of the layout locking freature introduced in
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2120
The resize of the layout area can happen either by screen resolution
change or available screen area change (a panel appears or is resized).

This is not an atomic operation, as width and height are usually set in
2 different operations, and even worse the layout area is resized to
match the available one with an animation, so many intermediate resizes
that should never cause a relayout happen.

A compression timer limits the actual relayouts to hopefully one,
 but if the system is really slowed down
(for instance, startup) the timer may expire and cause relayouts in
non useful sizes, losing the needed configuration.

The lock blocks all relayout and config writes when the size of the
layout area doesn't correspond to corona availablescreenrect, which are
the only "settled" cases.

M  +1    -0    containments/desktop/package/contents/ui/main.qml

https://invent.kde.org/plasma/plasma-desktop/commit/bd676333cf57659bc885928afe5d3fe908589e79

Sounds good, and appropriate! Thanks a bunch.

Please, when can we expect to see this patch being rolled out with the usual update && upgrade?
(I don't feel like compiling myself; and can survive with my workarounds)

Git commit 59bf0f5a2081ed49a32a34083b7f5a9f0792358b by Nate Graham, on behalf of Marco Martin.
Committed on 23/09/2022 at 22:21.
Pushed by ngraham into branch 'Plasma/5.26'.

Introduce a lock that blocks relayouts and config writes

The resize of the layout area can happen either by screen resolution
change or available screen area change (a panel appears or is resized)
This is not an atomic operation, as width and height are usually set in
2 different operations, and even worse the layout area is resized to
match the available one with an animation, so many intermediate resizes
that should never cause a relayout happen.

In normal operation an event compression timer limits the actual
relayouts to hopefully one, but if the system is really slowed down
(for instance, startup) the timer may expire and cause relayouts in
non useful sizes, losing the needed configuration.

In combination with
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1150

The lock blocks all relayout and config writes when the size of the
layout area doesn't correspond to corona availablescreenrect, which are
the only "settled" cases.


(cherry picked from commit ef57cd3d50f729f22558a20b03172da539e3bb71)

M  +23   -2    components/containmentlayoutmanager/appletslayout.cpp
M  +7    -0    components/containmentlayoutmanager/appletslayout.h

https://invent.kde.org/plasma/plasma-workspace/commit/59bf0f5a2081ed49a32a34083b7f5a9f0792358b

Git commit 22fa69d96d64422318e83cc57d9ed1d0a08c17b0 by Nate Graham, on behalf of Marco Martin.
Committed on 23/09/2022 at 22:21.
Pushed by ngraham into branch 'Plasma/5.26'.

Use relayout locking

This makes use of the layout locking freature introduced in
https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2120
The resize of the layout area can happen either by screen resolution
change or available screen area change (a panel appears or is resized).

This is not an atomic operation, as width and height are usually set in
2 different operations, and even worse the layout area is resized to
match the available one with an animation, so many intermediate resizes
that should never cause a relayout happen.

A compression timer limits the actual relayouts to hopefully one,
 but if the system is really slowed down
(for instance, startup) the timer may expire and cause relayouts in
non useful sizes, losing the needed configuration.

The lock blocks all relayout and config writes when the size of the
layout area doesn't correspond to corona availablescreenrect, which are
the only "settled" cases.


(cherry picked from commit bd676333cf57659bc885928afe5d3fe908589e79)

M  +1    -0    containments/desktop/package/contents/ui/main.qml

https://invent.kde.org/plasma/plasma-desktop/commit/22fa69d96d64422318e83cc57d9ed1d0a08c17b0

Writing this as a comment and not a bug report since there's still some more work to be done, but here's some extra info:

While attempting to test the backports of this bug fix (https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1178 and https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2167), I used a special setup with a painfully slow emulated display in order to reproduce the bug and see if the fix worked. Initially, I was led to believe that the fix was failing in my testing, however on closer investigation, I believe there is a different though related bug that my setup is making show up.

How to reproduce the setup:

1: Install GNOME Boxes. This virtualization software has been able to reliably reproduce the issue for me most of the time. VirtualBox has a significantly faster emulated display and may not work.
2: Install Kubuntu 22.04 into GNOME Boxes, providing 8 GB of RAM and 100 GB of disk space. (NOTE: KDE neon Developer Edition won't work - this bug only is appearing on Kubuntu for me, possibly due to the use of KDE Plasma 5.24 in Kubuntu, as opposed to a build from Master in Neon.)
3: When the installation is finished, do `sudo apt update && sudo apt -y full-upgrade` in a terminal, then reboot the VM.
4: Change the display resolution within the VM to the maximum possible resolution.
5: Place some widgets on the desktop.
6: Log out and log back in. The widgets will end up being shifted or scrambled around.
7: Download the KDE Plasma 5.24.6 tarballs and signature files from https://download.kde.org/stable/plasma/5.24.6/ and GPG verify them, then extract them.
8: Build and install all of KDE Plasma 5.24.6 once piece at a time, using `sudo make install` for installation.
9: Reboot the VM.
10: Place widgets on the screen where you want them (repositioning the existing ones if you so desire).
11: Reboot the VM again. The widgets will become scrambled/shifted again, as expected.
12: Apply the code changes in the two linked merge requests, then rebuild plasma-desktop and plasma-workspace.
13: Reposition your widgets, and reboot again. The widgets will become scrambled/shifted again, despite the applied bug fix.

Note that, if you do this whole process on KDE neon Developer Edition, the widgets will never be shifted or scrambled around, *not even in step 11.* This indicates that this particular bug is outside of KDE Plasma, as two different distros running the exact same version of Plasma display different behavior.

Hope it will make it possible to use widgets on my multi-monitor setup without them losing their position or even disappear as it used to happen in the past. Will see.

(In reply to Aaron Rainbolt from comment #59)
> Note that, if you do this whole process on KDE neon Developer Edition, the
> widgets will never be shifted or scrambled around, *not even in step 11.*
> This indicates that this particular bug is outside of KDE Plasma, as two
> different distros running the exact same version of Plasma display different
> behavior.


Looks like a Qt bug. If you can test https://invent.kde.org/qt/qt/qtbase/-/commit/75c0053006d05c930749652dfb0120c5a78689de it would be better

I see the fix has not been worked on for 5.24 for release in 5.24.7 (the current LTS release of Plasma). I highly suggest and urge this be done to keep with the 2-year LTS promise.

That's out of scope for this bug report. Not everything is backportable to 5.24, but in this case it is actually in progress anyway. Regardless, this is fixed in 5.26, so let's only re-open if it it's discovered to not in fact be fixed in 5.26.

Git commit 0a01c8910309fb9f289fe0aa58492e106d154548 by Aaron Rainbolt, on behalf of Marco Martin.
Committed on 13/10/2022 at 21:45.
Pushed by ngraham into branch 'Plasma/5.24'.

Introduce a lock that blocks relayouts and config writes

The resize of the layout area can happen either by screen resolution
change or available screen area change (a panel appears or is resized)
This is not an atomic operation, as width and height are usually set in
2 different operations, and even worse the layout area is resized to
  match the available one with an animation, so many intermediate resizes
that should never cause a relayout happen.
In normal operation an event compression timer limits the actual
relayouts to hopefully one, but if the system is really slowed down
(for instance, startup) the timer may expire and cause relayouts in
non useful sizes, losing the needed configuration
In combination with

The lock blocks all relayout and config writes when the size of the
layout area doesn't correspond to corona availablescreenrect, which are
the only "settled" cases.

M  +24   -2    components/containmentlayoutmanager/appletslayout.cpp
M  +7    -0    components/containmentlayoutmanager/appletslayout.h

https://invent.kde.org/plasma/plasma-workspace/commit/0a01c8910309fb9f289fe0aa58492e106d154548

Git commit 234cd860532449f017ecbbca6a8caad5473fcf8b by Aaron Rainbolt, on behalf of Marco Martin.
Committed on 13/10/2022 at 21:46.
Pushed by ngraham into branch 'Plasma/5.24'.

Use relayout locking

This makes use of the layout locking freature introduced in

The resize of the layout area can happen either by screen resolution
change or available screen area change (a panel appears or is resized)
This is not an atomic operation, as width and height are usually set in
2 different operations, and even worse the layout area is resized to
  match the available one with an animation, so many intermediate resizes
that should never cause a relayout happen.
A compression timer limits the actual relayouts to hopefully one,
 but if the system is really slowed down
(for instance, startup) the timer may expire and cause relayouts in
non useful sizes, losing the needed configuration
The lock blocks all relayout and config writes when the size of the
layout area doesn't correspond to corona availablescreenrect, which are
the only "settled" cases.

M  +3    -2    containments/desktop/package/contents/ui/main.qml

https://invent.kde.org/plasma/plasma-desktop/commit/234cd860532449f017ecbbca6a8caad5473fcf8b

I am reopening this as I see a bug happen in 5.26 on Neon which looks quite similar to this.
I have a desktop PC connected to my 4K TV via HDMI. The system is actually set to a resolution of 1920x1080, so I am not using the TV's default resolution but a lower one. After booting, the widgets I have on the desktop do not keep the position I set on the previous boot and are instead placed as if, at some point during the boot process, the resolution was set to an even lower value and then increased to Full-HD.

It's quite possible there are additional issues that can cause the same result, but for everyone's sanity, it's best if you open a new bug report, so we can investigate that issue on its own without spamming everyone subscribed to this one. Thanks!

During testing of 5.24.7 on Kubuntu 22.04 LTS, this has remained in place. Aaron Rainbolt, Riccardo Robecchi, Nate Graham: I have created a new bug 460618 to track and added you to the CC list.

Still getting some reports of this in 5.26. :( Those are being tracked in Bug 458038, and ultimately we may end up re-opening this. I guess there were more edge cases. Time will tell.