I recognize that GNOME is ditching (or has ditched) X11, I just didn’t know it was happening now and would be forced.
My question is simple: can I get X11 back until GNOME 50 is released?
Wayland broke at least two key parts of my setup:
without xrandr, I can’t get my external monitor to “act right”: the system thinks its an LG 34”, but it’s an LG 29”. I needed xrandr to set the correct resolution (2560x1080), and I can’t seem to get that done under Wayland.
Maybe it’s just me, but ALL Chromium based browsers have visual glitches after my “upgrade” to GNOME 49 and Wayland. Firefox: no problem. But Vivaldi, Chromium, Brave, and Edge, all borked with weird flashes at different parts of the browser window.
I know I will have to move to Wayland if I want to keep GNOME. But I would like some time to get these things fixed first. Any help is greatly appreciated. Ridicule can be withheld.
1. I don’t know how relevant this is now, but I found:
You might also find a pointer to something useful here:
2. I see no such issue here, and I use those browsers (with the exception of Brave). The issue is likely elsewhere, though where exactly, I can’t say at this time.
Start with the usual system information and maybe someone can make a suggestion or two. Please provide the inxi output as described (below).
Regards.
System Information
While information from *-fetch type apps might be fine for someone wishing to buy your computer, for Support purposes it’s better to ask your system directly;
Output of the inxi command (with appropriate parameters, and formatted according to forum guidelines) will generate information useful for those wishing to help:
Hmm - I have been using Wayland for a long time now - although I use Plasma with kwin - and I cannot recall having issues like you describe.
I have - occasionally - strange incidents where chromium based browsers may crash - as in completely - but I sign those off with a as caused by my profession - coding a Blazor WASM PWA using dotnet core.
When you have weird flashes at different parts of the browser window - I think hardware acceleration, thus related to the GPU.
I am guessing now - the browser creates various caches ~/.cache - you can safely clear that folder - content will be recreated but the change from X11 to Wayland or vice versa, may cause the cache to be invalid.
My totally uneducated guess is that the jittery/stuttery/screen tearing has something to do with GTK. The list of apps that have it are: Signal; Chromium; Vivaldi; and Brave. All others that I tried do not. But syncthing-gtk looks like this (it’s supposed to filled with information about your device and synced folders):
Regarding wlr-randr, I tried that once (during a lot of attempts with AI assists, mostly focused on creating modified /lib/firmware/edid entries that include the correct resolution), but I will focus on it again tomorrow and report back. If anyone has seen a guide to adding a resolution, similar to xrandr’s function, please let me know.
I will also turn off all extensions and see if that yields any change.
Earlier in Wayland adoption I recall some found that using the same Refresh Rate helped with a few multiple monitor configurations, at least with scaling and resolution issues.
That’s clearly nothing to do with the current problem, of course, but it might be a useful note to file away.
There was a similar issue on Mac hardware in one or two topics only recently (within the past month or two). I’m afraid I don’t recall the topic titles, but a careful forum search might reveal them (both were “Mac 11” from memory, so that might be a place to start).
I think ideally it should all have been lowercase, but no matter; it’s rare that the caching issue arises; but it does happen.
It’s possible Chromium is the common denominator. There have been one or two complaining of random screen artefacts since the update.
They didn’t specify exactly what was affected (Plasma was mentioned but it might be something deeper), in fact, they didn’t give a lot of information at all, but it may be a direction to follow.
These were only a few after-thoughts.
I’ll chime in again if I discover anything with any substance.
These instructions will not work on Gnome 50+ (so say the Gnome devs) but this will buy you some time to make a plan.
1) Install deps: sudo pacman -S base-devel
2) Set up a path to store locally build packages:
mkdir ~/pkgbuild; cd ~/pkgbuild
3) Download the Arch package source:
pkgctl repo clone --protocol=https mutter
pkgctl repo clone --protocol=https gdm
pkgctl repo clone --protocol=https gnome-session
pkgctl repo clone --protocol=https gnome-shell
4) For mutter, and gnome-session: Within each directory, edit PKGBUILD, find local meson_options=(, add -D x11=true to the end of its list.
5) For gdm: edit PKGBUILD, find local meson_options=(, add -D x11-support=true to the end of its list.
6) Now rebuild all 4 with gnome-shell last - it needs to be rebuilt after the others have as it depends on them:
cd mutter; makepkg -si
cd ..
cd gdm; makepkg -si
cd ..
cd gnome-session; makepkg -si
cd ..
cd gnome-shell; makepkg -si
Now reboot (or log out / restart gdm), select “Gnome on Xorg” from the login screen. Voila!
Later, when you run pacman -Syu for system upgrades, look for these packages. If their versions are 49.x, let it install, then re-run step 6. You may need to use makepkg -sif (f means force) to help them complete, you also may need to manually clean up the src subdirectories within each of the 4 packages if there are build failures). This again replaces the non-X11 builds with the X11-friendly versions instead. IF the pacman -Syu run shows versions 50+, don’t upgrade, or you’ll lose X11 for good.
[edited] I decided instead to use a full system backup I had from a few months ago and update while excluding all gnome and related components (anything with 49 in it pretty much). Will report back if that worked.
Though this is expected, it took about 1 minute to add my external monitor’s custom resolution using xrandr into this backup version (I hadn’t used the monitor back then). Sigh.
The forum was down yesterday, so I couldn’t report back. I’m still working on parts of this, but here is the latest.
After multiple attempts, it is now clear that wayland simply does not have a reliable way to add custom resolutions for Ultrawide monitors that report the wrong resolution, the way xrandr did on X11. Note: in my case, the monitor doesn’t seem to “report” the right resolution, but it does “support” the right resolution, as evidence by digging into its details and my use of `X11’. But for future readers, here are the methods that seem to be “out there,” but that did not work:
Also, here are the instructions for adding the same monitor on `X11` (Note: The below covers multiple monitor ports because it seems to change sometimes on reboot):
This is self-admittedly pathetic, but I am having something of an existential crisis regarding losing GNOME after using it for about 15 years. I don’t expect the wayland devs to fix this, as it has been a known issue for years. I guess I will have to try KDE Plasma.
This may be a non-starter, but it is even possible to update my applications – while excluding some associated with gnome 49 – using either pacman or pamac without breaking the system? I tried with the below, and failed:
It (wlr-randr) didn’t help. I couldn’t get past this error: “compositor doesn’t support wlr-output-management-unstable-v1”.
I tried to research it. The best I got was “This error indicates that your Wayland compositor does not support the required output management protocol for wlr-randr.”
FWIW, I have an almost identical Manjaro-GNOME setup on a different machine – one that I don’t use an external monitor. I did the full upgrade to gnome-shell 49, and I encountered none of the non-custom-resolution-related artifacts. That is, Vivaldi and other Chromium-based apps did not flicker, nor did Signal.
Earlier I expressed some doubt regarding wlr-randr – I rediscovered the post mentioned that I referred to, and it seems my doubt was justified – wlr-randr will not work with Wayland (on KDE) because it isn’t built against wlroots:
The article from Nate Graham (linked in that post) will be of related interest.
I presume you might have done this already, if not, can you revert to a single monitor for a time, and verify whether these artefacts persist?
Interesting. I’m on GNOME, and I got the same error referenced in that post w/r/t Plasma: compositor doesn’t support wlr-output-management-unstable-v1. I wonder what DE has a compositor that works with wlr-randr?
I actually didn’t try that; I guess I wasn’t thinking that the extra monitor was a cause of the problem, instead of the result of the problem. I will do that now.
[tracy@daphne ~]$ kscreen-doctor --help
Usage: kscreen-doctor [options] [output.<name>.<setting> output.<name>.setting [...]]
kscreen-doctor allows to change the screen setup from the command-line.
Setting the output configuration is done in an atomic fashion, all settings
are applied in a single command.
kscreen-doctor can be used to enable and disable outputs, to position screens,
change resolution (mode setting), etc.. You should put all your options into
a single invocation of kscreen-doctor, so they can all be applied at once.
Usage examples:
Show output information:
$ kscreen-doctor -o
Output: 1 eDP-1 enabled connected Panel Modes: Modes: 1:800x600@60 [...] Geometry: 0,0 1280x800
Output: 70 HDMI-2 enabled connected HDMI Modes: 1:800x600@60 [...] Geometry: 1280,0 1920x1080
Disable the hdmi output, enable the laptop panel and set it to a specific mode
$ kscreen-doctor output.HDMI-2.disable output.eDP-1.mode.1 output.eDP-1.enable
Position the hdmi monitor on the right of the laptop panel
$ kscreen-doctor output.HDMI-2.position.1280,0 output.eDP-1.position.0,0
Set resolution mode
$ kscreen-doctor output.HDMI-2.mode.1920x1080@60
Set scale (note: fractional scaling is only supported on wayland)
$ kscreen-doctor output.HDMI-2.scale.2
Set rotation (possible values: none, left, right, inverted)
$ kscreen-doctor output.HDMI-2.rotation.left
Set HDR mode (possible values: enable, disable)
$ kscreen-doctor output.HDMI-2.hdr.enable
Set SDR brightness (possible values: 100-1000)
$ kscreen-doctor output.HDMI-2.sdr-brightness.300
Set wide color gamut mode (possible values: enable, disable)
$ kscreen-doctor output.HDMI-2.wcg.enable
Set ICC profile path
$ kscreen-doctor output.HDMI-2.iccprofile."/path/to/profile.icc"
Show dpms information:
$ kscreen-doctor --dpms show
Set dpms mode: (possible values: on, off)
$ kscreen-doctor --dpms on
Options:
-h, --help Displays help on commandline options.
--help-all Displays help, including generic Qt options.
-i, --info Show runtime information: backends, logging,
etc.
-j, --json Show configuration in JSON format
-o, --outputs Show outputs
-d, --dpms <off> Display power management (wayland only)
-l, --log <comment> Write a comment to the log file
--dpms-excluded <connector> Do not apply the dpms change to the output with
said model names
Arguments:
config Specific output settings are separated by
spaces, each setting is in the form of
output.<name>.<setting>[.<value>]
For example:
$ kscreen-doctor output.HDMI-2.enable \
output.eDP-1.mode.4 \
output.eDP-1.position.1280,0
Multiple settings are passed in order to have
kscreen-doctor apply these settings in one go.
which does look like itr could be a wayland (on KDE) replacement for xrandr.
I still can’t find anything for GNOME, and could not test it anyway.
as caused by my profession - coding a Blazor WASM PWA using dotnet core.
