Description of problem: Plasma Wayland session is default even with nomodeset present which breaks rendering of the session. GNOME runs on Wayland even with nomodeset, but, KDE Plasma isn't capable of that it seems and used to default to Xorg with nomodeset. Version-Release number of selected component (if applicable): 0.19.0^git20220921.21e965a-1 How reproducible: Always Steps to Reproduce: 1. Boot Fedora KDE Spin on x86 UEFI with nomodeset 2. Log in 3. Actual results: Black screen with bunch of crashes in the background Expected results: Working session Additional info:
Proposed as a Blocker for 37-final by Fedora user frantisekz using the blocker tracking app because: KDE Plasma with Basic video driver is borked on UEFI (simpledrm).
Please note: Frantisek reported that just booting the KDE Live image works OK (sddm is skipped there because of autologin), it is only broken when booting the installed system.
Relevant logs guess: Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: No backend specified through command line argument, trying auto resolution Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: MESA-LOADER: failed to open simpledrm: /usr/lib64/dri/simpledrm_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib64/dri, suffix _dri) Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: failed to load driver: simpledrm Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: kmsro: driver missing Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: OpenGL vendor string: Mesa/X.org Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: OpenGL renderer string: llvmpipe (LLVM 15.0.0, 256 bits) Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: OpenGL version string: 4.5 (Core Profile) Mesa 22.2.0 Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: OpenGL shading language version string: 4.50 Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: Driver: LLVMpipe Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: GPU class: Unknown Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: OpenGL version: 4.5 Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: GLSL version: 4.50 Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: Mesa version: 22.2 Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: Linux kernel version: 5.19.16 Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: Requires strict binding: no Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: GLSL shaders: yes Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: Texture NPOT support: yes Oct 25 10:54:00 fedora kwin_wayland_wrapper[1552]: Virtual Machine: no Oct 25 10:54:00 fedora kwin_wayland[1552]: kwin_xkbcommon: XKB: inet:323:58: unrecognized keysym "XF86EmojiPicker" Oct 25 10:54:00 fedora kwin_wayland[1552]: kwin_xkbcommon: XKB: inet:324:58: unrecognized keysym "XF86Dictate" Oct 25 10:54:00 fedora kwin_wayland[1552]: kwin_wayland_drm: Failed to create framebuffer for EglGbmLayerSurface: Invalid argument Oct 25 10:54:00 fedora kwin_wayland[1552]: kwin_wayland_drm: Failed to create gamma blob! Invalid argument Oct 25 10:54:00 fedora kwin_wayland_wrapper[1617]: (WW) Option "-listen" for file descriptors is deprecated Oct 25 10:54:00 fedora kwin_wayland_wrapper[1617]: Please use "-listenfd" instead. Oct 25 10:54:00 fedora kwin_wayland_wrapper[1617]: (WW) Option "-listen" for file descriptors is deprecated Oct 25 10:54:00 fedora kwin_wayland_wrapper[1617]: Please use "-listenfd" instead. Oct 25 10:54:00 fedora kernel: simple-framebuffer simple-framebuffer.0: [drm] No conversion helper from XR30 little-endian (0x30335258) to XR24 little-endian (0x34325258) found. Oct 25 10:54:00 fedora kwin_wayland_wrapper[1617]: Failed to initialize glamor, falling back to sw Oct 25 10:54:01 fedora kwin_wayland_wrapper[1622]: The XKEYBOARD keymap compiler (xkbcomp) reports: Oct 25 10:54:01 fedora kwin_wayland_wrapper[1622]: > Warning: Unsupported maximum keycode 708, clipping. Oct 25 10:54:01 fedora kwin_wayland_wrapper[1622]: > X11 cannot support keycodes above 255. Oct 25 10:54:01 fedora kwin_wayland_wrapper[1622]: Errors from xkbcomp are not fatal to the X server
Created attachment 1920323 [details] journal
I cannot reproduce this on virt-manager. Does it requires a specific hardware?
When I start a live-usb on basic video driver, on a BIOS hardware notebook, then logout (since live session goes directly trhough autologin) then SDDM is fine.
Tested too on a UEFI hardware notebook (ACER aspire), same procedure: 1. Start computer with usb live and choose "basic graphics mode" 2. Go to menu => leave => log out 3. Confirm 4. SDDM starts correctly, in X11 mode.
I can confirm the bug here, but it's not really as described. SDDM itself isn't the problem. It's running KDE on Wayland with nomodeset that's broken. This is how it goes for me: 1. Boot live image in basic graphics mode. SDDM doesn't show its UI but does run (it always runs), and runs KDE in X.org mode. This works, you can install. 2. Boot installed system. SDDM runs and shows its UI. SDDM itself is running on X.org (it is configured to always do this). The default entry in the session list is "Plasma (Wayland)". If you leave this set and log in, you get a black screen with a cursor. 3. Reboot. Change the entry in the SDDM session list to "Plasma (X11)" and log in. This works, you get a working desktop running on X.org. I also tested F36 for comparison. F36 works. The difference is not (as Frantisek suggests) that in F36 SDDM defaulted to running Plasma on X in this case: F36 also defaults to "Plasma (Wayland)". But on F36, that works fine. You get a working desktop using the llvmpipe driver. So for some reason, in F37, Plasma-on-Wayland does not work when booted with nomodeset. In F36 it did. I don't know why we get Plasma-on-X when booting live but Plasma-on-Wayland when booting the installed system, but that seems like a secondary point. Both used to work.
The specific version reported is still on updates-testing repo. I think that the version on the Fedora repo may work and that could be the cause some of you can reproduce the bug and others not. Particularly those who are testing the live image directly.
I tested here a new scenario: 1. Boot the live usb 2. At the grub menu, choose the first line "start F37 KDE" and press "e" 3. Changed the linux line adding "nomodeset" before "rhgb quiet" 4. Started normaly at basic video driver 5. Log out 6. SDDM works normaly, with X11.
No. I'm testing with just the RC 1.4 live image and reproduce the bug there no problem. The confusion is, I think, because of the slightly wrong initial description. Geraldo's test would be 'valid' if the bug were as Frantisek described it, but it's not, so Geraldo's test isn't really telling us anything, because he's not actually doing the thing that fails (launch Plasma-on-Wayland).
Geraldo: that is still not a valid test. You need to be launching Plasma - the actual desktop - on Wayland. This is what happens by default on first boot after you install the system, if you go that far.
(In reply to Adam Williamson from comment #11) > No. I'm testing with just the RC 1.4 live image and reproduce the bug there > no problem. The confusion is, I think, because of the slightly wrong initial > description. Geraldo's test would be 'valid' if the bug were as Frantisek > described it, but it's not, so Geraldo's test isn't really telling us > anything, because he's not actually doing the thing that fails (launch > Plasma-on-Wayland). Adam, I can confirm that if I choose to start plasma-wayland at sddm with basic video driver, it crash, as you described.
(In reply to Adam Williamson from comment #12) > Geraldo: that is still not a valid test. You need to be launching Plasma - > the actual desktop - on Wayland. This is what happens by default on first > boot after you install the system, if you go that far. OK, I confirm that with nomodeset and wayland choosed at SDDM, it shows only a black screen.
I believe this only affects UEFI systems (I tested a BIOS system earlier today and it worked fine), adjusting summary.
(In reply to Kamil Páral from comment #15) > I believe this only affects UEFI systems (I tested a BIOS system earlier > today and it worked fine), adjusting summary. Will redo the test here on the BIOS machine, folowing Adam's systematic to see what happens.
(In reply to Kamil Páral from comment #15) > I believe this only affects UEFI systems (I tested a BIOS system earlier > today and it worked fine), adjusting summary. Yeah, I confirmed that too. On a BIOS hardware, it doesn't even show the option to login in a plasma-wayland session at SDDM after installation.
BTW, when I say "F36" above, I mean the original release F36 live image. I tested installing from that and booting. I did not update it at all. I don't know if any F36 post-release updates broke this there.
F36 does also show the simpledrm errors, so those aren't the problem. F36 also still works when updated to kernel 5.19, and F37 still doesn't work with kernel 6.1 from Rawhide, so the kernel doesn't seem to be the problem here.
If I upgrade plasma* , qt* , kde* , kf5* and breeze* on F36, the problem starts happening there too. F36 started out with Plasma/KDE 5.24.3 ; the upgrade upgraded it to 5.25.5 .qt5 went from 5.15.3 to 5.15.6. kf5 bits went from 5.91.0 to 5.99.0. Somewhere in that blob of updates is where the problem started, and it's definitely in Plasma-related stuff somewhere.
Created attachment 1920413 [details] journal messages from a 'good' boot on original F36
Created attachment 1920414 [details] journal messages from a 'bad' boot on updated F36
I dunno how significant they are, but some messages from kwin_wayland_wrapper definitely differ. Stripping out some identical messages, on 'good', we get this: Oct 25 15:27:28 fedora kwin_wayland[1419]: kwin_wayland_drm: drmModeAddFB2 and drmModeAddFB both failed! Invalid argument Oct 25 15:27:28 fedora kwin_wayland[1419]: kwin_wayland_drm: Failed to create dumb buffers for swapchain! Oct 25 15:27:28 fedora kwin_wayland[1419]: kwin_wayland_drm: Failed to create gamma blob! Invalid argument On 'bad', we get this: Oct 25 16:05:46 fedora kwin_wayland[1262]: kwin_wayland_drm: Failed to create framebuffer for EglGbmLayerSurface: Invalid argument Oct 25 16:05:46 fedora kwin_wayland[1262]: kwin_wayland_drm: Failed to create gamma blob! Invalid argument Oct 25 16:05:46 fedora kernel: simple-framebuffer simple-framebuffer.0: [drm] No conversion helper from XR30 little-endian (0x30335258) to XR24 little-endian (0x34325258) found.
There are another 10 instances of the "Failed to create framebuffer for EglGbmLayerSurface: Invalid argument" error in 'bad', and no instances of that error in 'good'.
Installing the big pending KDE update for F37 - https://bodhi.fedoraproject.org/updates/FEDORA-2022-23a0a34ea5 - does not fix this.
The "Failed to create framebuffer for EglGbmLayerSurface" message seems to come from ef97158f9 , which I don't *think* could cause significant behaviour change. The "drmModeAddFB2 and drmModeAddFB both failed!" message was removed in c65c82239 , which, I mean, I guess it could be involved, but, it clearly *intended* to refactor the message away. So I'm not sure either of those messages is the key here...
The "No conversion helper" messages look like they actually come from the kernel, from this patch: https://lore.kernel.org/all/20220425075939.30450-4-tzimmermann@suse.de/T/ which kinda just adds the warning message to a codepath that previously existed, so again, may not be the key here. But that leaves us distinctly...keyless. Hmm.
Filed upstream at https://invent.kde.org/plasma/kwin/-/issues/121 .
(In reply to Adam Williamson from comment #27) > The "No conversion helper" messages look like they actually come from the > kernel, from this patch: > > https://lore.kernel.org/all/20220425075939.30450-4-tzimmermann@suse.de/T/ > > which kinda just adds the warning message to a codepath that previously > existed, so again, may not be the key here. But that leaves us > distinctly...keyless. Hmm. Out of curiosity, does it work if you force a video mode for simpledrm? I didn't even know you could do that before reading that patch...
Tried `nomodeset video=1024x768-16` , but it didn't seem to change anything.
+8 in https://pagure.io/fedora-qa/blocker-review/issue/986 , marking accepted.
So, some movement here. We more or less know what's going on now. Basically - as I understand it - kwin is relying on the DRM driver to tell it what "formats" - these are DRM pixel formats, https://afrantzis.com/pixel-format-guide/drm.html - it can handle. simpledrm - which is the driver we're using on the `nomodeset` on UEFI path - is telling kwin it supports two 10-bit color formats, DRM_FORMAT_XRGB2101010 and DRM_FORMAT_ARGB2101010; this was added in https://patchwork.freedesktop.org/patch/466410/?series=97029&rev=3 by Hector Martin, which appears to be intended to support the newfangled ARM-based Macs, whose bootloader framebuffer apparently always uses one of these formats. simpledrm says that its list is "in order of preference", though I can't find any documentation that suggests "the list provided by the driver is in order of preference" is an actual documented "thing" about DRM drivers. kwin does not just read the list in the order it comes from the driver; it has its own logic - https://invent.kde.org/plasma/kwin/-/blob/master/src/backends/drm/drm_egl_layer_surface.cpp#L222-234 - which prefers formats with alpha channels over formats without, and formats that use 10-bit color over formats that don't. So kwin winds up using the 10-bit color format. However, on my system (and presumably on František's and Geraldo's systems, and thus likely on lots of other systems) it looks like what Xaver (upstream kwin dev) calls the "underlying" framebuffer - which presumably is the one that was set by the firmware or bootloader or whatever - is using an 8-bit color format, DRM_FORMAT_XRGB8888. simpledrm can convert *from* XRGB8888 *to* XRGB2101010 - that was added in the same patch series from Hector - but it can't convert *from* XRGB2101010 *to* XRGB8888. That's what the "No conversion helper from XR30 little-endian (0x30335258) to XR24 little-endian (0x34325258) found." message is telling us. And that's why we get no output. The patch we (mostly Xaver) came up with upstream to debug this: https://invent.kde.org/plasma/kwin/-/issues/121#note_549114 has the effect of making kwin prefer 8-bit formats over 10-bit, and with that patch, things "work" again on my test system. Potentially we could tweak it a bit to only do that on simpledrm and try using that, even though it's probably not the ultimate "correct" fix. But I'd worry that might possibly make things not work on the fancy new ARM Macs. I don't know if anyone has one to test on. Unsolved questions: is it kosher for kwin to be sorting the formats list like this, or should it just use the order it gets from the drm driver? Also, still, *why* did this break between Plasma 5.24.3 and 5.25.5? The 10-bit color support was already in Plasma 5.24.3. My best guess is that there was previously some additional check that the selected format actually works, and that was saving us, but it got removed; I'm looking into that again now I have a better idea where to look. If so, an option would be to try and restore that check. CCing Hector (hi Hector!), also Justin and Adam/Dave, since we're into kernel graphics stuff now.
> I'd worry that might possibly make things not work on the fancy new ARM Macs. I don't know if anyone has one to test on. Fortunately Lukas Brabec has one. I assume he'd rather test something just from a Live image, if possible, though.
This is interesting. simpledrmfb advertises these formats: DRM_FORMAT_XRGB8888, DRM_FORMAT_ARGB8888, // treated as X DRM_FORMAT_RGB565, DRM_FORMAT_RGB888, DRM_FORMAT_XRGB2101010, DRM_FORMAT_ARGB2101010, // treated as X ... but the only supported conversions are: XRGB8888 -> RGB565, RGB888, XRGB2101010 RGB888 -> XRGB8888 RGB565 -> XRGB8888 So the only safe format to use is XRGB8888. If you were to pick RGB888 or RGB565, you would also fail unless the underlying FB is that or XRGB8888. I just happened to introduce another matrix column that kwin happens to consider as preferred, and is also incomplete. I would say there are two things to fix here: kwin should actually use the formats in preferred order, at the very least for "dumb" drivers with software format conversion (which will fix this bug on that side, and avoid possibly costly kernel-mode conversions on some platforms), and the kernel shouldn't advertise formats it doesn't have conversion helpers for, and should always list the native format first (which will also fix the bug on that side). I'll try writing up a patch for the latter.
(In reply to Hector Martin from comment #34) > This is interesting. simpledrmfb advertises these formats: > > DRM_FORMAT_XRGB8888, > DRM_FORMAT_ARGB8888, // treated as X > DRM_FORMAT_RGB565, > DRM_FORMAT_RGB888, > DRM_FORMAT_XRGB2101010, > DRM_FORMAT_ARGB2101010, // treated as X > > ... but the only supported conversions are: > > XRGB8888 -> RGB565, RGB888, XRGB2101010 > RGB888 -> XRGB8888 > RGB565 -> XRGB8888 > > So the only safe format to use is XRGB8888. If you were to pick RGB888 or > RGB565, you would also fail unless the underlying FB is that or XRGB8888. I > just happened to introduce another matrix column that kwin happens to > consider as preferred, and is also incomplete. > Exactly, that's the issue. We need a drm_fb_xrgb2101010_to_xrgb8888() format conversion helper. I'll write a patch for that. > I would say there are two things to fix here: kwin should actually use the > formats in preferred order, at the very least for "dumb" drivers with > software format conversion (which will fix this bug on that side, and avoid > possibly costly kernel-mode conversions on some platforms), and the kernel Agreed. The problem is that Kwin was changed to prefer 10-bit color depths: https://invent.kde.org/plasma/kwin/-/commit/f2b29e3555955a3f3e72f3098454833b71cde06b > shouldn't advertise formats it doesn't have conversion helpers for, and > should always list the native format first (which will also fix the bug on > that side). I'll try writing up a patch for the latter. That's already the case, take a look to drm_fb_build_fourcc_list(): https://elixir.bootlin.com/linux/v6.1-rc2/source/drivers/gpu/drm/drm_format_helper.c#L835 So DRM_FORMAT_XRGB8888 is listed first due being the native format, it's just that Kwin ignores that and prefers DRM_FORMAT_XRGB2101010 that's listed by the simpledrm driver (but there's no emulation for that as you mentioned). There's a current discussion in #dri-devel about only exposing native + XRGB24 for backward compatibility with user-space that assumes that. I think that's the correct approach but regardless will add a rgb30-to-rgb24.
(In reply to Kamil Páral from comment #33) > > I'd worry that might possibly make things not work on the fancy new ARM Macs. I don't know if anyone has one to test on. > > Fortunately Lukas Brabec has one. I assume he'd rather test something just > from a Live image, if possible, though. I can compose Fedora Asahi images on-demand if needed, but the process to boot one is kind of involved at the moment...
marcan posted to dri-devel two versions of a fix for this bug. v1: https://lists.freedesktop.org/archives/dri-devel/2022-October/377407.html v2: https://lists.freedesktop.org/archives/dri-devel/2022-October/377442.html
thanks a lot for the quick response, folks! About the order: as I mentioned I saw the comment that asserts that the list is in "order of preference", but...ultimately that's just a comment in the source, right? Is there a more clear upstream reference that says "format lists are in order of preference and consumers should treat them as such"? I think Plasma may have just taken them in order at some point, but that was tweaked to this logic on the basis that it's better to use formats with greater capabilities if poosible...
This is reproducible on UEFI based aarch64 hardware as well (! M1 based mac's). And seems pretty clearly a kernel bug, because it falsely advertises a mode that doesn't exist on the hardware in question. OTHO, it is hard to consider this particularly severe because even with gdm it's possible to just select the Plasma (X11) option, and it works. In the past sddm/etc would have just removed the wayland options in this case (because of lack of drm).
(In reply to Adam Williamson from comment #38) > thanks a lot for the quick response, folks! > > About the order: as I mentioned I saw the comment that asserts that the list > is in "order of preference", but...ultimately that's just a comment in the > source, right? Is there a more clear upstream reference that says "format > lists are in order of preference and consumers should treat them as such"? > Indeed, that's mentioned nowhere in the DRM/KMS documentation so is not clear to me that is an expected behavior for drivers to list the supported formats in order of preference. The simpledrm driver advertises some formats that are not supported by the firmware set-up framebuffer but it does some software emulation. Consensus seems to be that this is wrong and in any case the only format that should be emulated for maximum compatibility is XRGB8888. So it may be that all the others advertised formats would be removed in the future. > I think Plasma may have just taken them in order at some point, but that > was tweaked to this logic on the basis that it's better to use formats with > greater capabilities if poosible... Yeah, I think that Kwin is not to be blamed here since user-space is free to pick any format that is advertised by a driver. The discussion was whether the fix should be to implement emulation for the advertised format or remove it to only be advertised in platforms that do support it natively. There was a lengthy discussion in #dri-devel channel, but most people involved seems to agree to what marcan proposed as the fix.
Updates here: there are now proposed fixes both on the kwin side: https://invent.kde.org/plasma/kwin/-/commit/b3d0698126ac7bd992d253fc3db344bb3137bf6f and the kernel side: https://lists.freedesktop.org/archives/dri-devel/2022-October/377442.html so setting POST. The kwin change is quite large and probably not appropriate for backporting. The kernel fix is fairly clear and seems like it *ought* to be safe (...famous last words), in that anything it no longer allows could not possibly have worked anyhow. It seems on track to land upstream, and Justin intends to backport it. However it's not a straightforward backport as it depends on helpers added in 6.1. Still, that's likely the path we're taking.
FEDORA-2022-c4057cabb4 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c4057cabb4
(In reply to Fedora Update System from comment #42) > FEDORA-2022-c4057cabb4 has been submitted as an update to Fedora 37. > https://bodhi.fedoraproject.org/updates/FEDORA-2022-c4057cabb4 This update seems to fix the bug. With this new kernel I just managed to start a fine plasma-wayland session on the same setup previous kernel hanged.
Frantisek, can you please test on the same setup? Thanks.
If it wasn't clear, https://bodhi.fedoraproject.org/updates/FEDORA-2022-c4057cabb4 fixes the issue on the setup that I'd encountered it on originally.
FEDORA-2022-c4057cabb4 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.