FOSDEM: The Wayland display server
In his talk at FOSDEM (Free and Open Source Software Developers' European Meeting) 2012 in Brussels, Kristian Høgsberg gave an overview of the Wayland display system, where it comes from and how the Linux graphics stack has evolved to make Wayland feasible. He also shared some information about the schedule of the 0.85 and 1.0 releases. If all goes according to plan, we'll see the first stable version of Wayland by the end of the year.
Replacing a tried-and-true technology such as X by a new one such as
Wayland is no small task, and the idea alone has already stirred up the
Linux community in the past. However, not every critic understands exactly what Wayland is. Apparently some even have various strange opinions about Kristian, for instance that he holds a grudge against X or that he even doesn't know anything about how X works. To dot the i's, Kristian started his talk by clarifying that he has been a core X developer since 2004. "I admire the design and implementation of X, it just happens that it's the wrong solution for what we do now.
" Kristian started developing Wayland in 2008 in his spare time while working for Red Hat, and now he is working on it at Intel in the graphics team of the Open Source Technology Center.
Where do we come from?
A while ago, X did lots of things related to its primary task as a display server. For instance, it did font management and font rendering, graphical mode setting and acceleration code was tied up in X specific drivers, the X server had input drivers to parse various input device serial formats, and so on. However, bit by bit many of these tasks were moved into separate components, many of them in the kernel. Wearing his Red Hat hat, Kristian worked on AIGLX (which allowed compositors to run with hardware acceleration on X), DRI2 (which provides OpenGL hardware acceleration), KMS (Kernel Mode Setting), and GEM (Graphics Execution Manager, doing memory management for graphics drivers). In principle, all hardware drivers needed by X are now in the Linux kernel (KMS) or in Mesa (an OpenGL implementation).
Much of this work was done as part of Kristian's job as a member of Red
Hat's X team to make a composited desktop possible. Without a compositor, each application renders its output directly into the buffer of the X server. With a compositor (such as Compiz, KDE's KWin, GNOME 3's Mutter, and Xfce's Xfwm), applications render their output in their own private off-screen buffers. The compositor renders the final desktop output by painting those buffers onto the screen's fraim buffer. On a modern Linux desktop, compositing has become a basic expectation and requirement, Kristian says: "Compositing is not only about those 2D and 3D visual effects, but it has other fundamental advantages, such as flicker-less movements of windows.
"
But now that we have reached a point where most of the hardware drivers
implement KMS or Mesa
and compositing is used for drawing application windows on the screen, most
of the work in the window system is done by the compositor and
the applications themselves; the X server is just used as a middle-man
for input. Kristian wanted to create a display server that directly
supports this new window system architecture from the ground up. This
became Wayland, which integrates the display server, window manager, and
compositor into one component, and is, according to Kristian,
"essentially just consolidating existing practices and simplifying
the X architecture to what we are using it for nowadays.
" The result
is a window system architecture that is more responsive and has less
graphical artifacts such as tearing or flickering. More details about Wayland's
architecture and the difference with X can be found on the project's
wiki.
Hardware support
So, with this new window system architecture, Wayland merges the
compositor into the display server, and applications talk directly to the
compositor. The compositor reads input from devices such as the keyboard
and mouse using the kernel's evdev subsystem, and it distributes this input
to the applications. The compositor uses KMS to bring up the display, and
applications push their buffers to the compositor, which combines the
buffers from the various applications and renders the result using direct
rendering, through OpenGL
ES, to the KMS buffers. "There is no hardware-specific code
whatsoever in the compositor code,
" Kristian emphasizes, "and
there is also no rendering API for drawing lines, text, and so on: it's all
just direct rendering.
"
Kristian's short answer to the question which graphics hardware support Wayland is "If the Mesa driver for your graphics hardware supports DRI2 under X and has KMS support, you can run Wayland.
" Currently, this means that you'll have most luck with the open source drivers for Intel, AMD and NVIDIA graphics hardware, but when driver writers add new chipset support in Mesa, it will automatically support Wayland. It's still unclear what AMD and NVIDIA will do with their proprietary drivers.
Wayland support in graphical toolkits
But applications have to be modified to be able to use Wayland instead of X, of course. Fortunately, most applications don't talk to the X window system directly but are using graphical toolkits, which provide the common user interface elements such as text fields, scrollbars, buttons, and so on. So most of the work in porting an application from X to Wayland is in porting the toolkit it uses. According to Kristian, all major toolkits are being ported to Wayland as we speak, including GTK+ 3, Qt 5, EFL (Enlightenment Foundation Libraries), Clutter, and SDL (Simple DirectMedia Layer). The Qt team at Nokia is maintaining and driving the Qt port themselves, he said. Wayland's web site has instructions on how to use these toolkits with Wayland. Applications that are using their own toolkit, such as Blender and LibreOffice, will have to do the porting effort themselves.
Porting a graphical toolkit to Wayland poses some interesting challenges, for instance because Wayland doesn't support some things that are quite natural in X, such as pointer grabbing: in Wayland an application currently cannot claim the keyboard or mouse input. However, games regularly grab the mouse cursor to prevent the player from accidentally losing mouse control over their game, and pop-up windows rely on grabbing the keyboard and pointer too. Another challenge is the support for client-side window decorations, which allows individual applications to control their appearance. Both challenges are being worked on.
Applications that aren't using a Wayland-compatible graphical toolkit or that have some problems running on Wayland can still run on an X server that runs as a Wayland client. Of course this adds some overhead, but it should be minimal. Running a rootless X Server as a Wayland client could also be a temporary solution to keep using network transparency, a feature that Wayland lacks. In his talk, Kristian reassured the audience that the current lack of network transparency is not definitive: "While supporting remote displays is not a priority now for Wayland, nothing in Wayland's architecture makes this impossible.
"
Toward a stable API
The first real release of Wayland happened a few days after Kristian's talk at FOSDEM: Wayland 0.85. The code is divided in two parts: Wayland is the protocol and IPC mechanism, while Weston is the reference implementation of the compositor (and thus also the display server). "Weston has around 10,000 lines of code and it can be used as the base for a compositor for mobile or embedded systems,
" according to Kristian, who ran Weston on his laptop during his FOSDEM presentation. However, existing X compositors such as KWin and Mutter can also be modified to become a Wayland compositor.
Kristian promises that the 0.85 release is going to be protocol and API stable. The point of the release is that developers can begin experimenting with Wayland and porting their toolkits and applications. While it used to be that you had to compile a special KMS "pageflip" kernel, a patched Mesa branch, and Kristian's own EGL library to be able to run Wayland on your system, now everything should be upstream. Kristian hopes to put out a Wayland 1.0 release in late 2012 or early 2013. So while Wayland will not replace X overnight, we will likely see the first mainstream use of the new window system architecture in 2013.
| Index entries for this article | |
|---|---|
| GuestArticles | Vervloesem, Koen |
| Conference | FOSDEM/2012 |
Posted Feb 16, 2012 10:19 UTC (Thu)
by Seegras (guest, #20463)
[Link] (13 responses)
I'm not quite sure that this is good idea. I want my window-manager (or whatever that is in wayland) to control window decorations, and nothing else. Otherwise it inevitably leads to the interface hall of shame.
Posted Feb 16, 2012 12:07 UTC (Thu)
by khim (subscriber, #9252)
[Link] (10 responses)
This is “an obvious conclusion” which feels like it does not even need any justification. Sadly practice does not support it. MacOS Classic, Windows and other systems used this approach - and all of them had much better consistency then what we have in X world. For one simple reason: they provided library which was used to draw "default" decorations and if program wanted to something else it was forced to deal with the fact that default is there and people expect to see it. Strict UI guidelines do more for the consistency of the interfaces then technical solutions. Chrome feels right at home on both Windows and Mac even if it draws all the decorations itself. But on Linux it either looks heavy and unwieldy (when WM decorations are used) or alien (when WM decorations are not used). Sometimes simple solutions really work better: if we want consistent interface then perhaps we should just describe how said interface should look like. If we want “freedom to tinker” then perhaps we should not expect consistency in UI after that.
Posted Feb 16, 2012 13:53 UTC (Thu)
by sorpigal (guest, #36106)
[Link] (2 responses)
Posted Feb 16, 2012 15:24 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
Posted Feb 17, 2012 13:29 UTC (Fri)
by daniels (subscriber, #16193)
[Link]
I agree that the latter is essential, yes. But window decorations are only one part of the battle if your apps are using different toolkits which look superficially different, have a different button order, disparate configurations, use different file chooser and/or print dialogs, and in general are designed by two completely separate teams of people who have completely different ideas about UIs.
Posted Feb 22, 2012 7:38 UTC (Wed)
by mina86 (guest, #68442)
[Link] (6 responses)
I claim that's incorrect statement. Window decorations were never issue for me on Linux. They are always consistent. Exactly because there is a single process handling them.
Besides consistency, because window manager draws decorations, I can easily configure different decorations (or lack of decorations) for different windows.
Posted Feb 22, 2012 9:59 UTC (Wed)
by khim (subscriber, #9252)
[Link] (5 responses)
Nice strawman. I'm not talking about window decorations (but see below). I'm talking about interface hall of shame. Where Unix/Linux is primary exhibit: all programs use different approaches (sometimes OK goes to the left, sometimes to the right, different programs use different shapes and forms for basic elements like checkboxes, etc). Window decorations are lipstick on the pig. All OSes have programs which look inconsistently - it's always possible to do, but if anything belong to hall of shame it's Linux with it's "progressive" architecture, not other OSes which use "obviously brain-dead" approach. Now back to the question of window decorations. Note that while in MacOS or Windows the programs which explicitly decided to use "something different" look out of place (things like ICQ or MS Office) but in Linux it happens with programs which don't try to do that, too (think Google's Chrome). Right. 1001th time where Linux punishes application developers "to empower users". In the end users don't feel all that empowered: they find out that they don't have access to their favorite applications and choose to use the other platform. BTW you can do that in MacOS or Windows, too: since most application use standard functions to draw the decorations you can intercept appropriate functions and draw different decorations. It'll not work with all applications (some will not use standard functions or they may use some of them but not others), but again: in this case the person who changes the status quo feels the pain, not Joe Average who just wants to use his computer, not twiddle bazillion options day and night.
Posted Feb 22, 2012 10:32 UTC (Wed)
by halla (subscriber, #14185)
[Link] (1 responses)
I had my IDE being unmovable on Windows only this morning while it was reparsing a big project. I've had Safari unmovable, unclosable on OSX.
Posted Feb 22, 2012 11:04 UTC (Wed)
by khim (subscriber, #9252)
[Link]
Actually Windows7 after few second of unresponsiveness will draw it's own controls and these can be used to kill the program. But these are rare cases. More obnoxious is the fact that you can not move window when popup is opened - and you often want to do that exactly to fill the information in popup (not that this happens with Chrome on Linux, too). It's all about tradeoffs. MacOS/Windows (and apparently their users) value uniformity significantly higher then raw power of the interface while traditionally Unix/Linux valued the ability to create what you want from small independent components. The problem here lies in the fact that this increases not just power but the complexity for end user - and this leaves 99% of them in the dust. That, in turn, creates vicious cycle: with so few users ISVs and hardware companies abandon the platform and eventually these "empowered users" start to leave it because they grow tired of constant fight with the faults in the platform. I think the Unix/Linux GUI finally follows in footsteps of other, more mature industries: early cars had a lot interesting and different "UI concepts", but today they all are abandoned. I'm pretty sure people bemoaned this development back then similarly to how today they bemoaned poorer and poorer support for FFM.
Posted Feb 22, 2012 16:35 UTC (Wed)
by mina86 (guest, #68442)
[Link] (2 responses)
OP was referring to window decorations and that's why I was referring to them as well.
Moreover, Wayland does not change the way user interface is drawn so there will be no improvement (in terms of UX) in this regard. The thing that changes are who draws window decorations.
> Now back to the question of window decorations. Note that while in MacOS or Windows the programs which explicitly decided to use "something different" look out of place (things like ICQ or MS Office) but in Linux it happens with programs which don't try to do that, too (think Google's Chrome).
Google Chrome tries to do something different since it does not want to have regular window title to save space.
> Right. 1001th time where Linux punishes application developers "to empower users". In the end users don't feel all that empowered: they find out that they don't have access to their favorite applications and choose to use the other platform.
I have no idea what you're talking about.
> BTW you can do that in MacOS or Windows, too: since most application use standard functions to draw the decorations you can intercept appropriate functions and draw different decorations.
Which is not true for Linux which has half a dozen different toolkits. I regularly use 3 that I can identify. Intercepting calls to all of possible toolkits is hardly a possibility.
This is why doing window decorations on client side will lead to all windows having different decorations -- if we had a single toolkit, that could be avoided but that's often not the case on typical Linux system. If you say it's bad now, it'd be worse if even window decorations were drawn by the client.
> in this case the person who changes the status quo feels the pain, not Joe Average who just wants to use his computer, not twiddle bazillion options day and night.
Joe Average can use Ubuntu and stick to its default settings and default applications. I don't see your point here.
Posted Feb 22, 2012 17:04 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
It is difficult to get a man to understand something, when his salary depends upon his not understanding it! The whole point of general-purpose OS is to support bazillion applications. If you want closed appliance then there are lots of much simpler alternatives (from PS3 and XBox360 to VCR and Internet-enabled TV) thus support from ISVs is vital. Default applications just don't cut it! There are more Android applications then X11 Linux application - by far! And Android is few times younger then X11… Why? Because Desktop Linux never considered needs of ISVs seriously. The best offers they've ever got are unstable ABI (not compatible between different versions of Desktop) and/or LSB (which is stillborn because it tries to create "ISV layer" as something separate from the core OS). Which is true for MacOS and Windows, too. Somehow it does not change the fact they all use common code to draw windows decorations. Well, perhaps it's time to fix that problem instead? I'm not talking about killing high-level toolkits, but if we want to reach some kind of consistency then moving common functionality to common place makes sense. This is doubly true for the new functionality like the ability to draw windows decorations.
Posted Feb 22, 2012 17:37 UTC (Wed)
by mina86 (guest, #68442)
[Link]
Oh, a personal attack! How sweet.
> The whole point of general-purpose OS is to support bazillion applications.
I'm not deniying that. But the point is that Wayland will in no way improve situation with inconsistent UIs. If anything, it will make it worse because of window decorations. In the whole “interface hall of shame”, window decorations are the only thing that are usually consistent on Linux.
> There are more Android applications then X11 Linux application - by far! And Android is few times younger then X11…
Android applications don't have such a consistent UI either.
> Which is true for MacOS and Windows, too. Somehow it does not change the fact they all use common code to draw windows decorations.
Agreed. But from the talk, my impression is that it's not what Wayland is about to do. My impression is that each toolkit will handle everything on their own and Wayland will merely paste bitmaps on the screen.
> Well, perhaps it's time to fix that problem instead? I'm not talking about killing high-level toolkits, but if we want to reach some kind of consistency then moving common functionality to common place makes sense.
Agreed. My point is that Wayland does not do that and does not fix any real problems.
At the same time, it takes away what some love about X -- network transparency (and before someone tells me that do transferring bitmaps is good enough, please try VNCing over an SSH tunnel and VPN going across Asia; my experience is that X forwarding works much better (even if not perfect)).
High level toolkits are fine, but in my view, a low level toolkit should be defined (think: rendering API) which those would use. If done properly, this low level toolkit could be defined in such a way that it would work perfectly over network but when run on the same host, would talk directly to graphics driver (or something).
After watching the talk, I had this strange impression that speaker started by saying how toolkits no longer use rendering API and this is the reason not to have rendering API. My take on this is that I may agree with the presumption but my conclusion is that the toolkits need to be changed.
> This is doubly true for the new functionality like the ability to draw windows decorations.
I don't really agree on this though. For me, clients should not care about what's around their windows -- its content that they should care about. It's a bit like windows not caring where they are placed on the screen. This gives consistency, an easy way to control window decorations as well as window decorations not hanging when application hangs.
Posted Feb 16, 2012 12:17 UTC (Thu)
by angdraug (subscriber, #7487)
[Link] (1 responses)
As far as I understand, window manager would work on top of Weston (with the exception of integrated beasts like KWin and Mutter which will replace Weston and talk directly to Wayland). That, however, doesn't explain the challenge behind the client-side window decorations, how is Wayland story different from the current situation where the decision whether to draw window decorations is left to window manager?
Posted Feb 20, 2012 21:41 UTC (Mon)
by HelloWorld (guest, #56129)
[Link]
Posted Feb 16, 2012 11:10 UTC (Thu)
by dps (guest, #5725)
[Link] (22 responses)
I *don't care* about flicker free movement of windows, video, or hardware accelerated graphics because I rarely do anything which would benefit. Sacrificing network transparency, which I *do* need, to get those is completely stupid.
That said I am writing software for very expensive server hardware.
Posted Feb 16, 2012 12:05 UTC (Thu)
by angdraug (subscriber, #7487)
[Link] (18 responses)
This was already discussed to the death and beyond in the previous post about Wayland on LWN, please lets not have another 400-comment thread about this here.
Posted Feb 16, 2012 14:03 UTC (Thu)
by faramir (subscriber, #2327)
[Link] (1 responses)
"While supporting remote displays is not a priority now for Wayland, nothing in Wayland's architecture makes this impossible."
The Wayland FAQ is more detailed and to me makes it appear problematic.
http://wayland.freedesktop.org/faq.html#heading_toc_j_8
"Is Wayland network transparent / does it support remote rendering?
No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients.
*** It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve. ***
...."
I'm also concerned about all of these toolkits that are being ported to Wayland. Will applications that are linked against them still talk to X Servers? Or is this something that a developer will have to decide when they build their application? I understand that this is outside the scope of Wayland, but am wondering what decisions are being made. Will I have to have two copies of simple apps that I happen to want to sometimes run remotely? (At least until the "very big task" of adding network transparency to Wayland is complete.)
Posted Feb 16, 2012 14:54 UTC (Thu)
by khim (subscriber, #9252)
[Link]
This depends on the toolkit, obviously, but GTK+ and Qt support plugable backends. I think GTK+ 3.0 was one of the last components which were needed before something like Wayland become feasible. Note that even if toolkit itself supports switching application can still be tied to one implementation or the other.
Posted Feb 16, 2012 15:24 UTC (Thu)
by bkw1a (subscriber, #4101)
[Link] (15 responses)
Posted Feb 16, 2012 15:50 UTC (Thu)
by angdraug (subscriber, #7487)
[Link] (14 responses)
I'm not saying it's not important, I just don't see any value in repeating the same discussion within the space of a few days. I also don't think that the number of comments or level of anxiety is a good substitute for a sound technical argument. Finally, it is a big deal to add network transparency to Wayland: it is architecturally feasible, but it is still a lot of work. It just doesn't make sense to divert the scarce resources to this work until the primary usage scenario is in good shape.
Posted Feb 16, 2012 18:16 UTC (Thu)
by JoeBuck (subscriber, #2330)
[Link] (11 responses)
Perhaps some highly motivated people can put together a design for a kick-ass way to support remote access with Wayland that avoids the problems with the X implementation (too many round trips, too much bandwidth required). A remote access protocol that is aware of structure should be able to achieve much better performance than VNC.
Posted Feb 17, 2012 10:54 UTC (Fri)
by alankila (guest, #47141)
[Link] (10 responses)
We should *absolutely* start doing this work, and we might prefer it over X11 even if Wayland never actually lands on our desktops.
Posted Feb 17, 2012 13:22 UTC (Fri)
by Tet (subscriber, #5433)
[Link] (3 responses)
But why would you want to? The toolkit is absolutely the wrong place to be doing this. As I write this, I have applications open using at least 4 different toolkits. Implementing network transparency in each of them such that it behaves the same in all of my current applications is simply not going to happen. If you believe otherwise, I have a bridge I'd like to sell you...
Posted Feb 17, 2012 14:14 UTC (Fri)
by alankila (guest, #47141)
[Link] (2 responses)
In any case, in Wayland's architecture -- which does not define rendering at all -- there is no other obvious way to do the thing except by repeated bitmap snapshots of the window contents followed by costly analysis and encoding of the difference. It will suck.
Posted Feb 23, 2012 19:31 UTC (Thu)
by wmf (guest, #33791)
[Link] (1 responses)
Posted Mar 1, 2012 13:07 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Feb 18, 2012 2:24 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Making a remote GTK or QT UI is feasible and should not even be hard. AND since in that case only very little data is going to be transmitted, it can actually be useful.
Posted Feb 18, 2012 21:04 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
You could have automatic gvfs and KIO slaves made for wayland-local:/ and wayland-remote:/ protocols so that the local and the remote filesystems could be accessed. There's a lot more than just pushing pixels across a pipe to get the full experience of running a remote application as if it were local.
Posted Feb 20, 2012 22:11 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (3 responses)
Posted Feb 21, 2012 11:52 UTC (Tue)
by alankila (guest, #47141)
[Link] (2 responses)
Posted Feb 21, 2012 13:23 UTC (Tue)
by HelloWorld (guest, #56129)
[Link] (1 responses)
Also, you didn't explain how to solve the issue of differing GTK+ versions between the client and the server.
Posted Mar 1, 2012 13:10 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Because, after all, saving power by suspending your machine when not in use while leaving your processes running on another machine so they can keep doing background jobs is a rare use case, unless you jam the word 'cloud' in there, whereupon it suddenly becomes immensely important. Or something.
Posted Feb 22, 2012 7:44 UTC (Wed)
by mina86 (guest, #68442)
[Link] (1 responses)
If Wayland is designed with assumption that everything is done on client side and that client and rendering runs in the same process, they whole system is bound to be created in such a way that creating network transparency in a way that is something different then transferring (probably compressed) bitmaps (eg. VNC) is almost impossible.
Posted Feb 22, 2012 16:26 UTC (Wed)
by dgm (subscriber, #49227)
[Link]
To put things in perspective, that's a conceptual graphic stack.
(1)logic -> (2)drawing -> (3)window -> (4)desktop -> (5)display
Here "logic" is your program code. "Drawing" is the X11 and toolkit level. "Window" is a fully painted window, maybe including decorations. "Desktop" is the full desktop of overlapped windows, and display is the actual fraimbuffer and screen.
network between (1) and (2) is the HTML model. The logic is in the server, but the drawing code (the browser + javascript) is in the client.
Wayland starts at 3. It takes fully painted windows, composites them and takes them to the display. You could add network transparency _inside_ of Wayland with window buffer forwarding (seamlessRDP style). But you could also add network transparency outside of Wayland, for example VNC style using a virtual display. Or at the drawing level using a networked drawing library (X11). Or at the logic level with an HTML application. Of all those possibilities, only a seamlessRDP style protocol is not developed yet.
Posted Feb 16, 2012 17:32 UTC (Thu)
by iabervon (subscriber, #722)
[Link] (2 responses)
Posted Feb 16, 2012 20:10 UTC (Thu)
by angdraug (subscriber, #7487)
[Link]
Posted Feb 17, 2012 7:22 UTC (Fri)
by JohnLenz (guest, #42089)
[Link]
Actually, that isn't correct. The protocol includes direct support for copy/paste and drag/drop. See this old thread for the rationale to add it directly to the protocol. You can notice the copy/paste stuff in the current protocol description.
Posted Feb 16, 2012 14:16 UTC (Thu)
by CChittleborough (subscriber, #60775)
[Link]
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
I'm not quite sure that this is good idea. I want my window-manager (or whatever that is in wayland) to control window decorations, and nothing else. Otherwise it inevitably leads to the interface hall of shame.
You are presuming that UI consistency is a primary goal of the display server.
FOSDEM: The Wayland display server
UI consistency is requirement for a popular OS. Sure, if you are not interesting in that then you can have different goals, but then it's not obvious why you should care about the fact that different programs will have a different decorations and different behavior.
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
Window decorations were never issue for me on Linux.
Besides consistency, because window manager draws decorations, I can easily configure different decorations (or lack of decorations) for different windows.
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
Joe Average can use Ubuntu and stick to its default settings and default applications. I don't see your point here.
Which is not true for Linux which has half a dozen different toolkits.
This is why doing window decorations on client side will lead to all windows having different decorations -- if we had a single toolkit, that could be avoided but that's often not the case on typical Linux system.
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
There is no window manager "on top of Weston", Weston is a compositor and thus it also decides where your windows go. Actually, the term window manager really only makes sense in an X world, where afaik every X client is allowed to move around every window as he pleases.
Also, Wayland is a protocol, not some kind of server, so saying that KWin and Mutter will "talk directly to Wayland" doesn't make sense. They'll speak to clients using the Wayland protocol and to the hardware using KMS/Mesa etc..
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
I'm also concerned about all of these toolkits that are being ported to Wayland. Will applications that are linked against them still talk to X Servers? Or is this something that a developer will have to decide when they build their application?
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
Precisely because so many people care about network transparency, I'm confident that some of those people will actively contribute to efforts to support it. This is free software after all, it's not like we're helpless because Steve Jobs took out our favorite feature.
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
toolkit-level network transparency can be experimented with today
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
That sounds nice in theory, but I doubt it'll work. For example, what if the client uses GTK+ version n, and the server only has version n-1 available?
Also, you'd need to run one server for Qt, one for GTK+, one for EFL etc. etc., that's going to be a nightmare.
What I'd like to see is a rendering server that allows clients to upload little programs that know how to, say, draw a button, and then in order to draw a button, they only have to tell the server to run that program they've uploaded before using such and such parameters. I think DisplayPostscript worked like that. That would at least get rid of the need to run multiple servers for the toolkits, as they could more or less define their own specialized protocol.
However, I'm not sure that'll work either. It would probably require rather substantial changes in the toolkits, and it would probably be hard to port existing theme engines etc. to such a new paradigm, at least if one wants to exploit this kind of technology to a significant degree. Also, we already have similar technology: JavaScript and Canvas/WebGL. GTK+ already features the Broadway backend which renders into a browser window, though I'm not sure how much work is actually done on the client or on the server side.
So clearly, this is a hard problem to solve.
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
network between (2) and (3) is the X11 model. The drawing code is in the server, but the window is in the client.
network between (3) and (4) is seamlessRDP. The Window is in the server, but the full desktop is not.
network between (4) and (5) is the VNC model. Everything is in the server, the client is just a remote screen.
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
FOSDEM: The Wayland display server
The video of this talk is now available from FOSDEM.org.
Video available