Starting Wayland-KDE on FC39

[Duncan]

Dave Close posted on Sun, 19 Nov 2023 22:39:29 -0800 as excerpted:

> Until FC39, I had only run Wayland on one of my machines, not even
> trying to bring it up on the others. Since I intensely dislike the
> graphic login, I found a way to start it from a virtual terminal like I
> normally start X11. Instead of "startx", I have a short script I call
> "startw" that contains only the single line, "/usr/bin/dbus-run-session
> /usr/bin/startplasma-wayland". This worked on FC38 and still works on
> some other of my machines with FC39.

dbus-run-session startplasma-wayland (scripted, script named the single 
letter "k" for kde, here) is the way I do it here, too, on gentoo, and I 
can confirm it's working with the current kf5/qt5-locked live-git packages 
from the gentoo/kde testing overlay.  As it happens I don't even have an X 
other than xwayland installed (tho I do have weston installed as a basic 
low-deps backup wayland compositor, in case my after-all live-git-built 
kwin/plasma compositor bugs out).  And I've not even had a *DM installed 
since switching to gentoo in 2004 (from mandrake cooker/testing, where a 
pre-release bug with whatever *DM it ran at some point killed the GUI 
login, so I switched to CLI login and startx, and never looked back).

> Now on the same machine with FC39 (upgraded with system-upgrade) this no
> longer works. Instead, it produces 248 lines of output and then
> terminates. Reviewing those lines, it appears that it is complaining
> about, 'failed to open drm device at "/dev/dri/card0"' and 'No suitable
> DRM devices have been found'. I'm not sure what device that refers to
> but there seems to be some indication that it is my display. The display
> certainly works fine for the virtual terminal I use to run this script,
> and it also works fine for X11 if I run "startx".

Confirming that in this context, drm/dri is display (IIRC display 
rendering manager and kernel display rendering interface).

Generically (as in, not just for displays), device-open failure very 
frequently is permissions-related, and that's where I'd start looking as 
I'm betting that's your problem here too.  But your situation will be 
somewhat more complex than mine, as fedora uses policykit, etc, to setup 
permissions for the logged-in user, and I've managed to avoid that, no 
policykit installed, here on gentoo.

(FWIW, that's perhaps the biggest benefit of gentoo's scripted from-source 
builds, being able to control such things at build-time where dependencies 
get decided.  Of course the tradeoff is build-to-install time, but with 
two decades this spring of gentoo behind me, I obviously find it worth it 
here.)

Anyway, sans policykit/consolekit/etc, the solution to device permissions 
issues is normally to add the appropriate users to the appropriate group 
(see what the device group is set as and try that, if your user isn't 
already in that group), or possibly to change the udev config to loosen 
the permissions a bit (does the device need to be writable by users in 
that group?).  Maybe that still applies to (and doesn't get overwritten 
by) *kit installations?

[snip some good troubleshooting you've already done]
 
> This machine is intended to run an application that only works on
> Wayland (Waydroid) so at this point I'm stimied. Any suggestions would
> be very helpful.

If you need more permissions help I'd suggest the fedora help channels as 
they'll be more familiar with the *kit config.

Also, particularly if you're on nvidia, it's possible the graphics card/
chip make and generation might affect things, as their proprietary stuff 
tends to ignore the linux standards and make its own rules, so the 
instructions may be somewhat different for it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman