Talk:Wayland

From ArchWiki

Window managers and desktop shells

Enlightenment?

I read here that they already had good support for Wayland two years ago. Doesn't that make it an important addition to this list? Johnchfr (talk) 17:49, 11 October 2014 (UTC)Reply[reply]

Yes, you are free to add it. -- Kynikos (talk) 04:06, 13 October 2014 (UTC)Reply[reply]
But, I tried it out (pkg from aur) and it seems very rough. The desktop comes up but when I try launching an app, displays an error dialog and when I close the dialog, it froze my system (I could not even switch ttys)! I didn't do much testing through different compile-options, though. -- Johnchfr (talk) 11:17, 14 October 2014 (UTC)Reply[reply]
It seems they're working on it, so it's worth being documented here, together with any relevant note about the state of the implementation. We don't decide what's good and what's bad for users here, we just give objective information to let the users make their own decisions. -- Kynikos (talk) 00:02, 15 October 2014 (UTC)Reply[reply]
since it's years later now, a quick update: enlightenment is usable (like gnome) with few minor issues --Ubone (talk) 14:22, 4 February 2019 (UTC)Reply[reply]

Graphics driver section

Would be cool to have some graphics driver section, just like the Xorg page. Maybe a common page? Emersion (talk) 10:26, 15 December 2017 (UTC)Reply[reply]

Troubleshooting "Running graphical applications as root"

I think that the https://wiki.archlinux.org/index.php/Wayland#Running_graphical_applications_as_root section should warn that it might be a bug in the application, not a bug in Wayland if the user needs to run a GUI app as root, see https://bugzilla.redhat.com/show_bug.cgi?id=1274451#c76. The wording in https://fedoraproject.org/wiki/How_to_debug_Wayland_problems#Graphical_applications_can.27t_be_run_as_root_from_terminal is pretty good, so maybe we should link to that. --Wikizian (talk) 09:27, 5 April 2018 (UTC)Reply[reply]

The easiest solution is to write an simple wladmin_exec script.

Containing this bash code

#!/usr/bin/bash

trap exit INT

which sudo &> /dev/null
if [ $? -ne 0 ] ; then
  printf  "No sudo are installed.\n\nIf you want a better runtime perfomance you should install sudo!\n\nFallback to using slower xhost localuser method!\n"
  xhost +si:localuser:root &> /dev/null && sh -c "su -c ${@}" && xhost -si:localuser:root &> /dev/null
  exit
fi

printf "Trying to use sudo enviroment load method!\n\nExecuting: sudo -E ${@}\n" && sudo -E ${@} || printf "Lools like it fails!\nUsing slower fallback xhost localuser method!\n\n" xhost +si:localuser:root &> /dev/null && sh -c "sudo  ${@} || su -c ${@}" && xhost -si:localuser:root &> /dev/null

Nonie689 (talk) 19:23, 18 July 2022 (UTC)Reply[reply]

Move Weston section to its own page & cleanup?

I think its a little odd that Weston is front and center on the Wayland page, and that it takes up 1/3 of the article.

The Weston section comes before the relevant discussion on/list of Wayland compositors which might mislead users into thinking they need Weston for Wayland in the same way they need X.org for X. Especially with the way the page somewhat mirrors the X.org page which starts with xorg-server installation instructions, and that Weston is not listed along with the other Wayland compositors in the compositors section.

In my opinion, the description of compositors should at least come first, and Weston should be listed among them. The Weston section should probably move to its own page. Additionally, some general and important info like XWayland is currently ensconced in the Weston section, so even users who know it is not relevant to them might miss it.

Less important, but I also find it odd that there is no mention of the wayland or wayland-protocols packages on the Wayland page, even though they're just dependencies for some compositors.

Finally, I think there should be a new section discussing application specific configuration as well, e.g. MOZ_ENABLE_WAYLAND or Wayland alternative software like xclip -> wl-clipboard.

—This unsigned comment is by Brocellous (talk) 00:08, October 18 2019 (UTC). Please sign your posts with ~~~~!

