Sorry this happened. In Plasma 5.27 we implemented a new system for mapping Plasma desktops and panels to screens that is fundamentally more correct by design, and as a result much more robust. We also added code to migrate old settings to this new system. Unfortunately, due to the non-determinism baked into the old system, the migration code works better the simpler your arrangement of screens, desktops, and panels was. For complex arrangements, we've seen a few reports that sometimes panels or desktops are swapped or missing, as a result of the old settings being in an inconsistent state at the moment of migration. We do have a UI to recover them in the form of the "Manage Desktops and Panels" window, which should let people manually restore their old setup. You can access it like so:

Right-click on desktop > click on "Enter Edit Mode" > a toolbar pops down from the top of the screen > click on "Manage Desktops and Panels"

Can you use that UI to move the desktop back to the correct screen? If you can, does the issue stop happening on subsequent reboots?

Possibly related: Bug 467422 and/or Bug 462316.

I do not think that my issue is related to the migration of old desktop settings. Actually, I am seeing this issue way more frequently with a new user that I have created on my system, that should have everything set up via the new defaults.

If I open the "Manage Desktops and Panels" configuration utility, everything is correct. And in fact, when I get the "black screen" doing ALT-F2 and then `plasmashell --replace` in the runner fixes everything.

Looks like the same issue as Bug 467422. In that case, the reporter says the issue was ultimately caused by a bad cable, somehow. Any chance you could check your monitor's cable for irregularities, and use a different one if possible?

Not a bad cable. As a matter of fact, I perfectly see the sddm screen on the monitor and logging in I see the plasma screen. Simply, when the issue occurs, I see the plasma screen with no "desktop" (no wallpaper image, no desktop folder view, only a large black region). This happens more frequently when — with one user logged in — I switch to another user. Pressing ALT-F2 to get the krunner and entering `plasmashell --replace` plasma restarts just fine. All this makes me thing of a 'race' or a timing issue wrt the startup phase of plasma.

I see the issue:
- on a laptop machine that is not so recent by today's standard, with haswell i7-4750HQ and a graphics unit that is not a workhorse (Intel Crystal Well Integrated Graphics Controller, rev 08);
- using an attached monitor, so that the attached screen is primary and the laptop screen is disabled.
Wonder if this specific configuration may have a relation with the issue.

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

It happened to me couple of times, but can't reproduce it each time.

Please attach your journalctl output from when the problem happens.

Also, please verify with a pristine as possible new user and take notes of exactly which changes you make and how. The more data points you can provide the better.

e.g. how do you configure the primary screen? do you use the applet or the popup or manually go to systemsettings? Do you make any other changes to *anything*? Is your laptop lid closed or open when the problem happens? Are the applications that are getting restored? etc. etc.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Currently moved to using Wayland and not experiencing this bug on that platform (even if other Wayland specific issues still exist).

Will test anyway on X11 as soon as possible since I believe there might still be an interest in fixing issues for X11.

Excellent, let's call it fixed until we know otherwise. I can't reproduce it at all on Wayland either, FWIW.

I've just installed Manjaro with KDE on a brand new machine, and at the first reboot with the external monitor connected, the desktop was black (just as it was on the previous machine almost every time).

I don't understand why this was closed as fixed. This was only ever reported to have been fixed on Wayland, and the title starts with "On X11"

Operating System: Manjaro Linux 
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.113.0
Qt Version: 5.15.12
Kernel Version: 6.6.10-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 12 × 12th Gen Intel® Core™ i7-1255U
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: Vivobook_ASUSLaptop X1502ZA_F1502ZA
System Version: 1.0

Largely because at this point multi-monitor on X11 is a lost cause; it simply can't be made to work well with the level of customization we offer users. Your only hope is to use Wayland if you want a halfway-decent multi-monitor experience. That may not be the answer you were looking for, but it's the truthful one.

If it makes you feel better, I can close this as RESOLVED INTENTIONAL to reflect the reality that we're unfortunately not able to put resources into playing whack-a-mole with multi-screen problems on X11.

I understand your point.

I have also started using the Wayland session that does not show this specific issue. Unfortunately, we are still in a trade-off phase, where one needs to decide whether the Wayland troubles are better than the X11 troubles or the other way round. ... and there seems little that can be done on the KDE side.

