Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • starshipeleven
    replied
    Originally posted by jpg44 View Post
    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.
    Pretty much all you wrote is wrong, would you mind actually understanding what Wayland is and how it works (and how X also works)?

    Leave a comment:


  • M@yeulC
    replied
    Mmm... Couldn't there be a single GBM-to-EGLstreams maintained by various compositors, or nVidia themselves, as a stopgap while the situation is sorted out? Though obviously leaving something completely broken (and not half-) encourages solving the issue.

    As for @jpg44's post, I'll have to break it down:
    Originally posted by jpg44 View Post
    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.
    Wait, what? Wayland display servers ("compositors") don't integrate graphics drivers. X did that. And it even had printer drivers at some point. Wayland apps talk to the compositor trough a clean API, and compositors to graphics drivers trough DRI, in the same way. And every compositor that implements the Wayland API should be compatible with every Wayland apps, except for a few features defined trough extensions. If unsupported, these features wouldn't even work in the first place.

    Originally posted by jpg44 View Post
    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.
    Wayland is a great move towards sandboxing. X security is broken by design (though nowadays mitigated to some extent). Could you please elaborate on how it increases the HW attack surface? I didn't get it.

    Originally posted by jpg44 View Post
    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.
    Yes, that's right. Although X network transparency has been broken for a while for a few now, as with most apps, it jut transfers images, in a very inefficient way. I can see multiple ways to add "network transparency" to Wayland. Basically you would need to implement a Wayland compositor in the ssh server, then define a protocol for the toolkit to implement network transparency itself, and fallback to a VNC-like solution. Also define a sink for sound at the same time, and a few other interfaces that never worked with X anyway. Hopefully even games would be playable remotely this way. This will probably happen at some point, give it time...

    Originally posted by jpg44 View Post
    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.
    I didn't really get it, as that wouldn't change a lot security-wise (maybe even introduce some issues), and would likely have terrible performance in the end, especially if talking about remote hosts.

    Originally posted by jpg44 View Post
    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.
    Like what's currently done trough the protocol specification, you mean? THere are also various libraries out there like wlroots.

    Originally posted by jpg44 View Post
    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.
    Mmm... I'm not sure if something like this can be done for now? Although it doesn't seem that complicated to me. If anyone has heard of such a thing, please share it.
    Do VNC servers like tigerVNC implement their own DRI to launch wayland compositors (or X servers) in a virtual environment?

    Leave a comment:


  • Flaburgan
    replied
    Originally posted by raveit65 View Post
    Keep in mind that i do this all in my free time.
    Thank you for your work.

    Leave a comment:


  • grok
    replied
    Originally posted by andre30correia View Post

    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
    Wayland had the promise of less cruft, more straightforward and then users complained of issues like mouse lag.

    I suppose that text scrolling fast by the terminal because you use something as simple as cat, ls -R or dmesg means tens of millions pixels sent through the system (Windows 10 does as much, you can enter "dir \ /s" and watch GPU usage shoot up in the task manager)
    Nonetheless, Gnome getting its game together is encouraging, and the stack improves over the year. Stuff like Ubuntu LTS defaults to X or is X only (Mint) so sometimes you don't need to do anything to be unaffected by issues.

    MATE and Xfce are great in that you can disable the compositor as well if you don't even care about supposed tearing issues, KDE as well but I've never used it. I would like to see how these desktops work on 144Hz LCD monitor on X11 with compositor disabled.

    I'm fairly confident that Wayland can be good enough (web browsers fucked up everything anyway, you need SSE2 and 1 gig of RAM to watch cat videos) and if it's ready by the time Windows 7 is dead, that's good.
    In the end I don't care very much. At worst, Wayland will be useless to me but I'll use it because it is supposedly more secure.

    Leave a comment:


  • raveit65
    replied
    Originally posted by the_scx View Post
    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.
    Honestly, i don't have any time or motivation any more to update epel7 repo for a non-free distro (rhel7) .
    I am using fedora and maintaining a whole desktop for one distro is enough.
    Maintainer is wanted for epel7

    Personal, i am thinking that the traditional rhel7 user don't like hard upgrades from gtk2 to gtk3 in a release cycle.
    And i don't like work on bug reports of possible migration issue.
    Keep in mind that i do this all in my free time.

    Leave a comment:


  • andre30correia
    replied
    Originally posted by jpg44 View Post
    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

    Leave a comment:


  • finalzone
    replied
    Originally posted by jpg44 View Post
    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.

    Leave a comment:


  • jpg44
    replied
    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.

    Leave a comment:


  • torsionbar28
    replied
    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.

    Leave a comment:


  • the_scx
    replied
    Originally posted by raveit65 View Post
    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.

    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

    Leave a comment:

Working...
X