Splitting is done: Weston. Sections were reordered: [1] -- Lahwaacz (talk) 06:52, 18 October 2019 (UTC)Reply[reply]

GDM and NVIDIA proprietary drivers

This section is a candidate for merging with https://wiki.archlinux.org/index.php/GDM#Wayland_and_the_proprietary_NVIDIA_driver

It took about an hour of digging through forum posts to answer the simple question "how do I force GDM to just use Wayland if I have an nvidia GPU?". This information wasn't anywhere on the wiki before, and without this specific action, Wayland is unusable for any desktop session launched via GDM.

The GDM page currently makes it sound like GDM just doesn't support Wayland, but that is not true any more, and in fact, it appears to be working pretty well at the time of writing. I've added the meat of this section to the GDM page, but I think it's no harm to have the info in both places. If someone is trying to find out why GDM won't launch Wayland sessions, as I was, they might just as well go looking on the Wayland page in the wiki as on the GDM page.

Andrew-wja (talk) 11:51, 11 November 2019 (UTC)Reply[reply]

The information should be kept only in one place. The other place can say at most something like "See the first place for details." -- Lahwaacz (talk) 18:52, 15 November 2019 (UTC)Reply[reply]

Compositors: Improvements

Maybe the section could be improved, though that would be some work...

  • Explain differences (especially between tiling and stacking)
  • Create a table with more columns to explain features & status(?)

G3ro (talk) 22:01, 14 October 2020 (UTC) G3roReply[reply]

The tiling and stacking types are explained in Window manager#Types, you can just link to that section.
I'm against creating a table, the features are already so diverse and numerous that it would not be readable.
-- Lahwaacz (talk) 12:24, 15 October 2020 (UTC)Reply[reply]
Ok, I added a link to that.
Still I would like to see a bit more information:
# Introduction: like what are compositors
# More information in the list to make it easier for users to decide: which projects are active, mature, can be used with the following desktop environments etc.
I am not saying it is easy to do, but maybe someone has the knowledge and could provide it.
G3ro (talk) 15:14, 15 October 2020 (UTC) G3roReply[reply]
Obviously the most important thing that some compositors are missing is links to Arch packages... -- Lahwaacz (talk) 07:12, 16 October 2020 (UTC)Reply[reply]
I don't know what you mean, I just checked and every compositor in Packages or AUR has a link, all others don't seem to have packages, or they are named very differently so the search does not show them.
G3ro (talk) 13:40, 17 October 2020 (UTC) G3roReply[reply]
I mean that some items in Wayland#Compositors do not have a link to an Arch package (e.g. dwl, waymonad etc). -- Lahwaacz (talk) 13:49, 17 October 2020 (UTC)Reply[reply]
There is no package (at least I searched and found none), so they don't have a link.
G3ro (talk) 13:54, 17 October 2020 (UTC) G3roReply[reply]

Requirements: Better description or links for EGLstream

Just as placeholder until someone does it. Right now there is only a link to an old Phoronix article.

One suggestion: Even though it is a bit political it might be worth to mention the "conflict" between the Xorg Team & others on side and Nvidia on the other side over these buffer APIs. Otherwise people might not understand, why there is not one standard (yet).

G3ro (talk) 15:28, 15 October 2020 (UTC) G3roReply[reply]

Weston doesn't officially support EGLStreams

Regarding this: I would rather add a note to the linked section in the weston article, than mention the third party patch in the overview here.

G3ro (talk) 19:53, 26 January 2021 (UTC)Reply[reply]

wlroots and EGLStreams

Unlike added in Special:Diff/652770, wlroots does not support EGLStreams. The words "EGLStreams" or "Nvidia" are never mentioned in the readme, and this blog post from it's author explains why it isn't supported.

I don't know where User:Drich got this info but it seems to be incorrect. -- Lonaowna (talk) 21:51, 19 February 2021 (UTC)Reply[reply]