In fact, most of the trouble I am experiencing with wayland seems to come from:

-  the total lack of standardization of common things in Wayland

    - why cannot there be a standard way to do session restore so plasma cannot do it?
    - why cannot there be a cross-toolkit env variable to decide if applications should use X11 or Wayland and every toolkit has its own way, so launching applications via `ssh -X` which should work just fine using Xwayland does never work?
    - why isn't there a single cross-toolkit env variable to control scaling?
    - why Java applications won't obey scaling anyway so big commercial applications (MATLAB to mention one) are now almost unusable unless you use weird hacks like passing them through Xpra?

- rather strange policy decisions

    - why can we have scaling only by 75-100-125-150 etc., what was the issue with specifying DPIs that enabled a much finer tuning;
    - why scaling is managed in a so weird way that most application developers cannot deal with it, so that even a healthy and rapidly developed project like libreoffice still has broken scaling on multi monitor with the QT VCLs?
    - why cannot applications decide their own icon, so a lot of stuff remains with the generic "W" icon and Qt's `setWindowIcon` has been broken *by policy*?
    - why is there no standard way to deal with the system tray, so those developing for flatpack have such a hard time making icons appear there?  To mention a few, `sleek`, `spotube`, many other flatpacks applications cannot show the tray icon on Wayland/KDE and some of these applications had to go back to using X11 to be usable on plasma (spotube).

Getting somehow resigned...

> I understand your point.

I don't.

What exactly does this mean:

> Largely because at this point multi-monitor on X11 is a lost cause; it simply can't be made to work well with the level 
> of customization we offer users. 

Let's keep focused on this specific issue here.
First of all, we are talking about being able to see the desktop on a single screen which is the external one (with the built-in one disabled). I  understand how that counts as "multi-monitor", that's not my point; but this is not demanding some great level of customization, it's just the bare minimum of having a usable computer, and a laptop-as-a-desktop configuration has to be the second most common one among desktop computers nowadays if not the most common.

Now, are you saying that this is due to a bug in X11?
If so, where is the upstream bug report?
If not, then it's a bug in KDE and then you have no excuse not to fix it. I was using Gnome with the exact same setup (external monitor as the only active one, builtin monitor disabled) literally 15 years ago. I hate Gnome, it has all sort of issues (many "by design"), but I don't remember having a black desktop with it.

