Talk:Wayland (protocol)/Archive 1

Archive 1

Kristian Høgsberg

According to Qt Is Now Drawing On Wayland, the screenshot and the comment on the page, Kristian Høgsberg is no longer a Red Hat's employee. He's currently working for Intel, possibly due to the Intel's interest in using Wayland in MeeGo Touch. - Justin545 (talk) 07:41, 11 October 2010 (UTC)

Difference to Xegl

Is somebody able to explain the relation and difference to Xegl architecture? It also uses EGL. The German Xegl article is more detailed than the English Xegl section in the Xgl article. http://www.freedesktop.org/wiki/Xegl http://en.wikipedia.org/wiki/EGL_%28OpenGL%29 http://www.khronos.org/egl/ http://www.freedesktop.org/wiki/Xegl http://www.freedesktop.org/wiki/EGL http://de.wikipedia.org/wiki/Xegl --KaiLueke (talk) 10:17, 1 November 2010 (UTC)

Mark Shuttleworth

Just read that Mark has thrown Ubuntu 100% behind Wayland Ampers - London UK (talk) 00:35, 5 November 2010 (UTC) Ampers Taylor

http://www.markshuttleworth.com/archives/551 —Darxus (talk) 18:06, 6 November 2010 (UTC)

Wayland and MeeGo

I removed false information that Wayland would already be deployed in MeeGo. See the following MeeGo mailing list post (5 November 2010): http://permalink.gmane.org/gmane.comp.handhelds.meego.devel/6643

Wayland is not on the list for 1.2.. it's not ready enough for that yet.

It is an interesting technology that we want to adopt when it's ready...

and help mature it as well, but right now it's just not ready yet.

Here is the speculation I removed:

As of September 16, 2010, the first deployment of Wayland is in MeeGo OS developed by Intel and Nokia.

--Hritcu (talk) 20:26, 7 November 2010 (UTC)

More info

Based mostly on ajax's series of posts to the Fedora desktop list. I realize we're not a crystal ball, but ajax is also a lead Xorg developer so I think can reasonably be expected to have described their solid plans accurately and in a manner it would be informative for us to summarize - David Gerard (talk) 23:05, 20 November 2010 (UTC)

There are no "solid plans" for use of Wayland. From anybody. Because it's so far from done. —Darxus (talk) 06:34, 22 November 2010 (UTC)

What is it?

The article seems to be lacking background on what exactly a display server is and how it fits in; in what sense might Wayland 'replace' X.org? Not replace it? Supplement it? What is its competitor? etc. Even a techie sort comes out of this article not really knowing what Wayland is. --Gwern (contribs) 19:01 13 November 2010 (GMT)

The best explanation of Wayland I've found is here. (In fact, AFAIK, that's pretty much all the user-oriented documentation the Wayland project has produced so far — they're still focused on coding.)

Here's my summary:

• The term 'display server' is not particularly meaningful, AFAICT. 'Compositor server' or a 'display compositor/manager' would be better.
• X itself does not use a compositor, but many modern X Window Managers do composition. Wayland is about moving composition from the periphery of the graphics stack to the center.
• Under X, applications send rendering instructions to the X server via a socket. Under Wayland, they render directly to a buffer using OpenGL etc, then tell the compositor what they just did.
• This makes Wayland faster than X.
• More importantly, Wayland is synchronous. Woops! Not true, see below.
• It will be possible (and highly desirable!) to create an X server which renders graphics using Wayland instead of a hardware-specific graphics driver.
• Graphics toolkits such as Qt, GDK and WxWidgets would need to be enhancedported to support Wayland.
• Many people who use X via networks (remote applications) are quite hostile to Wayland. However, an X developer says that "network remoting ... like in X" can be added to Wayland.

This article is not just unclear, it is wrong in places. I'll have a go at improving it. I'd be grateful for any help. Cheers, CWC 15:33, 14 November 2010 (UTC)

This article was created by me when Wayland was in its early stage. There was not much stuff to cite at that time. Wayland Architecture is important source, indeed. I'll appreciate your effort to expand it in a more sensible way. - Justin545 (talk) 16:15, 14 November 2010 (UTC)

Yeah, "not much stuff to cite" is an understatement. Worse still, some of the coverage was not particularly accurate, plus other stuff (even info from the Wayland developers themselves) has become outdated. I remember thinking at the time that this article was pretty good considering the sources, and feeling glad I wasn't editing here ... <grin> Thanks for your work here, Justin545.

While I'm here: could some knowledgeable people check evdev and my recent edit there, please. Thanks in advance, CWC 13:07, 15 November 2010 (UTC)

Chris, you have a dangerous misunderstanding of the term "synchronous". I'm curious what you actually meant by it. Maybe you just missed an "a".

The wayland protocol is already violently asynchronous, so it should be able to handle a bit of network lag gracefully.

— Kristian Høgsberg, November 2010

—Darxus (talk) 06:30, 22 November 2010 (UTC)

Oh. Thanks for pointing that out. I somehow misread the architecture document, even though it talks about event flows, not about procedure calls ... duh. You see why I keep asking people to check my edits ...

While I'm here, I recommend reading the email that Darxus linked to see what Kristan himself thinks about transparent networking for Wayland apps. Cheers, CWC 09:41, 22 November 2010 (UTC)

Big edit made, big scrutiny requested

I've just finished the big edit I hinted at earlier. Please check my work. (See above for motivation.)

