Ok, initially I was looking to get sddm itself to fallback to X if the wayland display server failed to start, but fedora is carrying patches to repeatedly (re)start on failures due to the bugs from last year where sddm was starting before CanGraphical=Yes became true.

At which point it seemed like tweaking the fedora patches a bit might be the right idea, and using nomodeset as the key to forcing X11 was a bit hacky IMHO last time around, and only really applies in a narrow set of circumstances. Better to actually wait for the DRM subsystem to become available. So maybe a patch like:

diff --git a/61-sddm-plasmawayland.rules b/61-sddm-plasmawayland.rules
index 35e18b3..f58a459 100644
--- a/61-sddm-plasmawayland.rules
+++ b/61-sddm-plasmawayland.rules
@@ -1,3 +1,3 @@
 # disable Wayland if modesetting is disabled
-RUN+="/usr/bin/rm -f /etc/sddm/hide-wayland-sessions"
-IMPORT{cmdline}="nomodeset", RUN+="/usr/bin/touch /etc/sddm/hide-wayland-sessions"
+ACTION=="add", SUBSYSTEM=="mem", KERNEL=="zero", RUN+="/usr/bin/touch /etc/sddm/hide-wayland-sessions"
+ACTION=="add", SUBSYSTEM=="drm", KERNEL=="card[0-9]", RUN+="/usr/bin/rm -f /etc/sddm/hide-wayland-sessions"

is a better choice, although I worry there may be a X11->wayland race now if it is still possible for sddm to start before the graphics subsystem was initialized. Of course, this is a bit "hacky" too as we are waiting for a /dev/zero and using it as a single-shot.

Is the problem that *SDDM* doesn't show up at this point? Or that the desktop fails to load once you login? Because last time, the problem wasn't with SDDM (which still uses X11).

(In reply to Neal Gompa from comment #2)
> Is the problem that *SDDM* doesn't show up at this point? Or that the
> desktop fails to load once you login? Because last time, the problem wasn't
> with SDDM (which still uses X11).

For proper context of my comment, bug 1952431 was about the Plasma Desktop being unable to load to the default Wayland session when kernel modesetting wasn't available (KDE supports fbdev but it's broken on Fedora for some reason that nobody is able to figure out). The fix there was to make SDDM hide all Wayland sessions when kernel modesetting is disabled.

However, SDDM *always* came up because it's running in X11 currently. This situation with Wayland sessions is a blocker for migrating SDDM to Wayland. I asked for SimpleDRM to be enabled in bug 1986222 so that we could re-evaluate how Wayland enablement was going to go in situations like that one.

What *this* sounds like is that the X11 server isn't correctly starting up so that the SDDM greeter loads?

Yes, the problem is that SDDM doesn't show up. I'm left with a blank screen when it starts. Dropping a `DisplayServer=x11` in the sddm.conf file fixes it. So I went looking at how it fallsback, but I found https://github.com/sddm/sddm/blob/690be076a46a5fe5ac7d005dd8da682d3de2523c/src/daemon/Display.cpp#L66 which further added to my confusion because it appears to be defaulting to X11 as you mention.

But putting a DisplayServer=x11 in the sddm.conf file fixes it, as does that udev rule change above. So somehow it does appear that wayland is being defaulted, which is when I started looking at fedora patches.

Although maybe the problem is that it is X11, but missing the m_terminalId? But then how does it normally work?

BTW: I think that udev rule needs to be fixed one way or the other. What it's doing is hammering the crap out of the filesystem by (trying) to remove the hide-wayland-sessions on every single udev event. If nomodeset is actually set, then it repeatedly removes the file, and recreates it for every single udev event in the machine.

Edit the subject, because the hide-wayland-sessions bit doesn't really seem to have anything to do with it. Xorg is running on /dev/fb0 despite it not having master-of-seat set, which keeps CanGraphical from being set on seat0. And at least on the first run, that keeps sddm from even trying to start X. Turns out though, that even DisplayServer=x11 probably doesn't have an effect.

What is happening though is that on first boot, it appears to fail to create the seat, which means it never tries to start X nor Wayland. On subsequent systemctl isolate calls it works pretty consistently, but given that CanGraphical isn't set it appears the only way for X to successfully start is if the Logind::isAvailable() check fails during sddm startup.

So, it seems org.freedesktop.login disappears for a short bit during systemctl isolate operations.

dbus-send --system --print-reply --dest=org.freedesktop.DBus  /org/freedesktop/DBus org.freedesktop.DBus.ListNames
method return time=1634681005.328363 sender=org.freedesktop.DBus -> destination=:1.17 serial=4294967295 reply_serial=2
   array [
      string "org.freedesktop.DBus"
      string ":1.0"
      string ":1.1"
      string ":1.2"
      string ":1.3"
      string ":1.4"
      string ":1.5"
      string ":1.6"
      string ":1.7"
      string ":1.8"
      string ":1.9"
      string ":1.10"
      string ":1.11"
      string ":1.12"
      string ":1.13"
      string ":1.14"
      string ":1.15"
      string ":1.16"
      string ":1.17"
      string "net.hadess.SwitcherooControl"
      string "org.freedesktop.Avahi"
      string "org.freedesktop.DisplayManager"
      string "org.freedesktop.NetworkManager"
      string "org.freedesktop.PolicyKit1"
      string "org.freedesktop.RealtimeKit1"
      string "org.freedesktop.home1"
      string "org.freedesktop.machine1"
      string "org.freedesktop.problems.daemon"
      string "org.freedesktop.systemd1"
   ]