(In reply to Sergio from comment #19)
> I understand your point.
> 
> I have also started using the Wayland session that does not show this
> specific issue. Unfortunately, we are still in a trade-off phase, where one
> needs to decide whether the Wayland troubles are better than the X11
> troubles or the other way round. ... and there seems little that can be done
> on the KDE side.
On the contrary, Plasma's wayland session is improving rapidly, while its X11 session is frozen in stone, never to get any better ever again. The same is true of the X server upstream.


> In fact, most of the trouble I am experiencing with wayland seems to come
> from:
> 
> -  the total lack of standardization of common things in Wayland
Sounds like it's time for you to submit some Wayland protocols to fix this. :) 

> 
>     - why cannot there be a standard way to do session restore so plasma
> cannot do it?
It's still a work in progress; see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18. Once that's accepted, we'll add support for it.

>     - why cannot there be a cross-toolkit env variable to decide if
> applications should use X11 or Wayland and every toolkit has its own way, so
> launching applications via `ssh -X` which should work just fine using
> Xwayland does never work?
Because there are multiple toolkits and they never came to an agreement about a common environment variable to use. This sounds like it could be a good candidate for a new Wayland protocol.

>     - why isn't there a single cross-toolkit env variable to control scaling?
See above. But why is this needed? App developers don't need it because they just need to follow the wayland scaling protocols. So the only people who would use it are users, but then it should also not be needed since your DE of choice should take care of setting up the scaling infrastructure properly for all kinds of apps. If it doesn't, it's an issue with the DE.

>     - why Java applications won't obey scaling anyway so big commercial
> applications (MATLAB to mention one) are now almost unusable unless you use
> weird hacks like passing them through Xpra?
Without knowing which apps, I can't answer that question, but I suspect based on other scaling-related questions that your system is misconfigured based on old habits from X11 that aren't translating to a Wayland world.

> 
> - rather strange policy decisions
> 
>     - why can we have scaling only by 75-100-125-150 etc., what was the
> issue with specifying DPIs that enabled a much finer tuning;
You can set any scale value you want in the relevant KDE system settings page, not just multiples of 25%.

>     - why scaling is managed in a so weird way that most application
> developers cannot deal with it, so that even a healthy and rapidly developed
> project like libreoffice still has broken scaling on multi monitor with the
> QT VCLs?
LibreOffice with the QT VCL works just fine for me with a multi-monitor system where one monitor has 225% scale and another has 110% scale; I was using it this way just today. If it's not working for you, it sounds like your system is misconfigured.

>     - why cannot applications decide their own icon, so a lot of stuff
> remains with the generic "W" icon and Qt's `setWindowIcon` has been broken
> *by policy*?
I think you just answered your own question. But there is a draft Wayland protocol that would implement this functionality: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269

>     - why is there no standard way to deal with the system tray, so those
> developing for flatpack have such a hard time making icons appear there?  To
> mention a few, `sleek`, `spotube`, many other flatpacks applications cannot
> show the tray icon on Wayland/KDE and some of these applications had to go
> back to using X11 to be usable on plasma (spotube).
This isn't an X11/Wayland thing; there *is* a standard way to set a System Tray icon and KDE implements it.

(In reply to php4fan from comment #20)
> > I understand your point.
> 
> I don't.
> 
> What exactly does this mean:
> 
> > Largely because at this point multi-monitor on X11 is a lost cause; it simply can't be made to work well with the level 
> > of customization we offer users. 
> 
> Let's keep focused on this specific issue here.
> First of all, we are talking about being able to see the desktop on a single
> screen which is the external one (with the built-in one disabled). I 
> understand how that counts as "multi-monitor", that's not my point; but this
> is not demanding some great level of customization, it's just the bare
> minimum of having a usable computer, and a laptop-as-a-desktop configuration
> has to be the second most common one among desktop computers nowadays if not
> the most common.
> 
> Now, are you saying that this is due to a bug in X11?
> If so, where is the upstream bug report?
> If not, then it's a bug in KDE and then you have no excuse not to fix it. I
> was using Gnome with the exact same setup (external monitor as the only
> active one, builtin monitor disabled) literally 15 years ago. I hate Gnome,
> it has all sort of issues (many "by design"), but I don't remember having a
> black desktop with it.

I'm not saying it's due to a bug in X11 specifically. Rather, the way X11 handles multiple monitors makes it very hard for our code to interact with it in a way that isn't super buggy without sacrificing customizability. It's our own fault for being customizable, basically. As a result, it's buggy and no one in KDE wants to work on X11 multi-monitor support because it's an unpleasant thing to do, and everyone in KDE who has a multi-monitor setup has already moved to Wayland where it already works much better. Hence my suggestion that you do the same.

GNOME's lack of customizability makes their X11 multi-monitor support less buggy, but note that GNOME is currently scoping out removing X1 support entirely. You simply won't be able to rely on X11 for long. The whole industry is moving in the direction of abandoning it.  It is what it is. The good news is that multi-monitor support is largely fixed--or at least fixable--on Wayland because Wayland is much friendlier to work with when it comes to programming multi-monitor support.

Thanks Nate for the extended answer!

>> and there seems little that can be done on the KDE side.
> On the contrary, Plasma's wayland session is improving rapidly, while its X11 session is frozen in stone,
> never to get any better ever again. The same is true of the X server upstream.

In fact, I think that we meant the same thing. When I say that there is little that can be done on the KDE side, I mean that Plasma progressed vigorously on all it could do alone, but that there are remaining issues (often annoying ones) coming from things that are not in control of the KDE developers. From a total outsider, the impression is that: (i) those who decide on the protocols tend to prevent the introduction of some mechanisms because they have some strong views on the policies that should be adopted and not having a mechanism appears as a powerful way to prevent some policies (`setWindowIcon` is an excellent example); and (ii) coordination with toolkit developers is too loose, maybe because of imbalance on how the toolkits are considered.

>>  - why cannot there be a standard way to do session restore so plasma cannot do it?
> It's still a work in progress; see https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18. Once that's accepted,
> we'll add support for it.

Excellent news, particularly for systems that cannot sleep. Yet, again for an outsider, it seems amazing that 15 years after the initial release of the wayland protocols, the ability to save-restore a session in a standard way is still on the drawing board.

>>   - why cannot there be a cross-toolkit env variable to decide if applications should use X11 or Wayland and every toolkit has its own way,
>>  so launching applications via `ssh -X` which should work just fine using Xwayland does never work?
> Because there are multiple toolkits and they never came to an agreement about a common environment variable to use. This sounds like
> it could be a good candidate for a new Wayland protocol.

This is particularly nasty. One does ssh -X from host A to host B and launches an application on B. Because the application does not know it should run on X11, since there is no standard way to tell it to run on X11, it may end up believing it should use wayland. If the user has a wayland session on B, the application opens on the screen of B with no error reported on the ssh terminal session. That may get unnoticed and the application may stay there even for days, using resources, amplifying the attack surface of B, whatever. When the user unlocks B not remembering that there is such application, that application window may get unexpectedly exposing to others in the room.

>> - why can we have scaling only by 75-100-125-150 etc., what was the issue with specifying DPIs that enabled a much finer tuning;
> You can set any scale value you want in the relevant KDE system settings page, not just multiples of 25%.

Particularly interested in this. In the KDE system settings -> display configuration, I can move the scale slider only by multiples of 25%, how do I unlock that?

>>  - why isn't there a single cross-toolkit env variable to control scaling?
> See above. But why is this needed? 

Because in principle everything should, as you say, just work. But if adjustments are required having to remember "GDK_SCALE" "GDK_DPI_SCALE", "QT_SCALE_FACTOR" or whatever other variable is a mess.

> LibreOffice with the QT VCL works just fine for me with a multi-monitor system where one monitor has 225% scale and another
> has 110% scale; I was using it this way just today. If it's not working for you, it sounds like your system is misconfigured.

No, unfortunately there is a confirmed bug about this setup. See: https://bugs.documentfoundation.org/show_bug.cgi?id=141578

>> - why Java applications won't obey scaling anyway so big commercial applications (MATLAB to mention one) are now almost unusable
>> unless you use weird hacks like passing them through Xpra?
> Without knowing which apps, I can't answer that question, but I suspect based on other scaling-related questions that your system is
> misconfigured based on old habits from X11 that aren't translating to a Wayland world.

Unfortunately, many large cross-platform scientific applications use java front-ends (MATLAB, SCILAB to mention two that almost everybody knows) and all AWT/Swing applications cannot do scaling properly on Wayland (while it was obeying the DPI setup in X11). AWT/Swing can do scaling but only at integer factors which almost invariably makes things either too big or too small. The only reasonable way to use these applications is via `xpra`'s `run_scaled` helper that kills performance and blurs the display slightly. To me, and I think for many in the scientific community, large Java based scientific applications are the largest obstacle to completing the migration to Wayland. This is definitely one of those trade-offs mentioned at the beginning, where KDE developers cannot help.

If you would like to experiment, please try scilab, that is open source.

>> - why cannot applications decide their own icon, so a lot of stuff remains with the generic "W" icon and Qt's `setWindowIcon` has been
>> broken *by policy*?
> I think you just answered your own question. But there is a draft Wayland protocol that would implement this functionality:
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269

Unfortunately, the fact that there is a draft protocol does not mean it will be merged. There seems to be a lot of resistance against this one (and I really tend to find it rather ideological). You surely know the discussion in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/52. Even from the protocol developers more open to it the attitude is "[even if this is merged] This [ext] protocol won't be something you can expect to see everywhere. I'd suspect gnome would not implement this". I would not bet on this. Seems a classical example of not providing mechanisms as a way to force a policy.

> This isn't an X11/Wayland thing; there *is* a standard way to set a System Tray icon and KDE implements it.

Looks like there is a difference in between how this is managed in X11 and in Wayland. For X11, the application can pass either the pixmap file or the pixmap data for the tray icon. On Wayland, only the pixmap file. This is not friendly to containerized (flatpack) applications where the file is not available out of the container. Please see the discussion on https://github.com/flathub/com.github.KRTirtho.Spotube/pull/51 for an example of an applications that had to go back to being X11 only. The thread is long, the important part is at the end.

I apologize for having slightly abused of this bug report to provide some links and practical cases. Hope you'll find them interesting, though.