The MATE Wayland Port Is Moving Along, NVIDIA Mir Support Still Being Tackled

[phoronix]

Phoronix: The MATE Wayland Port Is Moving Along, NVIDIA Mir Support Still Being Tackled

William Wold of Canonical's Mir team shared their latest weekly progress report on this display server supporting the Wayland protocol. While a short report, the two bits shared are quite interesting...

http://www.phoronix.com/scan.php?page=news_item&px=MATE-Wayland-NVIDIA-Mir

[raveit65]

Mate use gtk+3 since a long time, no need to repeat non-open task which are already done by us

[Michael]

Mate use gtk+3 since a long time, no need to repeat non-open task which are already done by us

Whoops thought some MATE apps still relied on GTK2, thanks for clarification.

[the_scx]

MATE, of course, is the GTK2-forked desktop environment.

As far as I know, MATE 1.8+ is Gtk+3-only DE.

The basics of MATE on Wayland are nwo working but popups created by the panel are positioned incorrectly as one of the current outstanding issues. MATE has long wanted a Wayland port.

Typo: :s/nwo/now/

[Michael]

As far as I know, MATE 1.8+ is Gtk+3-only DE.


Typo: :s/nwo/now/

Yep fixed thanks. Typed this article before my coffee was done brewing :/

[the_scx]

Mate use gtk+3 since a long time, no need to repeat non-open task which are already done by us

Since you're here, can you explain why we do not have MATE 1.18+ in EPEL7? If I remember correctly, you had some concerns about GTK+ 3 in EL7. I would understand if we were talking about EL6, but EL7? What's wrong with this library? Currently, it has a almost stable API/ABI ("GTK+ version 3.22 from autumn 2016 shall be the last 3.x release."). I know that GNOME devs changed their minds, but 3.24 does not bring drastic changes.

https://wiki.gnome.org/Projects/GTK+/3.24

Why do we have to deal with the gtk+2/gtk+3 mixed environment instead of having a unified one? What's worse, MATE 1.16 in EPEL7 has bugs that have already been fixed in a newer version and we do not have backports:
- Screen tearing (without TearFree or ForceCompositionPipeline/ForceFullCompositionPipeline enabled in X.Org, which is not always possible): https://github.com/mate-desktop/marco/issues/271 & https://github.com/mate-desktop/marco/issues/313 & https://github.com/mate-desktop/marco/issues/326 & https://github.com/mate-desktop/marco/pull/350
- Rendering issues with the systray icons: https://github.com/mate-desktop/mate-panel/issues/92 & https://github.com/mate-desktop/mate...ment-286708119

[torsionbar28]

Good news, as a Fedora MATE user, I like hearing about the project's progress. The MATE DE is very mature and stable at this point, no longer relying on any legacy code at all AFAIK. Most distros have a MATE option now, but given how divisive GNOME3 has been, I wonder why more distros haven't defaulted to MATE.

[jpg44]

This is really quite a disappointment as I have been trying to avoid Wayland, I hope they continue the X version. Wayland is really an idea whose time as come and gone, based on what seemed like at one time a good idea, DRI, now taken to an extreme for even programs that do not need what DRI does. The reason is that Wayland rolls up application and driver into one big ugly mess, and rolls up the display server and window manager into one big ugly mess. This is just a recipe for disaster as you are going to end up with incompatible versions of the application API because of all of the different versions of the display server since every window manager basically impelements its own display server.

The security situation is horrible since putting a hardware driver into an app is a questionable idea that really weakens security rather drastically. The apps should be kept seperate from drivers, and X got this right by having a nice socket between the apps and the display drivers for a nice clean separation.

There is more of a move towards isolation of processes and functions into sandboxes to avoid problems like this can cause like a problem with an app exposing the hardware as an attack surface. Wayland greatly increases the hardware attack surface.

Another stupid thing about Wayland is lack of app <-> display server network transparency so you can run your programs on another computer if need be and display them remotely, this is distinct from remote desktop which is an entire desktop session, rather than a single app.

If wayland were to add functionality for app <-> display network transparency, this would allow for network transparency and also fix the security concerns by allow people a more secure option for keeping apps seperate from the drivers. Just have a DRI/Wayland driver that can be loaded into an app that sends all OpenGL commands over the socket to the Wayland server using RPC and render it with hardware DRI drivers on the server side, and that should do the trick. Why not.

As for the risk of incompatable server implementations, could be addressed by encouraging the use of a fully featured library to provide server functions in the Server.

For those who want to stay on X, please also provide a rootless Wayland server , or a DRI/Wayland driver for apps that simply translates the wayland API to xcb commands and sent as an X client to an X server, that can display Wayland apps to an X server, by proxying and translating Wayland application connections to X client connections which can be targeted at an X server, this would help ensure that even if there are Wayland only applications they can be used on X, this also solves the app<->server network transparency issue since individual Wayland apps could be displayed to an X server.

[finalzone]

This is really quite a disappointment as I have been trying to avoid Wayland, I hope they continue the X version. Wayland is really an idea whose time as come and gone, based on what seemed like at one time a good idea,

Wayland is a protocol. It is a toolkit job to properly implement the functions which takes time.

[andre30correia]

This is really quite a disappointment as I have been trying to avoid Wayland, I hope they continue the X version. Wayland is really an idea whose time as come and gone, based on what seemed like at one time a good idea, DRI, now taken to an extreme for even programs that do not need what DRI does. The reason is that Wayland rolls up application and driver into one big ugly mess, and rolls up the display server and window manager into one big ugly mess. This is just a recipe for disaster as you are going to end up with incompatible versions of the application API because of all of the different versions of the display server since every window manager basically impelements its own display server.

The security situation is horrible since putting a hardware driver into an app is a questionable idea that really weakens security rather drastically. The apps should be kept seperate from drivers, and X got this right by having a nice socket between the apps and the display drivers for a nice clean separation.

There is more of a move towards isolation of processes and functions into sandboxes to avoid problems like this can cause like a problem with an app exposing the hardware as an attack surface. Wayland greatly increases the hardware attack surface.

Another stupid thing about Wayland is lack of app <-> display server network transparency so you can run your programs on another computer if need be and display them remotely, this is distinct from remote desktop which is an entire desktop session, rather than a single app.

If wayland were to add functionality for app <-> display network transparency, this would allow for network transparency and also fix the security concerns by allow people a more secure option for keeping apps seperate from the drivers. Just have a DRI/Wayland driver that can be loaded into an app that sends all OpenGL commands over the socket to the Wayland server using RPC and render it with hardware DRI drivers on the server side, and that should do the trick. Why not.

As for the risk of incompatable server implementations, could be addressed by encouraging the use of a fully featured library to provide server functions in the Server.

For those who want to stay on X, please also provide a rootless Wayland server , or a DRI/Wayland driver for apps that simply translates the wayland API to xcb commands and sent as an X client to an X server, that can display Wayland apps to an X server, by proxying and translating Wayland application connections to X client connections which can be targeted at an X server, this would help ensure that even if there are Wayland only applications they can be used on X, this also solves the app<->server network transparency issue since individual Wayland apps could be displayed to an X server.

X will be live for many years. Desktop users need something new than the old X, without wayland or something new Desktop will never survive or grown