Which is why its working at all. There is a seat discovery race that causes seat0 to be created regardless of CanGraphical=true.

Fixed the title to reflect the actual problem

Created attachment 1835277 [details]
Blocks waiting for logind, and adds a fallback event to start seat0

Ok, I "fixed" it. 

I've added a bit of code to block sddm startup if logind isn't yet available. This breaks it 100% of the time because the seat0 then never gets created because none of them ever become CanGraphical. So, in addition, a timer is set at 5 seconds, and if none of the seats are cangraphical it goes ahead and creates one anyway as it was doing if logind wasn't available.

The first part is really a bug with systemd/systemd-logind and sddm dependencies, because logind probably shouldn't be marked active/running until its fully registered on dbus, and sddm needs to be dependent on that status, possibly with the BindsTo= (which didn't seem sufficient when I was mesing with it yesterday).

The second one is really a systemd-udev rules bug, but I don't see how to fix that either because of the fbX vs /dev/dri/cardX race in the kernel which is currently being worked around for the nomodeset case but none of the others really short of adding things to the hwdb, which I'm lothe to do at the moment (because it can change if the only problem is that the driver hasn't landed yet).

And the reason BindsTo= doesn't work (and in fact makes it worse) is because systemd thinks the service is _running_ while it's still being stopped from the isolate command. So the sequence is something like: stop all the services including logind, logind hasn't yet stopped, but then systems starts processing the startup sequence and checks the current state (still visible on dbus) to go ahead and start sddm. Sddm then starts, and notices that logind isn't running... Except when the BindsTo is in there, so does systemd, and it promptly kills sddm, and doesn't restart it (despite the restart in the sddm unit file).

Note that https://bugzilla.redhat.com/show_bug.cgi?id=2016310 is about this breaking even in the 'nomodeset' case again. I'm going to see if this patch fixes that. Jeremy, do you think this patch is shippable, or is it more of a PoC hack that we should improve somehow before using it?

I have another version, which checks for /dev/fb0 before starting the seat, and decreases the dbus/login1 timeouts. 

I think it is pretty solid as is for fedora (although I would like to update the udev rule and add a comment to the sddm.sysconfig as well).

That logind1 dependency problem desperately needs fixing, and should probably be brought up with the systemd folks but I can't personally see how to fix it at the moment.

The cangraphical problem should over the long term go away with simpledrm. 

So, yah I think this patch is reasonable as a short term fix since I don't see how to fix the problem upstream at the moment. It shouldn't make things worse...

Can you attach the "other version" if it's better? Thanks! Note I did test to see if this fixes 2016310, and it doesn't - even with this patch applied, booting with 'nomodeset' still gets a black screen at SDDM startup...

Created attachment 1836078 [details]
Patch to sddm rpm package

The above patch is what I'm building local sddm rpms with now. It contains a slightly tweaked version of the logind/default start patch listed here, the udev rule listed here, as well as a couple minor commented out tweaks to the fedora provided config files to document how to debug sddm as well as change the default X11/Wayland startup.

I can create a pull request if that is easier, otherwise, this can be tested with a debug build here: https://koji.fedoraproject.org/koji/taskinfo?taskID=77673924

FEDORA-2021-631306a178 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178

FEDORA-2021-631306a178 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-631306a178`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-631306a178 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178

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

FEDORA-2021-631306a178 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-631306a178`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2021-631306a178 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

At Raspberry Pi 3 Model B Vi.2
I run Fedora 35
I have the same black screen with mousecursor.

I tryed as user:
$ systemctl --user status plasma-plasmashell.service
..
Loaded: loaded (/usr/lib/system/user/plasma-plasmashell.service: disabled: vendor preset: disabled)
Active: inactive (dead)

I followed the Ubuntu suggestions of:
https://askubuntu.com/questions/181774/black-screen-after-instalation-of-kde-desktop
but did not found any of KDE configuration files, containing anything like "--desktop"
nor any reasonable "autostart" files like:
~/.kde/share/autostart
/etc/xdg/autostart/*
~/.config/kde.org
/usr/share/autostart
~/.gtkrc-2.0-kde4
~/.kde/share/config/kdeglobals

sddm.service was allready running but I tried:
login as user and
$ systemctl start sddm.service
with the result, that I was called for the password on command line
but still in command line mode
 
have done: 
upgrade .. --advisory=FEDORA-2021-b71b8a85c8

I tried the insertion of "DisplayServer=x11" under [General] in /etc/sddm.conf
reboot
without any result

afterwards I made an system upgrade to Fedora 36:
system-upgraded to 36 at 2021-11-28 

and checked the need of:
upgrade .. --advisory=FEDORA-2021-631306a178
with result: nothing to do

I still have the black screen with the mousecursor.
$ systemctl --user status plasma-plasmashell.service
..
Loaded: loaded (/usr/lib/system/user/plasma-plasmashell.service: disabled: vendor preset: disabled)
Active: inactive (dead)

I coudn't find even an overview of sddm Xorg wayland .. to dig in deeper.