Window managers and desktop shells
- 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)
- 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)
- 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)
Weston - Keyboard Shortcuts
On weston 1.12, application using dbus cannot be launched normally. I've added a workaround to launch on the troubleshooting section.
Graphics driver section
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)
The RDP backend in wlroots
A new paragraph is added in https://wiki.archlinux.org/index.php?title=Wayland&diff=next&oldid=573059. I think it is not enabled in Arch's wlroots? https://bugs.archlinux.org/task/62809.
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.
- Splitting is done: Weston. Sections were reordered:  -- Lahwaacz (talk) 06:52, 18 October 2019 (UTC)
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.
- 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)
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(?)
- 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)
- 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) G3ro
Should we add a section for XWayland?
This could also feature a table explaining the status of implementation on different graphic drivers.
- Well like most other articles it would describe the software (which might be especially important here, because Xorg/Wayland upstream is always a bit short on recent information regarding their projects; for example the main site for XWayland still looks like some kind of beta status, probably wasn't updated for years), but it could also include some important notes, for example:
- * Graphics Driver differences, like I mentioned above; for example proprietary nvidia drivers have no GPU-acceleration support for XWayland yet (though there are proposed patches for that)
- * XWayland is like a XServer, so it does not include all the "security" features of Wayland (on the pro side this also means less restrictions)
- * Still some features might be different (or missing) in regards to regular XServer
- * XWayland can (in theory) be used with every compositor, if they include support for it
- * I have to admit that I don't know about many configuration options for it, but maybe there are also things to mention
- Maybe we'd want a section on setting up standalone XWayland similar to what Fedora is planning?
- * https://fedoraproject.org/wiki/Changes/XwaylandStandalone
- * https://aur.archlinux.org/packages/xorg-server-xwayland-standalone-git/
- nloewen (talk) 21:00, 3 December 2020 (UTC)
- No, I don't think that will work. As you can see in the Weston#XWayland Wiki Article, XWayland is started via the Wayland Compositors. So every compositor needs their own instructions. The point for XWayland on this page (or the X-Server page) was just to describe it a bit more.
- Also "standalone" in this case means, that XWayland is compiled seperate from other X-Server components, because XWayland is part of X-Server for now. It does not mean, that it can work without Wayland (which would be pointless anyway).
- G3ro (talk) 19:20, 4 December 2020 (UTC) G3ro
- Update: Now I think I understand your point, you want to make people aware of your package, correct?
- In that case, yes I agree it should be mentioned, because of the upstream patches, that seem to be missing in the official releases.
- Though that should be checked once more, there was a new release some days ago, if I am not mistaken.
- Update2: I have added a section for XWayland, mentioning your package.
- Though I am not sure, whether the admins will agree to mention an AUR package in such a prominent way. And we still should check whether at least some of the necessary patches are already included in 1.20.10.
I am not sure you understand this correctly. XWayland is started via a compositor, so of course the instructions can vary from compositor to compositor. So the instructions should be on the seperate pages.
- G3ro (talk) 20:05, 8 December 2020 (UTC)
- Update3: I just checked the commit history of the 1.20.10 release and it seems that most of the patches mentioned in the fedora article are missing, among them: initfd support, multiple window buffers, Hans de Goede's RandR patches for xwayland and probably more.
- So it makes sense to advise for using the git master version.
- G3ro (talk) 22:16, 8 December 2020 (UTC)
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).
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.
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.
- 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)
- 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)
- 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)