EGL are a dependency of wlroots, which is mentioned further down; I also never disputed the support. I disputed compatibilty which is simply not true. You can run sway perfectly fine with an Nvidia Card. Also the Readme mentions "unopinionated" modularity, which can be interpreted towards a broader compatibilty in consensus with the build dependencies. I disputed this section simply to make it of more granular wording instead of "its not supported" suggesting that I won't work which isn't true. The sway's switch along the lines of "--no-i-wont-buy-nvidia-next-time" also suggest a general aversion towards locking out a majority of users. So filed a dispute to make it clear that this matter isn't exactly as straightforward as the compat table presents it. I intended to start a discussion to improve the sections style of writing. Just reversing the commit, doesn't improve the state of unclarity.
Drich (talk) 23:37, 19 February 2021 (UTC)Reply[reply]
First of all, EGL is something different than EGLStreams. Using EGL does not mean using or supporting EGLStreams. GBM also uses EGL.
The table states that the proprietary NVIDIA graphics driver is incompatible with sway, which I believe to be correct. (meaning that you are actually not able to run it) It does not state that it is completely incompatible with Nvidia cards, but it does state that it is incompatible with the NVIDIA driver.
Yes you are kinda correct that "You can run sway perfectly fine with an Nvidia Card", but only when using the Nouveau driver.
If you think we should clarify that the table talks about drivers instead of cards, I'm all for that. Also, there's nothing wrong with starting a discussion; that's what we're having right now!
--Lonaowna (talk) 10:18, 20 February 2021 (UTC)Reply[reply]
Well, I might have jumped the gun on that topic. I am in fact an Nvidia User, but I think my ability to run wlroots compositors might be due to the fact that Iam a PRIME user. I never considered the fact that EGL might not be a abbreviation for EGLStream. I don't think an edit is necessary anymore. Driver politics are irritating...
Drich (talk) 12:01, 20 February 2021 (UTC)Reply[reply]
I clarified the name to "proprietary Nvidia driver" in the table.
G3ro (talk) 19:30, 20 February 2021 (UTC)Reply[reply]
The column header as well as surrounding text already talk about a GPU driver which should be clear enough. -- Lahwaacz (talk) 08:35, 21 February 2021 (UTC)Reply[reply]

The setting of environment variables may be unnecessary for Qt apps under Wayland

The Qt subsection of the GUI libraries section states,

"To run a Qt application with the Wayland plugin [4], use -platform wayland or QT_QPA_PLATFORM=wayland environment variable."

But I was able to run both dooble and falkon under Wayland without having to set the variable. I merely had to install qt5-wayland.

Are these instructions still relevant?

Pound Hash (talk) 21:10, 20 December 2021 (UTC)Reply[reply]

Maybe your desktop environment had those already otherwise you could edit this mildly with "maybe" -- Ubone (talk) 10:44, 16 January 2022 (UTC)Reply[reply]
I don't have a desktop environment; I use Sway. Also, I already wrote maybe in the OP. Pound Hash (talk) 06:10, 25 January 2022 (UTC)Reply[reply]

Isn't GBM used by default instead of EGLStreams on NVIDIA cards now?

I found no information regarding whether GBM is used instead of EGLStreams for popular compositors like Mutter and KWin. If anyone knows which one is used by default, then it might be necessary to add a note under the environment variables in Wayland#Requirements to clarify which compositors don't need those environment variables to use GBM as a backend. —This unsigned comment is by Cont999 (talk) 2022-08-20T12:46:51. Please sign your posts with ~~~~!

I've been using Wayland under KDE for more than a year without too much trouble. However, I recently replaced an old AMD GPU with a new NVIDIA GPU and could not get Wayland to work with the proprietary NVIDIA driver. When I filed a bug report with KDE, I was told that if I had set GBM_BACKEND=nvidia-drm & __GLX_VENDOR_LIBRARY_NAME=nvidia (as recommended here) I should unset/remove them as "they break things." Unsetting and removing the two environment variables resolved the problem and Wayland runs fine with the proprietary NVIDIA driver. Should an indication be added to the page that forcing GBM might cause problems with the NVIDIA driver on newer cards and recent driver versions? G. S. Martin GaryScottMartin 09:58, 15 October 2023 (UTC)Reply[reply]

Does Electron support to be run with GTK4 currently

In this edit, The following paragraph was added:

