Wayland
|
Size: 4295
Comment:
|
← Revision 31 as of 2017-10-31 20:24:59 ⇥
Size: 5769
Comment: added paragraph and link to subdirectory about elevated permissions with GUI applications
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ''' *** We are no longer moving to [[Mir]] and now switching back to Gnome-Shell which already has a wayland implementation in it. This section likely needs a lot of review. It was originally written for moving Unity to Wayland *** ''' |
|
| Line 5: | Line 7: |
| See the [[http://wayland.freedesktop.org/|Wayland website]]. | Wayland is a new protocol that enables 3D compositors to be used as primary display servers, instead of running the 3D compositor as an extension under the (2D) X.org display server. |
| Line 7: | Line 9: |
| === What is the official word on Ubuntu moving to Wayland? === | Or, in layman's terms, it assumes you're using a 3D desktop from the start, instead of bolting on 3D capabilities to an 2D framework. |
| Line 9: | Line 11: |
| See Mark Shuttleworth's blog post, [[http://www.markshuttleworth.com/archives/551|Unity on Wayland]]. | See the [[https://wayland.freedesktop.org/|Wayland website]] for more details. |
| Line 21: | Line 23: |
| === Are Wayland package available in the Ubuntu archive? === | === What is the reason for making Wayland? Why does X have to be replaced? === |
| Line 23: | Line 25: |
| No, not yet. For now, you can [[http://wayland.freedesktop.org/building.html|build it manually]]. | These days we only use a fraction of what X was originally designed to do. X11, by definition, is a big protocol of rendering primitives and font management and lots of other stuff. Most of that stuff we don't really need or use in modern desktops. At the same time, with today's 3D-centric desktops, toolkits, and window managers, the compositor is a critically important piece and in the future will likely become a hard requirement, yet in X11 it is limited to being merely an out-of-process extension to the X server. Thus Wayland, from a high-level view, is about making the compositor the central process and the X server the optional add-on you can activate for legacy X applications. |
| Line 31: | Line 37: |
| Graphics drivers such as Intel, Nouveau, and Radeon include both kernel drivers and an X driver. Wayland only needs the kernel drivers. Under the KMS/DRM/GEM architecture, that's where most of the real functionality is, such as modesetting, memory management, and graphics rendering. The remaining bits on the X side of things is used just to interface with the X server and aren't needed by Wayland. | Graphics drivers such as Intel, Nouveau, and Radeon include both kernel drivers and an X driver. With Wayland we only need the kernel drivers. Under the KMS/DRM/GEM architecture, that's where most of the real functionality is, such as modesetting, memory management, and graphics rendering. The remaining bits on the X side of things are used just to interface with the X server and aren't needed by Wayland. |
| Line 35: | Line 41: |
| No, not at this time. fglrx, nvidia, psb, and other closed source drivers are developed externally to X.org and externally to Ubuntu. As far as we know, work to update them to conform to the new KMS/GEM/etc. architecture is not planned (at least, not publically) and would need to be done before they could be used under Wayland. | No, not at this time. fglrx, nvidia, psb, and other closed source drivers are developed externally to X.org and externally to Ubuntu. As far as we know, work to update them to conform to the new KMS/GEM/etc. architecture is not planned (at least, not publicly) and would need to be done before they could be used under Wayland. |
| Line 37: | Line 43: |
---- /!\ '''Edit conflict - other version:''' ---- ---- /!\ '''Edit conflict - your version:''' ---- According to Krisitan closed drivers need 2 things : * A way to set the graphics mode (like kms, but it could also be a standalone library) |
According to Kristian closed drivers need 2 things: * A way to set the graphics mode (like KMS, but it could also be a standalone library) |
| Line 45: | Line 47: |
| psb already is capable of mode setting. I (adamw) don't know if it can share buffers. | |
| Line 46: | Line 49: |
| ---- /!\ '''End of edit conflict''' ---- | |
| Line 51: | Line 53: |
| There are other ways to share graphical sessions and applications across a network. Wayland also permits running an X11 server inside itself, so you also always have the option of just running X11 clients inside Wayland. | There are other ways to share graphical sessions and applications across a network. Wayland also permits running an X11 server inside itself, so you also always have the option of just running X11 clients on top of the server. |
| Line 53: | Line 55: |
| === Will toolkits (Qt, Gtk, etc.) need to be ported to work on Wayland? === | Another possible idea is discussed here: [[http://lists.freedesktop.org/archives/wayland-devel/2010-November/000037.html|NetworkTransparency]]. |
| Line 55: | Line 58: |
| Yes. This is an area of heavy development currently. The toolkits must be ported as one of the pre-requisites to getting existing applications running on Wayland. | === Will toolkits (Qt, GTK+, etc.) need to be ported to work on Wayland? === |
| Line 57: | Line 60: |
| === Will window managers need to be rewritten for Wayland? === Yes. Canonical is investing in making Unity work on Wayland. It is expected that other window managers will be written for Wayland, and perhaps existing WMs will be ported to it in time, as well. |
Yes. This is an area of heavy development currently. The toolkits must be ported as one of the pre-requisites to getting existing applications running on Wayland. [[http://wayland.freedesktop.org/toolkits.html|Much progress has been made on Qt, GTK+, Clutter, SDL, and EFL]]. |
| Line 63: | Line 64: |
| Yes, due to the technical design differences of Wayland compared with X11, changes need to be made to client applications. In some cases, a simple recompilation using Wayland-enabled Gtk/Qt will be enough; in other cases minor changes are needed; in a few cases where extensive X11 functionality is used directly in the app, it will necessitate more extensive porting work. | Yes, due to the technical design differences of the Wayland protocol compared with X11, changes need to be made to client applications. In some cases, a simple recompilation using Wayland-enabled GTK+/Qt will be enough; in other cases minor changes are needed; in a few cases where extensive X11 functionality is used directly in the app, it will necessitate more extensive porting work. === Elevated (sudo -H, gksudo) permissions with GUI application programs on Wayland === Wayland is designed to not allow elevated (sudo -H, gksu ...) permissions with GUI application programs. It is a good idea to do such tasks with command line tools. But there are work-arounds, that are described at the link '''[[/gks]]''' |
| Line 67: | Line 72: |
| This is a wiki, so add your questions above this one. | You might also like this FAQ: https://groups.google.com/forum/?fromgroups#!forum/wayland-display-server In case you still have questions after that, this is a wiki, so add your questions above this one. |
*** We are no longer moving to Mir and now switching back to Gnome-Shell which already has a wayland implementation in it. This section likely needs a lot of review. It was originally written for moving Unity to Wayland ***
Wayland and Ubuntu
What is Wayland?
Wayland is a new protocol that enables 3D compositors to be used as primary display servers, instead of running the 3D compositor as an extension under the (2D) X.org display server.
Or, in layman's terms, it assumes you're using a 3D desktop from the start, instead of bolting on 3D capabilities to an 2D framework.
See the Wayland website for more details.
Is Ubuntu dropping X?
No, X will be retained for backwards compatibility. It will be run inside the Wayland/Unity instance when needed.
When will Wayland become the default on Ubuntu?
This has not been decided. This decision will be made at a future Ubuntu Developer Summit (UDS).
It's possible we'll roll it out for some limited scope initially, since it may take time before it's adequately supported across a broad enough range of hardware.
What is the reason for making Wayland? Why does X have to be replaced?
These days we only use a fraction of what X was originally designed to do. X11, by definition, is a big protocol of rendering primitives and font management and lots of other stuff. Most of that stuff we don't really need or use in modern desktops.
At the same time, with today's 3D-centric desktops, toolkits, and window managers, the compositor is a critically important piece and in the future will likely become a hard requirement, yet in X11 it is limited to being merely an out-of-process extension to the X server.
Thus Wayland, from a high-level view, is about making the compositor the central process and the X server the optional add-on you can activate for legacy X applications.
Will video drivers need to be rewritten for Wayland?
No. Most of the open source drivers have been undergoing rewrites in recent years to support KMS, GEM, and other modern graphics technologies which move more of the graphical functionality into the Linux kernel. Wayland leverages (and requires) these technologies; indeed the whole reason Wayland can exist is because of these changes. But those changes were underway for X in general. In the future Wayland and X will both be using the same graphics drivers.
What about the graphics drivers still in X?
Graphics drivers such as Intel, Nouveau, and Radeon include both kernel drivers and an X driver. With Wayland we only need the kernel drivers. Under the KMS/DRM/GEM architecture, that's where most of the real functionality is, such as modesetting, memory management, and graphics rendering. The remaining bits on the X side of things are used just to interface with the X server and aren't needed by Wayland.
Can Wayland be used with the closed source proprietary graphics drivers?
No, not at this time. fglrx, nvidia, psb, and other closed source drivers are developed externally to X.org and externally to Ubuntu. As far as we know, work to update them to conform to the new KMS/GEM/etc. architecture is not planned (at least, not publicly) and would need to be done before they could be used under Wayland.
According to Kristian closed drivers need 2 things:
- A way to set the graphics mode (like KMS, but it could also be a standalone library)
- A way to share video memory buffers (for example an EGLImage) between processes
psb already is capable of mode setting. I (adamw) don't know if it can share buffers.
What about network transparency?
The X11 protocol was designed around running graphical apps across the network. While some people use this feature, it's far from common. Wayland drops this requirement as a way to greatly simplify its architecture.
There are other ways to share graphical sessions and applications across a network. Wayland also permits running an X11 server inside itself, so you also always have the option of just running X11 clients on top of the server.
Another possible idea is discussed here: NetworkTransparency.
Will toolkits (Qt, GTK+, etc.) need to be ported to work on Wayland?
Yes. This is an area of heavy development currently. The toolkits must be ported as one of the pre-requisites to getting existing applications running on Wayland. Much progress has been made on Qt, GTK+, Clutter, SDL, and EFL.
Will applications need to be rewritten or modified to work on Wayland?
Yes, due to the technical design differences of the Wayland protocol compared with X11, changes need to be made to client applications. In some cases, a simple recompilation using Wayland-enabled GTK+/Qt will be enough; in other cases minor changes are needed; in a few cases where extensive X11 functionality is used directly in the app, it will necessitate more extensive porting work.
Elevated (sudo -H, gksudo) permissions with GUI application programs on Wayland
Wayland is designed to not allow elevated (sudo -H, gksu ...) permissions with GUI application programs. It is a good idea to do such tasks with command line tools. But there are work-arounds, that are described at the link /gks
I have more questions not answered here
You might also like this FAQ: https://groups.google.com/forum/?fromgroups#!forum/wayland-display-server
In case you still have questions after that, this is a wiki, so add your questions above this one.
Wayland (last edited 2017-10-31 20:24:59 by localhost)