Configure WAYLAND resolution on KDE

[Duncan]

[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