"Use --gtk-version=4 to solve fcitx input issue."

However, after trying to run an Electron program with flag --gtk-version=4, the following error was thrown:

(process:39254): Gtk-ERROR **: 22:59:05.179: GTK 2/3 symbols detected. Using GTK 2/3 and GTK 4 in the same process is not supported

Does Electron actually have the support to be run with GTK4 currently?

Currently I have deleted the instruction content about the flag of --gtk-version=4 in this wiki page. I'd like to have the content added back if there is some solution to allow Electron to work properly with GTK4.

白羊李志远 (talk) 15:35, 11 May 2023 (UTC)Reply[reply]

Related upstream issue --Misaka 0x34ca (talk) 15:45, 11 May 2023 (UTC)Reply[reply]
From https://fcitx-im.org/wiki/Using_Fcitx_5_on_Wayland#Chromium_.2F_Electron:

You should only use one of --enable-wayland-ime or --gtk-version=4, depending on you want to use text-input-v1, or gtk4 im module. text-input-v1 works for kwin 5.27 and weston. Gtk4 im module works on all environment, but only GNOME with Kimpanel extension can display the popup window in the correct position.

Teohhanhui (talk) 17:22, 6 March 2024 (UTC)Reply[reply]

Lightdm support for Wayland is debatable

I realize that its project readme says it can start wayland sessions, but in practice I don't know of anyone that succeeded.

On the other hand I know I could not convince it to start Sway (anecdotal, sure), and there is also https://github.com/canonical/lightdm/issues/267 and https://github.com/canonical/lightdm/issues/268 . Documentation on which greeters (if any) can be used to start wayland compositors from lightdm is also lacking.

This is to be compared with e.g. gdm which just works out of the box.

I would propose to remove lightdm from the list of display managers that support Wayland.

Bluehood (talk) 03:37, 7 June 2023 (UTC)Reply[reply]

It can launch Wayland sessions, so it should be listed here. --City-busz (talk) 07:58, 7 June 2023 (UTC)Reply[reply]

SDDM Wayland support

Since SDDM 0.20 supports Wayland, should it be noted in the Display Managers section? Or, since it's considered experimental according to https://wiki.archlinux.org/title/SDDM, should it just say experimental?

I was able to get it to use Wayland on my system using this configuration with no issues.

TheSF4 (talk) 00:48, 25 June 2023 (UTC)Reply[reply]

Setting SDL_VIDEODRIVER="wayland,x11" does not work.

I've been encountering issues with using this specific value for games that use SDL. Setting it to "wayland" or "x11" on it's own works just fine. This fall back doesn't. Not sure how to actually set a proper fallback here as the wiki linked doesn't demonstrate it. GothicLemons (talk) 22:17, 5 July 2023 (UTC)Reply[reply]

Wrong Chromium / Electron flag for WebRTC screen sharing?

Under Wayland#Command line flags, it says:

Use --enable-webrtc-pipewire-capturer to solve electron screen capture problem on Wayland.

However, the correct flag seems to be --enable-features=WebRTCPipeWireCapturer, as can be seen at https://wiki.archlinux.org/title/PipeWire#WebRTC_screen_sharing Teohhanhui (talk) 17:29, 6 March 2024 (UTC)Reply[reply]

Great catch, that's indeed a long-removed Chromium flag not meant for Electron. I've replaced it for the correct one. This has probably caused a lot of people trouble. C0rn3j (talk) 19:03, 6 March 2024 (UTC)Reply[reply]

JetBrains Runtime has experimental support for native Wayland

java needs to be run with -Dawt.toolkit.name=WLToolkit to select the experimental Wayland toolkit.

The latest release as of time of writing: https://github.com/JetBrains/JetBrainsRuntime/releases/tag/jbr-release-21.0.2b375.1

They continue to work on WLToolkit on the jbr21 branch: https://github.com/JetBrains/JetBrainsRuntime/tree/jbr21

Upstream tracking issue is here: https://youtrack.jetbrains.com/issue/JBR-3206 Teohhanhui (talk) 13:22, 8 March 2024 (UTC)Reply[reply]