[As a courtesy this initial reply is posted to the mailing list and mailed
directly to the original poster. Please send followups to the list, as I
will.]
欧阳 春晖 posted on Sun, 4 Dec 2022 05:17:41 +0000 as excerpted:
> Hi everyone.
> I'm recently trying to log into KDE using wayland on my Gentoo/Linux PC,
> I'm using a NVIDIA graphics card with a GTX 750, and using closed source
> drivers,
Gentoo here too, and I'm running kde/plasma on wayland, without xorg
installed at all, so it's possible in general.
Tho there are some differences and some possible differences, the biggest
of which is that that since a couple years after first switching to Linux
shortly after the turn of the century (before I switched to Gentoo; I was
then running Mandrake), I've had a *strict* personal policy of NO NVIDIA
GRAPHICS due to their freedomware-unfriendly policies. FWIW I had checked
that nVidia had Linux graphics drivers before buying the card I was on
when I switched to Linux, but back then (before I actually switched) I
didn't know that there /was/ such a thing as closed-source Linux graphics
drivers so I couldn't and didn't actually check that it was freedomware.
If I'd have known the distinction I'd have never bought it in the first
place.
That was the LAST time I made THAT mistake! By a couple years later when
I upgraded graphics cards again I had had enough, and I've steered as far
clear of nVidia graphics since as I have servantware software (see the
sig) in general, for the same reason.
In practice that has meant I've been running Radeons for 20 years now,
although there were a few years in the late ATI and early AMD eras that I
had to limit my upgrades to older hardware as the (then) newer stuff
didn't have available freedomware drivers, but AMD eventually changed that
and I've not had to worry about it for years, now.
Additionally, and being a Gentooer I'm sure you appreciate the flexibility
as well tho you may have made other choices, I always login at the CLI and
run kde from there, rather than running a *DM graphical login manager like
SDDM. Unfortunately that's even harder to find proper documentation for
than just running KDE/Plasma on wayland, because so much of what's out
there assumes starting plasma-wayland from a graphical login.
So naturally I had some of the same questions you do, when I first started
investigating kde/plasma-wayland. Fortunately it's not too difficult in
general, even less so now than when I switched back in 2020, and I should
be able to help with the general and gentoo sides of it, tho you'll
obviously need to look elsewhere for any nVidia-specific stuff.
Also of interest, I'm running systemd, which I believe made things a bit
simpler for me, but I *believe* gentoo (with help from the kde upstream)
has been keeping openrc systems working with it as well. Tho again I
won't be able to provide much help with the openrc stuff if there's
differences, but I expect existing gentoo openrc documentation to be
sufficient there and don't anticipate any real problems in that regard --
I expect you'd be more likely to run into nVidia-specific than openrc-
specific problems.
And finally, I do run both ~amd64 not arch-stable, which I still expect
may help as I'm not sure of the arch-stable plasma-wayland status, and in
my case, actually the live-git *9999 versions of most kde/plasma packages
from the gentoo/kde overlay, but plasma-wayland is now stable enough
/that/ should not be necessary or even particularly beneficial any longer,
though it certainly helped back in 2020 when I switched plasma-X to
plasma-wayland as back then the latter was still buggy enough that the
live-git versions made a big difference.
> he works on XORG at 1600x900, supports DRM (probably due to VGA monitors
> problem, unable to read EDID).
It looks like the first part of that sentence/paragraph got chopped off
somewhere so I'm not entirely sure whether your card /does/ support (says
support) DRM or does /not/ (the parenthetical suggests does not support),
so I'm guessing...
> Normally, wayland should have the function of manually setting the
> resolution like xorg, but I don't know how to do it, and I can't find
> relevant information on the Internet. If KDE users or developers have
> any suggestions and ideas, please contact me.
>
> If the WAYLAND compositor used by KDE does not support setting the
> resolution for the time being due to development reasons, please let me
> know,
I had exactly this sort of question as well, tho in my case it was more
how do I tell plasma-wayland (or specifically kwin_wayland, on wayland,
the plasma compositor as well as the window manager, though it does still
split out some tasks to other kde/plasma components through various
mechanisms, but kwin_wayland still does way more than kwin_x11) what to do
with my two monitors and how they're positioned relative to each other,
than resolution. But either way, there's nothing like the old xorg.conf
configuration mechanism, and finding documentation on the wayland
replacement tends to be *quite* difficult, because unlike X, it's not
standardized into a single configuration format and location but rather,
varies depending on what specific compositor, kde/plasma/kwin in this
case, you're using.
OK, to some hints that I'm hoping you'll find helpful:
General hints:
1) When running plasma-wayland, /most/ of your X-based apps will continue
to "just work" via xwayland, in some cases with even less hassle than
running under xorg.
I've actually been quite pleasantly surprised at this but it's true. Even
many apps you'd think were X-specific continue to "just work", in some
cases with less bugs than under xorg, though of course sometimes limited
in scope to the xwayland side of things.
For example, xrandr still prints valid resolution information because it's
getting it from xwayland, though trying to use it to /change/ resolutions
isn't going to work. xprop still prints usable X properties (window
class, title, minimized/normal/maximized state, dock/panel state, always-
on-top, always-under...) for various X windows running under xwayland, but
it can't see wayland-native windows, only X windows. For scripting,
wmctrl still works (both info output and moving/closing/etc) with X
windows but not wayland-native windows, and xdotool still can be used to
manipulate X windows and send them keystrokes, etc. If you're using a
third-party X app to listen for global shortcut triggers, /some/ of them
still work, while some don't, depending on whether kwin_wayland eats the
keys or passes them on. (Kwin will eat certain "extra" keys if it can see
and use them for its own global shortcuts, but some of the more exotic
ones it can't use and just passes on via xwayland, while a few like the
common volume-up/dn/mute keys it apparently both responds to and passes on
via xwayland.)
OTOH, while xset still prints generally valid values for its various
settings, in my experience it can no longer be used to actually /set/
anything at all -- even for X apps. The returned status is as if it
accepted the change, but immediately querying the value again, via xset
itself, still prints the unchanged value.
2) Both GTK and Qt/KDE have methods available to tell an app to run in X
mode or wayland mode. Normally this is done by setting/exporting an
environmental variable (I'd have to look up the specifics but ask if you
find you need them, or just google it) before starting the app, so it's
easy enough to either do it from konsole (for temporary usage and
experiments) or in a wrapper script (more permanent, if an app tries to
run in wayland mode but is buggy, for instance, while running in X mode
just fine).
Some versions of vlc's default qt-based GUI would try to run in wayland
mode because qt supported it at the time, for instance, but it still had
X-specific assumptions and would crash. Tell it to run in X mode (so it
ran via xwayland), though, and it would run just fine. Those bugs seem
fixed now, though, and vlc has been running fine for me in native wayland
mode for awhile. Similarly, early gtk3 versions of claws-mail would by
default try to run in wayland mode when gtk detected it, but again would
crash (and later wouldn't crash but would be buggy) due to X-specific
assumptions. In X mode (running in xwayland under wayland) it worked
fine. Newer claws-mail runs fine in native wayland mode in general, but
some of its plugins (the global hotkey, which it can't get on wayland due
to the stricter security model, and the tray icon, which I think /should/
work but at least last I tried it, just didn't show up, tho I'm not sure
whether that's a claws bug, a gtk bug, or a plasma/xembed-sni-proxy bug)
are still broken on wayland, though I don't believe X mode helps with
that.
Additionally, some apps simply detect the DISPLAY and/or WAYLAND_DISPLAY
environmental variable settings and behave accordingly, in which case it's
possible to simply ensure the appropriate display var is set while the
other is unset, to get it to run in the mode you want.
3) Have a backup compositor available.
I have found it very useful to have a second wayland compositor available,
both in case kwin_wayland breaks and simply as a second point of wayland
behavior comparison, if kwin_wayland is working but you're not sure
whether the different-from-X behavior you're investigating is wayland-
specific or kde/plasma specific.
If you keep xorg working at least for awhile, as I did, that helps in some
regards, but having a wayland that's not plasma to get that "second
opinion" can still be helpful, and anyway, at some point plasma-xorg broke
for me (probably some live-git thing) and I found it easier to just
install a second wayland compositor than to troubleshoot what was wrong
with plasma-xorg.
As for which one... I chose the reference-compositor weston, here. It's
not fancy but that's actually a /good/ thing for a backup you're likely to
need to work when your primary doesn't. As the wayland reference
compositor it's well documented and /everybody/ should be testing against
it. It has few additional dependencies (actually none for me if I recall)
and (of interest to gentooers) it's a relatively short/small build. AND
its config is a quite simple (and again well documented, manpage) text-
based $XDG_CONFIG_HOME/weston.ini (~/.config/weston.ini by default).
IOW, weston is arguably the /ideal/ second compositor. =:^) Of course
there are others if you want something fancier, but I just wanted
something simple, simple to configure, and low dependency, that I could
count on to run if my after all live-git plasma installation wouldn't, and
so far it has filled that need perfectly. =:^)
As a more recent development of interest specifically to gentooers, it's
now possible to set USE=-X globally, and only turn it on for specific
packages. I've done just that and can post a list of the packages I have
USE=X set for, if you're interested, later, but I recommend that you just
keep USE=X set for now, until you get comfortable with wayland and decide
to try to set USE=-X and save some dependencies you can then quit worrying
about having to update. =:^)
More specific hints:
4) KWin window rules (doesn't apply if you don't use them):
FWIW I depend on a somewhat large set of kwin window rules. If you do
too, be aware that many apps, particularly kde apps (where they seem to
have taken the opportunity afforded by the wayland switch to get rid of
some legacy naming policies) change window class names under wayland. You
will thus likely need to change window matching rules accordingly.
If like me you start out wanting to be able to run either xorg or wayland
and need the rules to apply to both, you'll want to use the /duplicate/
/rule/ button, rename one or both of the rules to reflect xorg or wayland,
and change the wayland rule to reflect the window class under wayland.
(Of course if you actually switch to wayland and eventually unmerge xorg
as I did, you will then be able to delete all the X-specific rules, but
that's likely to be a few months.)
But finally answering the question you actually asked...
5) Resolution and similar config a la xorg.conf:
I'm honestly not sure how much of the display config is supposed to be
retained across plasma session, but at least here, for multiple monitor
positioning (my default resolutions are correct), it's not. See 5b below
for my workaround.
5a) GUI: kscreen, the kcm. Almost the same as in xorg.
The usual plasma GUI method to configure resolution, orientation, multi-
screen positioning, etc, is via the kcm (kcontrol module, aka plasma
systemsettings, under hardware, display and monitor, display
configuration, or from krunner or konsole, kcmshell5 kscreen, or via
krunner via keyword such as display, screen or monitor, and select display
configuration. This works much the same in wayland as it does in xorg.
5b) CLI/scripting, a la xrandr:
For scripting/CLI display configuration, you're looking for kscreen-
console (info) and kscreen-doctor (print or change settings).
Unfortunately no manpages (or USE=handbook), but the usual --help option
works. (Again, these should work for xorg as well, but of course third-
party config doesn't work for wayland as it does for xorg.)
As alluded to above my resolutions are correct but I have a dual monitor
setup and the default layout consistently reverses the right and left
monitors. I'd simply switch cables if I could (they're both HDMI on the
monitor side, actually both bigscreen TVs), but one cable's too short to
reach the far monitor and the graphics outputs are different (displayport,
hdmi), so that won't work.
So I have a simple script that basically does this:
kscreen-doctor \
output.1.position.3840,0 \
output.2.position.0,0
(The logic's actually a bit fancier than that but that's the operational
bit; I can post the full script if you like.)
And I have that setup in the autostart scripts (kcmshell5 autostart, or
plasma systemsettings, startup and shutdown, autostart) to run at plasma
startup.
That automates switching the two monitor positions at startup, so I don't
have to do it manually.
Presumably you'd setup something similar if the default resolutions were
wrong.
Alternatively...
5c) Supply a kernel commandline resolution and/or a fake EDID.
I'm unclear whether you have DRM working or not (that was the bit of your
post that seemed incomplete). If it's working and nVidia isn't trying to
do something special here, a video= kernel commandline option (see
$KERNDIR/Documentation/fb/modedb.rst) such as the ones I use for my multi-
output graphics card might work. Here's what I use to force all three
outputs to 4K (3840x2160) mode; modify output name and resolution as
appropriate (note that the output name is the kernel name and may not be
equivalent to the xorg output name, mine wasn't, something like HDMI-0 for
xorg vs the HDMI-A-1 here, IIRC):
video=HDMI-A-1:3840x2160 video=DVI-D-1:3840x2160
video=DisplayPort-1:3840x2160
If that doesn't work...
I've never had to do the fake EDID thing so I don't know what caveats
apply, tho of course one of them could be nVidia-specific options you'd
need to check their documentation for, but check the kernel config options
(... indicates more):
DRM_LOAD_EDID_FIRMWARE
Device drivers > graphics support > allow to specify an EDID ...
FIRMWARE_EDID
Device drivers > graphics support > frame buffer devices >
support for frame buffer devices > enable firmware EDID
And lastly, an observation from following the git development...
They recently began much more highly integrating kscreen's autodetection
logic into kwin and plasmashell (which needs it for wallpaper resolution,
etc) and in general focusing on resolution retention, plugging/unplugging
monitors and whether the previously used settings for that config are
detected and reused, etc. The work is quite recent and seems to be
ongoing, but they are definitely aware of and focused on bugs in that area
ATM, so improvements should be coming.
But also note that the planned branch of frameworks for qt6 is coming in
January, after which frameworks-5 will be in no-new-features, bugfixes-
only, maintenance mode (plasma and apps/gear will branch later; they need
a solid frameworks-6 base to build on first). It is thus quite possible
that some of the work won't be available until the 6 versions, tho it is
acknowledged bugfixing so at least some should make it into upcoming 5
releases as long as the code churn remains within bugfix-level
requirements.
--
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