I put in a lot more about the reasoning behind Wayland, using quotes from the Wayland FAQ. I took out all the outdated stuff except the initial Phoronix item (and I've noted that its title is wrong). I worked in LWN's report of Keith Packard's LPC talk earlier this month, because I feel it adds some important context. I added a bit of biographical info about KRH, because his impressive history as a Linux graphics developer adds credibility to this project.

I've read lots of articles (and their comments!) about Wayland in the last few days. The best article is from (no surprise) LWN, but it is currently subscriber-only. It's The way to Wayland: Preparing for life After X by Joe 'Zonker' Brockmeier. I have not used it as a source, but it certainly shaped my thinking. When it is generally available, we should cite it re things like to GPU hotswapping(!).

Please improve my work. In particular, "History" is probably not the best title for that section. Cheers, CWC 14:36, 23 November 2010 (UTC)

There is nothing wrong with citing subscriber-only content in Wikipedia, as long as you do it accurately - David Gerard (talk) 22:44, 27 November 2010 (UTC)

@CWC: The linked articles are free-for-all now. In the future, you can use the LWN.net "subscriber link" feature to link to subscriber content. -- intgr [talk] 03:38, 28 November 2010 (UTC)

Thanks to both of you for those useful tips.

I've made a smallish edit, changing 1 heading and (as an interim measure) adding the Brockmeier article as an EL. Cheers, CWC 11:54, 28 November 2010 (UTC)

"Intel and Nokia want to adopt Wayland in a future version of MeeGo."

The "and Nokia" part of that appears to be unfounded. The reference is: http://www.phoronix.com/scan.php?page=news_item&px=ODYwMQ

The only mention of Nokia there is:

"Though this isn't to be confused with the MeeGo netbook edition or even Nokia's version of MeeGo Touch for their hand-held devices as they have the decision of using Wayland or continuing to run an X.Org Server."

So, while I would personally guess it's true, I'm going to delete Nokia from that sentence because there is no actual evidence of it. —Darxus (talk) 19:03, 17 December 2010 (UTC)

Wayland is not a display server

For how much Wayland simplifies things, it sure can be confusing. Wayland is not any one display server or compositor. There is currently only one Wayland display server, the program "compositor" contained in the Wayland git repository. It is only a demo, or sample implementation. It is not intended to ever actually be used as a primary desktop interface.

Instead, the Wayland protocol is intended to be implemented in compositing window managers, such as Compiz, KWin (KDE), Metacity (Gnome), Mutter (Gnome Shell, MeeGo netbook), and MCompositor (MeeGo handset). They then become the display server, communicating with video and input hardware however they like.

I've written up a lot of this kind of stuff here: http://www.chaosreigns.com/wayland/ There are a couple minor inaccuracies (I need to replace "pointer" with "handle"), but I've had a couple active Wayland developers read over it, and I believe it is generally correct.

So what's the situation on referencing my own web site, or IRC logs, on wikipedia?

I guess I should just post the contents of that page to the Wayland mailing list asking for feedback —Darxus (talk) 20:44, 17 December 2010 (UTC)

I believe everything on http://www.chaosreigns.com/wayland/ is now correct. —Darxus (talk) 21:19, 17 December 2010 (UTC)

Posted: http://lists.freedesktop.org/archives/wayland-devel/2010-December/000361.html —Darxus (talk) 04:09, 18 December 2010 (UTC)

WP:NOR#Citing_oneself I interpret that to mean that if it would be appropriate for someone else to add something to wikipedia referencing something I posted elsewhere, it's just as appropriate for me to add the same thing to wikipedia referencing my own post. —Darxus (talk) 05:23, 18 December 2010 (UTC)

Date format

As per WP:DATE the date format YYYY-MM-DD has been deprecated because it is ambiguous and even harmful for users who use YYYY-DD-MM date format. In addition to that, the YYYY-MM-DD date formatting is not consistent with the date format used everywhere else (even the talk signatures use Day Month Year format). Regarding the exception in WP:DATE, it was designed because it'd be very hard to design long tables with many columns. Reference list does not need to conserve space, thus I'm against using YYYY-MM-DD date format.1exec1 (talk) 20:04, 19 December 2010 (UTC)

Who uses YYYY-DD-MM (with dashes)? The only instance I can find is "Nobody uses YYYY-DD-MM." - http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=96476. The long form looks terrible in lists, and YYYY-MM-DD is in order of significance, and is generally easier to read quickly. Does anybody actually interested in the subject of this article think the "8 September 2010" form is best here? —Darxus (talk) 20:55, 19 December 2010 (UTC)

The thing I mentioned about order of significance - you can just read as far into "2010-09-08" as you are interested in precision. You can just skim the beginning if you're just interested in the year, or just the year and month. With "8 September 2010" you have to read through "8 September" to get to the most important part. —Darxus (talk) 20:57, 19 December 2010 (UTC)

1exec1, I apologize for my implication that you are not interested in the subject of this article, it was unfounded. —Darxus (talk) 21:09, 19 December 2010 (UTC)

Indeed the reason why ISO standardized YYYY-MM-DD in ISO 8601 is that it's unambiguous: nobody ever used the YYYY-DD-MM date format. -- intgr [talk] 22:11, 19 December 2010 (UTC)

Yet both formats are deprecated by the Wikipedia. Why to have a problem where there isn't one, please give me at least one reasonable argument to use ????-??-?? over dd Month yyyy. My argument over this is that we must abide to wikipedia manual of style except very rare circumstances. Wikipedia is becoming quality encyclopedia so any inconsistencies must be avoided as plague. Regarding the YYYY-DD-MM format, I don't use this personally, but some people do (google search) and in particular, it seems that it is popular format in Sweden ref.1exec1 (talk) 15:32, 20 December 2010 (UTC)

Regarding the skipping of parts of the date, I saw a research paper somewhere about speed-reading that suggested it's not possible to completely skip small parts of the sentence - either you read them equally good/bad or do not read at all.1exec1 (talk) 15:36, 20 December 2010 (UTC)

I'm pretty sure Wikipedia's policy is that consensus on any one article dictates what that article should be. And the most consistent date format used in those lists in this article before you came here was YYYY-MM-DD. The problem where there was none was created by you. And as I said, YYYY-MM-DD is easier to read. It is my opinion that it should be used for everything in articles for computer geeks, but I'm comfortable just using it in lists and tables where it most improves readability, and using the Wikipedia long form in prose. You see YYYY-MM-DD in lots of computer related things because it's concise, most readable, and sorts. It is elegant in a way that attracts the same people who are attracted to computers. And no, nobody uses YYYY-DD-MM, look at the results of your own google search. That discussion you attribute to Sweden actually says "Here in the Commonwealth, we write out dates in Day/Month/Year order" and questions "Why does the US do it Month/Day/Year? Is it just to be contrary?". I'm in the US. Yes, we use Month/Day/Year sometimes. It's regrettable. Everyone can tell the difference between Month/Day/Year and YYYY-MM-DD. It is the reason for the dashes instead of slashes. —Darxus (talk) 19:26, 20 December 2010 (UTC)

An overriding principle is that style and formatting choices should be consistent within a Wikipedia article, though not necessarily throughout Wikipedia as a whole. Consistency within an article promotes clarity and cohesion.

— WP:MOS#Internal consistency

The Arbitration Committee has ruled that editors should not change an article from one guideline-defined style to another without a substantial reason unrelated to mere choice of style, and that revert-warring over optional styles is unacceptable. Where there is disagreement over which style to use in an article, defer to the style used by the first major contributor.

— WP:MOS#Stability of articles

1exec1, the above quote says specifically that you should not do what you did.

Year-initial numerical (YYYY-MM-DD) dates (e.g. 1976-05-31) are uncommon in English prose, and should not be used within sentences. However, they may be useful in long lists and tables for conciseness.

— WP:MOSDATE#Dates (emphasis added)

Nothing I have suggested using YYYY-MM-DD in is a sentence. All of it is a list or table. —Darxus (talk) 19:58, 20 December 2010 (UTC)

There isn't even anything in WP:DATE that says you should use "day Month year". It says that is "acceptable". And I'll repeat that there is nothing that says YYYY-MM-DD should not be used, except for in sentences, which is not relevant. — Darxus (talk) 21:50, 20 December 2010 (UTC)

"consensus can be assumed if editors stop responding to talk page discussions". Reverting dates not in sentences to numerical format. —Darxus (talk) 19:19, 24 December 2010 (UTC)

Name

06:32PM < Squideshi> krh: How'd you come up with the name Wayland?
06:33PM < krh> Squideshi: I drove through it
06:33PM < krh> http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=wayland+ma&aq=&sll=42.39416,-71.136231&sspn=0.006957,0.016458&ie=UTF8&hq=&hnear=Wayland,+Middlesex,+Massachusetts&ll=42.362603,-71.361694&spn=0.111365,0.263329&z=12

This happened in IRC a few hours ago. —Darxus (talk) 02:27, 25 January 2011 (UTC)

Just before reading this, I changed the article to give this information, using an Ars Technica article as the source. (That's a good article, BTW; we might want to use it for in other places.) Cheers, CWC 07:21, 30 November 2011 (UTC)

FOSDEM 2012 talk

Kristian Høgsberg gave a talk about Wayland at FOSDEM 2012. This pre-FOSDEM interview has some useful info; LWN's report (excellent, as usual) is here. We probably should use these to update the article. Cheers, CWC 15:28, 16 February 2012 (UTC)

Planned adoption / toolkit support

There is some inconsistency in how planned adoption and toolkit support is mentioned. EFL is the only toolkit listed under "Planned adoption". GTK+ and Qt are mentioned elsewhere in the article (both of which I think have pretty decent support in their upcoming releases). Clutter isn't mentioned anywhere, and is probably the toolkit with the most solid support, probably because it's sponsored by Intel which employes krh, the creator of wayland.

I recently got qtwebkit to run via wayland for the first time, which I think is pretty significant.

There's a live cd, with GTK+, Qt, EFL, and Clutter support built for wayland, I believe. Doesn't have qtwebkit yet. http://sourceforge.net/projects/rebeccablackos/ —Darxus (talk) 18:15, 28 March 2012 (UTC)

I attempted to clean up the planned adoption / toolkit support. —Darxus (talk) 20:43, 28 March 2012 (UTC)

Rasterman on moving Tizen to Wayland

https://lists.tizen.org/pipermail/general/2012-January/000312.html
This is interesting because of how qualified he is to answer this. This is the guy who has been doing the Enlightenment window manager since 1997, and wrote the Enlightenment Foundation Libraries, which he says he believes currently has the best wayland support of any graphical toolkit (compared to GTK+ and Qt). Although I wouldn't be surprised if Clutter's is better. This is also interesting because Tizen is the replacement for Meego, which it seemed Intel original hired krh to implement wayland on. —Darxus (talk) 21:40, 28 March 2012 (UTC)

Weston, the reference implimentation, is not Wayland

There's a bunch of stuff in this article that conflates the reference compositor, which has been renamed from wayland-demos to weston, with wayland itself. For example: "Because it requires Linux-specific features such as udev,[38] and KMS, Wayland only works with the Linux kernel." It even has a really solid reference, in the README currently in the wayland source. The problem is that README is so old it pre-dates the separation of the wayland source into wayland, the protocol, and wayland-demos. It's weston that needs udev and KMS, not wayland. Also, krh decided weston is solid enough that it's now more appropriate to call it a reference compositor instead of a demo compositor. I'll try to do some cleaning. —Darxus (talk) 16:15, 29 March 2012 (UTC)

Article needs ongoing work

Writing a good encyclopedic article about a major software project while it is being developed is always going to be hard, so it is no surprise that this article has problems. For one thing, there is a distinct lack of thoughtful overview articles we can cite. Instead we tend to get new snippets of information that someone puts into the article. The best source I know of at present is Daniel Stone's LCA2013 talk (LWN report, MP4 video, OGV video), but it's more of a progress report than an overview.

I write this after starting a short, simple edit (to improve a recently-added ref to Daniel Stone's LCA2013 talk) and finishing up with a long, complex edit. I think the stuff I removed or rewrote is all outdated, but I'm sure there is other outdated/wrong stuff in there. (I ran out of time.) Please check and fix and finish my work.

More importantly, please be especially WP:BOLD about updating, restructuring and even pruning this article. Cheers, CWC 04:47, 16 February 2013 (UTC)

Yeah, the article sort of accreted. People should feel free to do a proper rewrite, or at least reorganisation - David Gerard (talk) 11:08, 16 February 2013 (UTC)

"Nope, it depends on Linux-specific kernel features."

1exec1's response to 89.243.54.169 in the change log. My understanding is that Wayland does not depend on anything but the ability to pass shared memory (SHM) buffers between applications (how clients pass their graphical output to the server). I suspect you were referring to KMS or something - a dependency not of Wayland, but of the only implementation of it so far, which is only a demo, and has very little to do with actual requirements of implementation. I encourage you again to read the stuff I've written up on my understanding of Wayland: http://www.chaosreigns.com/wayland/. I posted it to the mailing list. The only response I got was off list with a couple very minor changes. However, I don't know of anyone who has expressed interest in making Wayland work off of Linux, so the wording of the article doesn't much matter to me. —Darxus (talk) 01:36, 24 December 2010 (UTC)

Yes I agree that I didn't do research what particular features of Linux kernel Wayland does depend on. But the idea of Wayland itself is that much of once relevant, but now obsolete X server features have moved either to kernel or to userspace libraries. So at the end it will depend on the kernel much more and we can't conclude that it will run on any Unix-like operating system when no implementations (even on Linux) exist. Of course, as far as open source concerned, it's always possible to add the needed kernel functionality in the form of kernel modules, so in practice Wayland will be implemented on many platforms.1exec1 (talk) 10:44, 24 December 2010 (UTC)

AFAIR, Weston was written exclusively for the Linux kernel. But the other implementations of Wayland libwayland-client, -server and -EGL are not Linux-specific. It should also be possible to write a commercial implementation for Mac OS, Windows, etc. ScotXW (talk) 13:27, 4 September 2013 (UTC)

SDL under development or done (good enough)?

SDL says "while SDL has been ported to also be used on Wayland" but links to [1]. Wikipedia is not a good source. Going by what it links to would be ok (maybe it's outdated or SDL page need to be updated). comp.arch (talk) 16:26, 28 February 2014 (UTC)

Well, we can put this one or we can wait until the release of SDL 2.0.2 and use the announce link --JavierCantero (talk) 19:38, 28 February 2014 (UTC)

You can try SDL here: Hawaii (desktop environment), see announcement: http://lists.freedesktop.org/archives/wayland-devel/2014-March/013831.html I guess the SDL port is working User:ScotXW^t@lk 19:08, 22 March 2014 (UTC)

Advantages of Wayland

From https://wiki.gnome.org/Initiatives/Wayland#Why_switch_to_Wayland_.3F

• input transformation
• transparent hardware overlays
• direct rendering
• isolating clients (sandboxing)
• makes it possible to reuse android drivers (via libhybris), but also see direct vs indirect rendering
• per-crtc EGLSurfaces means repainting and swapping only the monitor where content changes
• smooth transition between composited desktop and fullscreen clients (no X unredirect flicker)
• eliminates lag between cursor and dragged windows (eg moving toplevels or dnd icons)
• better remote display
• ...

We could use this to rewrite this article. User:ScotXW^t@lk 20:18, 17 March 2014 (UTC)

Could you, please, explain why would we need to rewrite this article? Adding new or updating current content is always a good thing, but this article isn't in need of a complete rewrite. — Dsimic (talk | contribs) 06:43, 18 March 2014 (UTC)

Clearly Special:Permalink/600768793#Adoption needs to be rewrited. And some other portions as well. Also, the article bears 104 references. I could image a couple are superfluous. User:ScotXW^t@lk 19:07, 22 March 2014 (UTC)

That's to be expected for the "Adoption" section in any article, if you agree – such sections reflect the current state of projects, thus requiring constant maintenance so they stay up-to-date. Please don't get me wrong, this article surely can (and should) be better, but it doesn't require to be torn down and rebuilt from ground. — Dsimic (talk | contribs) 06:44, 23 March 2014 (UTC)

I don't think that any of Wikipedia’s principles is to minimize the use of references. Right now Wayland is in the process of being adopted. I think that currently a list-like structure serves readers better (although I think it was a mistake to transform the section into a bullet point list – whoever did that should IMO consider reverting it to the previous layout). Once adoption is further along (probably sometime in 2015) it can be rewritten into prose form and merged into history. --KAMiKAZOW (talk) 15:33, 23 March 2014 (UTC)

Well, it was me doing the layout compaction... Had a look again at the previous version, and it really doesn't look better or more usable – at least not to me. If there was more content for each of the items, the previous layout would be better; with only brief descriptions, a bulleted list should be more suitable. — Dsimic (talk | contribs) 16:15, 24 March 2014 (UTC)

The term Display Manager is perfectly fine

A recent change questioned the term 'Display manager' and replaced it with 'Display server'. Putting aside that using derogatory terms in the summary is disrespectful and probably against the rules of Wikipedia (at least the social rules), the fact is 'display manager' is a generic term and perfectly valid in that context. The author of that comments is confusing a display manager (the subsystem that manages or handles the display in a certain system) with the X display manager that certainly is another (and very specific) module of the X architecture. The term 'display server' is applicable only with client-server architectures, and that certainly covers both Wayland and X. But not all display managers are client-server architectures, so not in every place are the terms interchangeable, and the term 'display manager', more generic, is preferred when compared to any display subsystem. That said, the third of the changes in the 'Weston' section is in my opinion, well done, because in than section is specifically talking about Wayland display managers, that are obligatory servers.

By the way, there is a second laughable statement in which the same person mistakes the on-screen (display) buffer, also called the front buffer, with the term "on-screen display" (OSD). He is clearly not understanding the sentence so I think it can be changed to "It will composite those buffers to form the on-screen display buffer of application windows" to avoid future misunderstandings.

To the person responsible of the changes: please next time, before gratuitously insulting or accusing anyone, comment the potential errors with the rest of the editors, in a friendly tone if that's posible. Thank you. --JavierCantero (talk) 15:26, 15 June 2014 (UTC)

If it is possible, yes, I promise. User:ScotXW^t@lk 06:32, 19 June 2014 (UTC)

"Unity isn't directly related to Compiz...."

"Unity isn't directly related to Compiz in the same way as the other 2 mentioned WMs, removing" - http://en.wikipedia.org/w/index.php?title=Wayland_%28display_server_protocol%29&diff=485177034&oldid=484832941
Really? Unity runs on Compiz, Sam Spilsbury, the Compiz maintainer, is employed by Canonical to work on Compiz + Unity. Compiz can be used with other things, just like Mutter. I'd say Compiz is related to Unity exactly as Mutter is related to gnome shell. Particularly since the other way Compiz was being used was on gnome desktops, which it isn't anymore due to the gnome transition to Mutter. I don't like Unity either, but that doesn't make the connection between it and Compiz worth deleting. —Darxus (talk) 18:28, 2 April 2012 (UTC)

Yes, these days Compiz and Unity are related like Mutter and GNOME Shell but the article talks only about window managers. IMO no DE should be mentioned at all in that context. Only the WMs themselves. --KAMiKAZOW (talk) 21:46, 2 April 2012 (UTC)

I think they're worth mentioning because the DEs are names people know, and the window managers often aren't. The planned adoption section has a "KDE" item, so I don't know why you said the article only talks about window managers. The Ubuntu item mentions Unity. —Darxus (talk) 16:43, 4 April 2012 (UTC)

They are mentioned in the Adoption section. KDE is not the name of a desktop environment, BTW. If you add such info, better do it right. --KAMiKAZOW (talk) 12:28, 9 April 2012 (UTC)

Gotta love it when the K Desktop Environment isn't a desktop environment. —Darxus (talk) 18:18, 9 April 2012 (UTC)

It is not my duty to explain to everything. Read KDE and KDE Plasma Workspaces yourself and discover that “K Desktop Environment” is dead since years. --KAMiKAZOW (talk) 00:01, 10 April 2012 (UTC)

"It is not my duty to explain to everything." In case other people try to do that, this is supposed to be an encyclopedia, over several articles, please do not stand uselessly in the way. Also, please note, that in other languages, the KDE-article ist still describing the desktop environment, not the community and a KDE SC article does not exist. If this all has become too complicated for you, maybe somebody else can take over, my dear? User:ScotXW^t@lk 09:51, 21 June 2014 (UTC)

Window Manager

There are some comments that Wayland will replace KWin/Metacity/etc window managers. But it looks to me that it replaces the compositing part and the intention is for user-space libraries to draw the window borders and decorations as part of the buffer given to Wayland.

IMHO this would be vastly superior solution, since in current X the amount of code needed to control window manager decorations is far larger than what would be needed to directly draw them (assuming the program already can draw buttons), and it locks the design and prevents evolution of new appearances and uses of window borders, and it is obvious that toolkit and application designers could take huge advantage of controlling this area of the screen.

However one disadvantage is "inconsistency" (window borders could differ depending on the application, though IMHO this problem already exists for all the buttons and other GUI inside the window so a solution should be tried for everything, not just the borders). A second disadvantage is that the X emulator would have to include a fake window manager to add borders to X programs. I think there many also be disadvantages in making Wayland clients portable to other systems, as I think both Windows and OSX do not include the window borders as part of the memory-mapped image the client can write to, though again I'm not sure if mistakes made on those systems and on X should dictate Wayland's design

Anyway I cannot find any statement anywhere in the Wayland documentation or in all the discussions indicating if the window border drawing has been moved to the client code. This would seem to be a major aspect of Waylands design so an answer would be nice to add to this article.Spitzak (talk) 20:48, 4 January 2011 (UTC)

Wayland doesn't replace any of KWin/Metacity/etc. except allowing them to communicate with client applications directly through the Wayland protocol instead of through an X server (and encouraging direct communication with hardware (keyboard / mouse / video)). KWin and Metacity are expected to become Wayland display servers by implementing the Wayland protocol. KWin and Metacity still do the compositing. The existing Wayland display server is only a demo, and not intended to replace anything.

Yes, with Wayland, window decoration is the responsibility of the client applications, largely for the reasons you mentioned (find some references here http://www.google.com/search?q=wayland+client+decoration). Client side decoration is being implemented in GTK, and probably Qt. And yes, consistency is a problem, although not an entirely new one. For example, chrome / chromium does its own thing for drawing tabs in the title bar. Gnome and KDE exist largely to address the problem of GUI consistency.

Wayland client portability to other operating systems will be handled by those clients using graphics libraries capable of output directly to the graphics systems on those operating systems, as they (GTK, Qt, etc.) already do.

There is no "X emulator". The commonly used X server, X.org, has been modified to run as a Wayland client. And no fake window managers. This is a screenshot of the compiz window manager running on an X.org server that is a wayland client: http://wayland.freedesktop.org/fullscreen-x-compiz.png. Apparently window decorations from the window manager are copied over just fine when running rootless: http://wayland.freedesktop.org/rootless-x-under-wayland.png. —Darxus (talk) 21:23, 4 January 2011 (UTC)

Metacity is a bad example since it has been replaced by Mutter (in gnome 3), it may have no future. —Darxus (talk) 00:28, 5 January 2011 (UTC)

Thanks for the searches. It does appear the clients are to draw the window borders.Spitzak (talk) 20:35, 5 January 2011 (UTC)

The articles Display server and Windowing system are supposed to provide the necessary knowledge to understand better what the Wayland protocol is supposed to do. The article Display manager does not, BTW. The article compositing window manager is also misleading. In case you do not grasp why, don't bother, move on. User:ScotXW^t@lk 09:56, 21 June 2014 (UTC)

Why the rush?

Why the rush to include every piece of information of things that are clearly "Under Construction", therefore ill-defined and subject to change? This is not a race to win anything. The last example is the XDG-Shell protocol, but I can cite libinput, WRandR, and that only in the last few months! Here is my alternative: allocate a section in this Talk page for information and links that can be relevant in the future, when associated parts will be written. If that's not ok, a second proposition maybe a "Future developments" section in the Article page, remarking that they are ongoing developments, and therefore the information provided may be unreliable. --JavierCantero (talk) 15:44, 15 June 2014 (UTC)

Seems reasonable. The stuff is by ScotXW, a guy who is currently blocked for edit warring. He has zero sensibility how Wikipedia works and lacks all desire to learn. Maybe the block will change his mind.

This is Wikipedia: Feel free to improve this article. I'll back you, should ScotXW interfere. --KAMiKAZOW (talk) 00:49, 16 June 2014 (UTC)

While ScotXW is mentioned, yeah, he (or she?) does introduce confusion quite often – as in this, so in other articles. I've tried to talk with him a few times, with intentions to explain the nature of Wikipedia and point out what he should do better, but his tone is pretty much unfriendly. On the other side, he mostly contributes good content, but it's obvious that his knowledge of English could be better, and many times added content simply isn't encyclopedic enough. Just a few thoughts from my side. — Dsimic (talk | contribs) 04:59, 18 June 2014 (UTC)

I will keep your very objective and useful comments in mind. Anything of substance? User:ScotXW^t@lk 06:30, 19 June 2014 (UTC)

The first thing I think is to move the xdg-shell section that you wrote to a "Futher Developments" (or something similar) section. Whenever it finally gets released (supposedly in Wayland 1.6, but it might be later) it can be moved to its final place. Also, I want to propose to get rid of mentions to C functions, C headers and so: that implies that the person reading the article knows programming (C programming to be exact). That's a severe assumption and (in my humble opinion) I don't think is a good style to explain anyone what is Wayland or how it works. The description should be (again, in my opinion) more high level, accessible to everybody. If you all agree, I can write an alternative version of that part (except there is anybody willing to do it, of course). --JavierCantero (talk) 10:35, 19 June 2014 (UTC)

In case you really want to write an article for morons, please use the simple:Wayland instead. Simple English for simple people. I don't mind making and keeping something accessible for blind people or physically impaired people, but keeping an encyclopedic article "accessible" for the stupid, costs too much. Why not make the article Windowing system more ... "accessible"? DO NOT use schemes or diagrams, they could be too, "confusing". User:ScotXW^t@lk 09:46, 21 June 2014 (UTC)

Umh, calling people morons isn't that great. While I do agree that the majority of people isn't that smart, everyone is lacking extensive knowledge in at least some areas. For example, I have no idea about which brand of pipe bags is considered the best, or which exotic tea flavors are available out there and how are they prepared; the fact is that I pretty much don't care about pipe bags and exotic teas, but I'd be able to Google that out in a few minutes if I wanted so. Why? Because someone wrote about those things in an accessible language for the people who aren't experts in those areas.

Pretty much the same applies to Wikipedia – articles should be accessible to people who aren't experts in the field. Of course, there's also no point in writing trivial articles, so about one half of each article should be easily accessible, while another half should contain more in-depth coverage. At least that's how I see the things. :) — Dsimic (talk | contribs) 14:59, 22 June 2014 (UTC)

I was not talking about using a simplified English, but about not requiring be a computer expert to be able to read a Wikipedia entry. See Wikipedia:What Wikipedia is not#Wikipedia is not a manual, guidebook, textbook, or scientific journal, point 7. --JavierCantero (talk) 10:55, 24 June 2014 (UTC)

It’s funny how Scot repeatedly calls others idiots but over and over again fails to grasp simple Wikipedia concepts. --KAMiKAZOW (talk) 11:38, 25 June 2014 (UTC)

Section: Software architecture

I just stumbled over http://blog.mecheye.net/2014/06/xdg-shell/ a blog post by the main Wayland developer for GNOME, it should be used to rewrite the Software architecture section, because ATM it simply composed out of a huge citation. This is still better than other mentionings of Wayland in the Wikipedia, where it usually quotes: "every frame is perfect". This article, especially its section "Software architecture" should really bother to explain HOW this "perfectness" is actually achieved. xD Of course I am going to do that, in case anybody else is interested, the blogpost is really useful. User:ScotXW^t@lk 17:35, 24 July 2014 (UTC)

The relevant info is in the chapters 3 (that has the same content that Wayland architecture) and 4 of the Wayland documentation. Jasper's article is not really centered in Wayland architecture. For example, it doesn't describe basic concepts like what is an interface (in Wayland terminology) and its elements (Request, Events, Errors), or what is an object and how are they (interfaces and objects) related. When these basic concepts are established then it's possible to start to talk about the basic interfaces like wl_compositor, wl_display, wl_surface or wl_buffer, explaining how they work together to achieve the goal of "perfectnesss".

Sadly, the Wayland documentations lacks of good explanations of its own terminology, and its more a quick list of existing interfaces with low level of detail of each one. If anyone is aware of a better source of information about this, I'll be happy to know about it. --JavierCantero (talk) 09:28, 25 July 2014 (UTC)

Also, I'd like to propose to move the first paragraphs of the actual "Software Architecture", including the huge quote, to its own section called "Overwiew". Thoughts? --JavierCantero (talk) 09:48, 25 July 2014 (UTC)

Well, I didn't wait, and the change of the section names is done, as well as the start of the new "Software Architecture" section (Does anyone else think that "Architecture" alone is better?). ScotXW, I created the "Render model" subsection because I think it's about that what you want to write, isn't? In any case it is going to be needed sooner or later... --JavierCantero (talk) 16:57, 25 July 2014 (UTC)

1. Nice work.
2. Since this is an article about software, and there is the article software architecture, I would keep calling the section like that, you know, to make it easier for the less gifted people to look stuff they have no idea about up. Something about cross-referencing in an online encyclopedia.
3. Let's make section "overview" for non-technically interested users, who'd like to know more about Wayland, and section "Software architecture" really technical.User:ScotXW^t@lk 20:07, 26 July 2014 (UTC)

The article looks much better, keep up the good work! — Dsimic (talk | contribs) 18:22, 29 July 2014 (UTC)

Wayland protocol architecture diagram

Some comments about ScottWX's change:

• The diagram is right.
• The diagram is ilustrating the text of the section, that is backed by the Wayland documentation itself.
• When two process communicate, they always use one of the many IPC methods provided by the kernel. They never communicate directly, there is not such thing. Even when they use files, they are using the kernel (read() and write() syscalls). In the case of D-Bus it also uses unix domain sockets internally or alternatively TCP/IP sockets, both kernel IPC mechanisms (among others). This is basic operating system stuff that everyone participating in this article (at least the technical parts) should know.
• libwayland-client and libwayland-server specifically use unix domain sockets. See the Wayland source code if you don't believe the official documentation or me.
• This is not the first or the second time this guy insults using the Edit summary field, while he is who is plainly wrong.

I don't want to sound arrogant, but I'm tired of wasting my time explaining basic stuff, instead of using that time in better ways (like improving the article). Next time the same thing occur, I'm going to revert the change labeling it as "Vandalism". No explanations of basic stuff. I don't want to be part of warring edition, but I'm not anyone's teacher, and my patience has limits. --JavierCantero (talk) 15:03, 31 August 2014 (UTC)

Well, let's ping ScotXW and maybe we can get something better than his/her usual "I don't care, it's a work in progress". :) — Dsimic (talk | contribs) 09:55, 2 September 2014 (UTC)

Work In Progress is not a valid excuse since anyone can use Help:Userspace drafts or Help:Talkspace drafts or even Wikipedia:Workpages to avoid interferences with the main article. By the way, this is my userspace draft of parts of this article User:JavierCantero/Wayland (display server protocol). I'm using it before adding any significant portions to the article. --JavierCantero (talk) 17:22, 2 September 2014 (UTC)

Thank you for your competent input here. User-space programs are indeed forced to use the IPC primitives provided by the kernel (or kdbus). The problem is, that this abstracts the point to far away. This article is primarily about the Wayland __protocol__. But yes, I am absolutely for a much deeper documentation, not as a replacement but as augmentation. Another very interesting field is multi-seat functionality. Google gave me some stuff by Dadid Hermann (e.g. kmscon) who did some documentation. But IMHO this field should NOT be documentated in this article, this article should concentrate on the Wayland core protocol and the extension protocols. I hope you all agree. User:ScotXW^t@lk 14:04, 24 February 2015 (UTC)

Yes, it's a bit deep, but there is a reason: I may need to add later a more detailed diagram to explain how the direct rendering is handled by the protocol (as opposed to how it is done in core X), and that implies talking about memory objects passing through the kernel. If I already place the kernel in this simpler scheme, I think I'm laying the groundwork to make it easier to understand in futher, complex diagrams.

Regarding multi-seat functionality: it's part of the core Wayland protocol. The protocol not only defines multiple input (keyboards, mouses, ...) and output (screens) objects, but also defines an explicit wl_seat object to bind them (this screen with this pointer and this keyboard, and so), and this is also an important feature that sets Wayland approach apart from the X approach. So if you have relevant information about it, expanding what is already written, please consider adding it to the article. --JavierCantero (talk) 11:36, 25 February 2015 (UTC)

1. I commented on that pictures talk-site, it is IMHO wrong/misleading, I did not remove it from THIS article! Please DO ADD more information, to make your picture/diagram/scheme LESS misleading, soon. User:ScotXW^t@lk 13:52, 13 March 2015 (UTC)

License

The article and Wayland's FAQ claim that the used software license is the MIT license. However http://cgit.freedesktop.org/wayland/wayland/tree/COPYING is not the MIT License text. It's the HPND. See http://opensource.org/licenses/HPND

Therefore I'd like to revert [2] --KAMiKAZOW (talk) 23:01, 21 May 2015 (UTC)

You should revert it, clearly the license is the Historical Permission Notice and Disclaimer, not the MIT License. They are even using the no-promotion clause that is equivalent to 3-clause BSD license and not present in the MIT-style licenses. --JavierCantero (talk) 09:35, 22 May 2015 (UTC)

It is not the HPND. It seems to be a combination of a couple of the many MIT variants documented on Fedora's wiki: https://fedoraproject.org/wiki/Licensing:MIT . --Hroðulf (or Hrothulf) (Talk) 18:07, 2 June 2015 (UTC)

What Fedora's wiki calls "old-style MIT" is what OSI calls Historical Permission Notice and Disclaimer. --JavierCantero (talk) 10:14, 3 June 2015 (UTC)

Following my inquiry to the Wayland mailing list (you may have read about it on Phoronix…), the license text has been changed to the "regular" MIT/Expat license. --KAMiKAZOW (talk) 01:46, 13 June 2015 (UTC)

Removing Inadequate lead template

I think the introductory text now adequately summarizes the article, therefore I'd like to remove the "Inadequate lead" template. --JavierCantero (talk) 10:00, 15 October 2015 (UTC)

Linux-only

I've just edited the article to say that Wayland requires Linux, not just a UNIX-like OS. I added a short explanation of this to the "Design" section:

Because it requires [[Linux]-specific features such as <!--[[Graphics Execution Manager|GEM]],--> [[udev]], <ref>[http://cgit.freedesktop.org/wayland/wayland/plain/README README] file from the Wayland source code repository</ref> and [[Kernel mode-setting|KMS]], Wayland only works with the [[Linux kernel]].

It is my understanding that Wayland relies heavily on GEM, but I don't have any solid source for that, so I commented out that part of the list. There are plenty of web pages saying (accurately) that Wayland requires udev; I used the README from the code repository because I happened to have it open in a browser tab, but it's not ideal as a Wikipedia source. There are acceptable sources saying (accurately) that Wayland builds on KMS, but I don't know of any good source saying that Wayland requires KMS, let alone explaining why. If anyone reading this knows of such a source, please add it to the article.

I've carefully used the present tense here. FreeBSD is paying someone to "implement support of GEM, KMS, and DRI for Intel Drivers" (see also http://wiki.freebsd.org/Intel_GPU). I guess that might, when finished, make it possible to port Wayland to FreeBSD by replacing the udev-related code, in which case we'd need to change the article to say "Linux or FreeBSD".

I feel that is worth saying in the article that Wayland is Linux-specific, because there is some interest in that, but it would be wrong to speculate about porting it to FreeBSD or anywhere else. OTOH, I'm verging on WP:OR, so I'd like to hear what other editors think about this. Cheers, CWC 07:50, 30 November 2011 (UTC)

IMO unless someone disputes that fact as factually incorrect, it's OK to have only weak sources. BTW, another source: [3], section X.Org and KMS. 1exec1 (talk) 11:53, 30 November 2011 (UTC)

Thanks for that link, 1exec1. For other readers: it's an article titled "Choosing between portability and innovation" from March 2011. The author doesn't mention Wayland, but does discuss KMS, GEM and udev in detail. In my limited understand (I have not researched this in any depth), with those 3 you could, at least in theory, port the Wayland library. As mentioned above, someone is adding KMS and GEM to FreeBSD, at least for Intel graphics drivers. Moreover, someone has added a udev-lookalike to DragonFly BSD, a FreeBSD derivative. So I wouldn't rule out the possibility of DragonFly and/or FreeBSD running Wayland within a few years.

On a related topic, User:KAMiKAZOW has a good point in this edit. The current implementation is Linux-specific, but the protocol is more general, modulo the GEM buffer ID thing. Thanks for correcting my thinking, KAMiKAZOW. CWC 03:42, 1 December 2011 (UTC)

I've commented out "and KMS" due to KMS support being added for Intel GPUs in FreeBSD 9.1.

Do not forget Generic Buffer Management (GBM). User:ScotXW^t@lk 09:53, 21 June 2014 (UTC)

Or NOT Linux Only

To implement a Wayland client application, one needs

1. to be able to link with the wayland-client library
2. to be able to create a handle representing shared memory that can be passed over some IPC to the wayland server that is running your display.

I think that the conclusion should be that the BSDs can implement this and therefore Wayland-based applications would port to BSDs. Also even though Cygwin is challenged to support this in a true-POSIX way, you could implement a Windows-based server that Cygwin apps could talk to using a special wayland-client library that used Windows stuff (perhaps named pipes) to implement the details, and then an application would build and run on Cygwin and be using Wayland. That last part is speculative but I think it could inform a conclusion that ultimately, Wayland is not Linux-specific.

One should not decide this issue based on whether a given *server* could be ported, or even a given wayland-client library could be ported. That would be like saying that a web browser couldn't run on Windows because Amaya depended on XLib (which I don't know if it does just an example no sweat). Cardiffman (talk) 02:12, 19 December 2015 (UTC)

The same way that Wayland can also potentially be ported to any operating system with IPC, including Windows, MacOS X, AmigaOS, ... But that's not the point. Wikipedia articles must reflect facts, not possibilities. And the fact is today the only implementation available is for Linux. We must wait until Wayland is ported to another operating system/plataform to add it to the article (with the appropriate references). --JavierCantero (talk) 13:44, 19 December 2015 (UTC)

Wayland is a protocol, not a program. Therefore, by definition, it's not restricted to any particular system. There is nothing to port. Any system that can implement the protocol can have Wayland. CodeCat (talk) 20:59, 19 December 2015 (UTC)

(From the lead) "Wayland is a protocol [...] as well as a reference implementation of the protocol in the C programming language." And that reference implementation needs to be ported to a specific operating system/plataform. Anyway, that is not a reason to say that is available in a particular system (such as BSDs in the original comment) because it "can be implemented". Not before it really happens. --JavierCantero (talk) 16:17, 20 December 2015 (UTC)

The reference implementation is Weston, not Wayland. CodeCat (talk) 18:27, 20 December 2015 (UTC)

Weston is the reference implementation of a Wayland compositor, not the reference implementation of the Wayland protocol. --JavierCantero (talk) 22:52, 20 December 2015 (UTC)

Change to List-defined references

I want to propose a change in the referencing style to List-defined references. Right now the references are scattered throughout the article body, making it difficult to keep them consistent and without duplicates. It's not usually a problem when the article is small and the references few, but with 150 references (and increasing) this is basically unmaintainable. I am ready to make the change —in fact I already coded and tested a script to automate the change— but WP:CITEVAR says that first we need to seek consensus for the change of reference style. So the question is: is anyone against it? --JavierCantero (talk) 21:18, 2 March 2016 (UTC)

Since no one has expressed opposition to the list-defined referencing style (or maybe no one cares), I've already done the migration (except for one reference in the infobox to the last preview release that is updated very often, so I left it inlined for convenience). Now I should order the references and merge the duplicated ones to complete the work. --JavierCantero (talk) 16:06, 9 March 2016 (UTC)

I vote - yes - to support u, better later then never (Ocexyz (talk) 10:20, 10 March 2016 (UTC)).

Network Transparency

Some patches have been published for this: https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Network-Transparency

— Preceding unsigned comment added by 82.108.130.2 (talk) 10:57, 14 March 2016 (UTC)

Actually the recent patches are somewhat a big deal as they actually send Wayland protocol over the socket to the remote server. Previously all discussion of remote desktop assumed it would be done by clients talking to a local "fake" wayland server, that then used a protocol such as RDP to communicate with the remote end. It is not clear if everybody considers this new idea the correct thing to do but it is a major change.Spitzak (talk) 19:59, 14 March 2016 (UTC)

If the patches are mainlined, then when they are part of a new Wayland release is when we should reflect that fact in the article, not before. Right now, as far as we know, the patches could be rejected, postponed, heavily modified... Wikipedia is not a crystal ball, so please refrain to include future events in an article until they really happen. --JavierCantero (talk) 18:17, 16 March 2016 (UTC)

I think you deleted text somebody else put in there, I did not do that. The text you deleted was the "older" version where there is a local wayland server that then does the remote communication. The recent patches posted by Derek Foreman [[4]] and [[5]] describe a new scheme by which a Wayland client talks directly to a socket to a remote wayland server, there is no local wayland server. I agree none of this should be put in the article as it is a prediction.Spitzak (talk) 01:57, 17 March 2016 (UTC)

Releases table text size to 85%?

What is the purpose of reducing the Releases table text font size to 85%? It's almost illegible (see MOS:FONTSIZE). If the problem is the table size with some resolutions, I suggest tweaking the table column sizes instead. --JavierCantero (talk) 10:46, 17 April 2016 (UTC)

I removed the 85% definition. When I added the table, it was supposed to look like https://en.wikipedia.org/w/index.php?title=Wayland_%28display_server_protocol%29&oldid=576292347#Adoption

Whoever found it necessary to bloat up the table's contents so much can now take care of properly making it readable again. --KAMiKAZOW (talk) 15:07, 18 April 2016 (UTC)

I was not refering to that. The table size change I was talking about was done two days ago, and it reduced the font size of the table from normal size to 85% without providing any reason. --JavierCantero (talk) 15:14, 18 April 2016 (UTC)

What about the section "Wayland Security Module"?

The "Wayland Security Module" section refers to a feature proposed in 2014 but never added to Wayland/Weston. Two years have passed and there are no signs of a future merge either. What shall we do? The content is interesting, but nowadays it leads to error since it's not implemented and maybe it never will be. (By the way, this is what happens when someone doesn't follow WP:Crystalball and try to anticipate events) --JavierCantero (talk) 18:16, 9 May 2016 (UTC)

Security

bloviating

"Security: Wayland isolates the input and output of every window, achieving confidentiality, integrity and availability in both cases; X lacks these important security features"

This couldn't be further from the truth: the author of the above obviously hasn't read X11R6's documentation nor X.org's. See manpage XSecurity(1). What is true is that Myths about X are not new at all - one can google up X documentation citing them and answering them.

Much of the talk in the article, (ie, that networking isn't important, fonts aren't important, drawing lines isn't important, ...) simply denies the fact existing applications exist and the above are highly efficient and useful.

the only efficient way to provide client server (and network transparency, and that is compatible with various electronics): is X11. they did it right the first time. when wayland gets these things it will just be cut and past from X11 with the W name on it, which i imagine is the intent - like most copy lefts these days.

(all i see is a group effort to "rebrand X11" by shifting it registers, supplying the missing parts from X11 later)

First, a Wikipedia Talk page is not a forum. Talk pages exist for the purpose of discussing how to improve articles. Talk pages are not for general discussion about the subject of the article. The purpose of an article's talk page is "to provide space for editors to discuss changes to its associated article or project page. Article talk pages should not be used by editors as platforms for their personal views on a subject". It's important to be constructive: "Article talk pages should be used to discuss ways to improve an article; not to criticize, pick apart, or vent about the current status of an article or its subject". See WP:TALK#USE for more information.

Second, the statement about the security comparation is well backed and properly referenced — no less but by a proceeding about Graphics stack security during the X Developer's Summit of 2012. The XSecurity(1) man page only talks about access methods to open a connection with a X Server. Once the connection is open, each X11 client has whole access (read and write) to all the X resources in the server, even those from another X clients, including window contents and events. That's the reason why X architecture doesn't comply with the CIA triad and is considered inherently insecure (opposite to Wayland architecture which doesn't allow such level of access between Wayland clients).

About the remainder comments, I'm only going to say you that Wikipedians don't tolerate those who come here to troll like this is another forum. Destructive intents are not welcome. You have been warned. --JavierCantero (talk) 10:28, 13 April 2016 (UTC)

The user is clearly annoyed with this repeated myth and to be fair, it's kind of annoying to see Wikipedia propagate this, but this is in line with Wikipedia's mission statement of simply reporting the mainstream consensus of 'authoritative sources', it is well cited, the authoritative 'experts' in this case however are wrong is the problem.

About your second point, the X11 SECURITY extension which Xorg implements stops all that of which you speak, this is for instance used by OpenSSH by default and any client can be launched inside Xorg and most other X servers as 'untrusted', in which case that can't access all that data at all. Your interpretation of the X11 SECURITY extension is wrong. X11 allows a client to connect with limited privileges, it can only read input events that belong to its own 'subview' if the server, so it can read from other clients input that exist in the same subview with multiple untrusted subviews being able to exist. 'trusted' clients can read everything. The problem is again that a lot of sources which are perceived as 'authoritative' act like it doesn't exist which is unusual since it is widely used and OpenSSH is a major consumer of it. When people use X forwarding over OpenSSH by default they use an untrusted client, that client cannot get input events from the rest of the display. So what do we do here? I'm not going to edit the page because it has authoritative citations, but I will leave you with a primary source ( https://www.x.org/wiki/Development/Documentation/Security/ ) that under the header 'server access control' explains succinctly what it does. 81.204.20.107 (talk) 05:55, 9 August 2016 (UTC)

My interpretation of what the original message is arguing is right: go to the XSecurity(1) manpage (that is the source he/she provides to justify his/her complains) and see yourself that there is no mention to the SECURITY extension; it only talks about X Server authentication methods, i.e. methods to authenticate within the X Server and gain access (total access) to it. He/she is not only contemptuously arguing, but also not providing sources to support his/her claims —even the opposite: providing a source that defeat his/her claim. (FWIW there is not almost any documentation about SECURITY extension anywhere, is something totally obscure but that is not an excuse for behaving the way he/she did).

Regarding your complain of Wikipedia propagating a myth: this is not a myth, this is a real situation. No distribution uses the SECURITY extension (as well as nobody uses XACE, a more appropiate security framework) to avoid/limit local X applications to run as untrusted ones. The criticism exposed by the experts (without quotes) are not only valid, but on point, since it's a real problem that affects X users in the real world, and therefore something that must be accept as a valid argument. The opposite will not be a neutral point of view, but trying to hide the flaws of one of the "contenders".

Also, as I said, this is not a forum and therefore is not the place to discuss about this (or really anything subject-related). And trying to "hijack" WP pages to favor one's stance in a discussion is not very "well received" in Wikipedia either. --JavierCantero (talk) 10:50, 9 August 2016 (UTC)

1) Well, he or she didn't link anything, and neither did you, I did link something which says that it is wrong. I'm the only one here that did provide sources which pretty unambiguously say your interpretation is wrong.

2) My distribution uses it, as well as many others, as I said, a known real world consumer of it is OpenSSH which is pretty big. You ca see if your distribution does it by doing `ssh -X somehost` and see if it fails, if it fails and `ssh -Y somehost` works, your distribution compiles without the SECURITY extension most likely.

3) It indeed isn't, as I said, Wikipedia's mission is to simply restate what 'authoritative' people say. However the talk page is definitely the forum to address what do when Wikipedia contains a clear factual inaccuracy. And there is certainly room for discussion when the Xorg documentation pages contradict what authoritative people having talks on conference say. At this moment, Wikipedia contains a factual inaccuracy and there is an authoritative citation on point that shows it as much. The discussion here is whether or not Xorg's own documentation which is a primary source and thus biased and not objective over talks of people may or may not also have their own biases. In any case, the sentence 'X lacks these important features' is incomplete at best, the X security extension which does exactly that is provided by any big X server implementation that I know of. Xorg, Xephyr and Xpra all provide it. In that sense I do believe it should be mentioned. 81.204.20.107 (talk) 13:07, 9 August 2016 (UTC)

1) man Xsecurity (I'm sure there is some outdated version of the man page out there if you bother to find it, but I prefer the source)

2) No, your distribution doesn't use it for local applications, that is the relevant scenario to compare with here (Wayland is not a remote protocol).

3) No, there is not "factual inaccuracy". Right now, there is only this sentence with two facts: "Security: Wayland isolates the input and output of every window, achieving confidentiality, integrity and availability in both cases; X lacks these important security features". The first is obviously true (it's how Wayland protocol is designed). The second, "X lacks these important security features" is what I understand you want to challenge. The fact is, no distribution provides isolation between local X clients as the Wayland model does, not even using SECURITY, XACE or another extension (standard X can't). That is the true, and that is what the related cites are supporting (BTW, from recent XDCs, presented by X developers to X developers). There is not " Xorg documentation pages contradict what authoritative people having talks on conference say", there is some (obscure and not very developed in the case of SECURITY) documentation to extensions that might be used to implement the equivalent of the Wayland isolation in an X environment. And I said might because I suppose you are right and they are equivalent, but Wikipedia is not built upon assumptions and a study from an appropiate source to support it should be provided before being considered factual. And that's not the case. --JavierCantero (talk) 14:52, 9 August 2016 (UTC)

size in {{infobox software

Where does the 100kb size estimate in the infobox come from? For instance, does it refer to the collection of Wayland source code or the approximate size of the compiled binaries? 128.12.254.132 (talk) 02:09, 7 May 2017 (UTC)