Talk:Wayland

From ArchWiki
Jump to navigation Jump to search

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)

Yes, you are free to add it. -- Kynikos (talk) 04:06, 13 October 2014 (UTC)
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

Why set Ctrl-b in the article section ? vinegret (talk) 07:22, 29 January 2015 (UTC)

dbus

On weston 1.12, application using dbus cannot be launched normally. I've added a workaround to launch on the troubleshooting section.

Alive4ever (talk)

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)

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.

—This unsigned comment is by Yan12125 (talk) 11:00, 8 June 2019‎. Please sign your posts with ~~~~!

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)

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)

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)

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) G3ro

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
Obviously the most important thing that some compositors are missing is links to Arch packages... -- Lahwaacz (talk) 07:12, 16 October 2020 (UTC)
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) G3ro
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)
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) G3ro

XWayland

Should we add a section for XWayland?

This could also feature a table explaining the status of implementation on different graphic drivers.

G3ro (talk) 22:03, 14 October 2020 (UTC) G3ro

Depends on what is there to describe. -- Lahwaacz (talk) 12:24, 15 October 2020 (UTC)
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
G3ro (talk) 14:59, 15 October 2020 (UTC) G3ro
Should I add a section about XWayland to Xorg instead, as it is a part of that project?
I would then add a link to this page.
G3ro (talk) 13:48, 17 October 2020 (UTC) G3ro
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
I don't think each compositor would need their own instructions. The only difference from normal XWayland setup is the package you install.
Although, if this is just to describe XWayland more, perhaps that doesn't fit.
nloewen (talk) 17:40, 8 December 2020 (UTC)
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)
I added the new package "xorg-xwayland" to the list as well, so now everyone can install a recent version without needing to build it themselves.
G3ro (talk) 17:03, 10 December 2020 (UTC)

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) G3ro


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)

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)

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)
I clarified the name to "proprietary Nvidia driver" in the table.
G3ro (talk) 19:30, 20 February 2021 (UTC)
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)