Announcement

Collapse
No announcement yet.

Prolific Red Hat Developer Starts Up "Wayland Itches" Project

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

  • #51
    Originally posted by the_scx View Post
    Re: Wayland Itches

    1. Screen recording
    Screen recording is still a problem on Wayland. Although we finally have a screen capture API for Mutter and actual program that support Wayland display server on GNOME session (Green Recorder), users want to use their favorite tool for recording desktop/games.
    https://bugzilla.gnome.org/show_bug.cgi?id=768978
    https://github.com/foss-project/gree...ca96a853#about

    Unfortunately, OBS Studio is still working on Wayland support.
    https://obsproject.com/mantis/view.php?id=719
    There are experimental zero-copy screen capture on Linux, which also works on Wayland, because it operates kind of below it. To be honest, in my opinion it shows that all this security-related hysteria is pointless, since this "protection" can be bypassed one way or anther. In fact, it only causes problems with various applications that worked well under X11 but are half-working or not-working under Wayland.
    https://obsproject.com/forum/threads...-linux.101262/

    There is one more interesting example. Peek uses XWayland to bypass Wayland's restrictions.
    https://github.com/phw/peek/tree/6e7...ayland-support

    We should obviously ask ourselves if it really should looks like that. In my opinion, something is definitely wrong here.

    2. Screen capturing
    This is a similar issue. We already have APIs for that as well as working tools (e.g. GNOME Screenshot). Unfortunately, each Wayland compositor (Weston, Mutter, KWin, Sway) have to implement it on its own. For the years it was kind of mess, because there was separate API for each solution, and the Portal API for this (org.freedesktop.portal.Screenshot) is a relatively new thing.
    https://bugs.freedesktop.org/show_bug.cgi?id=98894
    https://gitlab.freedesktop.org/wayla...land/issues/32
    https://gitlab.gnome.org/GNOME/gnome...Screenshot.xml
    https://blog.martin-graesslin.com/bl...to-screenshot/
    The real problem in here is that we have some applications with screenshot functionality, which is broken under Wayland session. A good example here would be gImageReader (with both Gtk+3 and Qt5 front-ends). This is probably the best open source OCR GUI app for Linux (it is actually front-end for Tesseract) and it is kind of sad that it isn't fully functional under Wayland.

    3. Color picking
    For a long time, there was no API for color picking in Wayland at all. The screen capture API is simple not enough. Today, we have some kind of working solution for Mutter and KWin.
    https://bugzilla.gnome.org/show_bug.cgi?id=789756
    https://gitlab.gnome.org/GNOME/gtk/b...kcolorpicker.c
    https://bugzilla.gnome.org/show_bug.cgi?id=780375#c17
    https://phabricator.kde.org/D3481

    Unfortunately, there is not a single tool that would benefit from it. Both Gpick and Gcolor3 are totally broken under Wayland, even if XWayland is in use. What is worse, GtkColorPicker (that can handle both Mutter and KWin APIs) won't be available in stable release until GTK4 launches, so don't expect a working solution in the near future.
    https://gitlab.gnome.org/World/gcolor3/issues/38
    https://gitlab.gnome.org/GNOME/gtk/b...icker.c#L56-60

    4. Remote desktop
    Remote desktop for Wayland is still in work-in-progress state.
    http://jgrulich.cz/2018/07/02/screen...land-sessions/
    https://wiki.gnome.org/Projects/Mutt...Remote_Desktop
    https://fedoraproject.org/wiki/Chang...dRemoteDesktop

    Unfortunately, there is no NX/X2Go solution on the horizon.

    5. Terminal
    Can't launch graphical apps from terminal when logged as another user.

    Steps to reproduce:
    a. Run GNOME Terminal
    b. Use su to login as another user.
    c. Try to run any graphical app, e.g. GNOME Terminal.

    Result:
    Code:
    Unable to init server: Could not connect: Connection refused
    # Failed to parse arguments: Cannot open display:
    Of course, this works correctly under X11 session.

    6. Disable/enable touchpad
    For obvious reason, xinput program doesn't work properly under Wayland. This applies as well to any utility that uses it under the hood. Unfortunately, this may be a problem for applets that are used to disable/enable touchpad, e.g. Touchpad Indicator and its clones. In GNOME, all of these utils should use gsettings instead.
    https://github.com/atareao/Touchpad-Indicator
    https://github.com/atareao/Touchpad-...ad.py#L86-L138

    7. Automated UI testing
    Automated UI testing is not always so easy in Linux, but they may be a very useful. There is no uniform solution here. For GTK+ and Qt apps, the dogtail may be used. Unfortunately, it still doesn't support Wayland. Maybe it will be available in the next release.
    https://gitlab.com/dogtail/dogtail

    For simple tasks however, a lot of people prefers to use xdotool instead. It may be primitive, but it works. Unfortunately, not under Wayland.

    8. XDG-Decoration
    The XDG-Decoration protocol lets programs to use server-side decorations (SSD). It provides a standardized way for Wayland compositors to draw window decorations (window border with standard buttons). Currently, it is supported by both KWin and Sway, but not by Mutter. The GNOME devs however refuse to implement it.
    https://gitlab.gnome.org/GNOME/mutter/issues/217
    This is extremely important in gamedev, because it is the only sane way for libraries like SDL2, GLFW, Allegro and the like to handle window decorations. In games, all you need is just a single window with one big OpenGL/Vulkan context. And this works perfectly in fullscreen mode. In windowed mode, however, the user would expect to see a window decorations. Almost every modern platform (Windows, macOS, Linux/FreeBSD on X11) can provide it for free, but not Wayland, at least not in GNOME session.

    This is some kind of problem on Flathub, because we don't know if we should allow certain games to run on native Wayland or stick with X11 to gain the best user experience.

    9. Wayland security
    Flatpak/Flathub maintainers claims that they can provide truly sandboxed apps, but only when using Wayland, because "X11 is inherently insecure". This would be particularly applicable to games that may be used in unchanged form for years. However, the whole Wayland security thing isn't entirely true. Currently, if you want to access the joystick or gamepad under Flatpak, you need to give access to all devices, including e.g. webcam. As far as I know, the solution for this is still ongoing.
    https://github.com/flatpak/xdg-deskt...ment-426298840

    10. WINE
    Code:
    It is very unlikely that Wine is going to support Wayland in the same way as X. I worked on a Wayland driver for Wine some time ago, but discontinued the idea because Wayland lacks many features that are expected by Windows programs.
    
    One problem is for example that a program can not specify the location of a newly created window. This doesn't sound very problematic at first, until you notice that drop-down / popup menus are also just normal windows on Windows. The solution that Wayland provides for this is not really compatible with the Win32 API. I therefore talked with some Wayland developers and there is no chance of fixing this in the future. It is part of their concept that applications should not have control over the window position and similar settings.
    
    IMHO, it is not a good solution to remove features just because an application could abuse them. I can understand this for security relevant features, like grabbing the keyboard and mouse input from another window, but not for things like specifying the window position. It is like removing the possibility to delete files, because the user could accidentally click on the wrong file, instead of implementing a recycle bin. Adding a way to recover from situations in which programs misbehave would be a better solution, but this is just my opinion.
    https://bugs.winehq.org/show_bug.cgi?id=42284#c1

    11. Color management, HDR, etc.
    As far as I know, Wayland still lacks support for proper color management and many other things, that are already available in X11 for years or even decades. One of these thing may be DeepColor Visual extension for HDR on X.Org Server. This for example will require the wayland compositor to be FP16-aware.
    https://www.x.org/wiki/Events/XDC201...c-2016-hdr.pdf
    https://wiki.gnome.org/Initiatives/HDR

    12. Freesync & G-Sync
    Similar to above. I haven't seen any FreeSync/Adaptive-Sync or G-Sync work on the Wayland front.

    13. Support for MATE and Xfce
    This is not Wayland issue per se. It just would be nice if these DEs would support Wayland. Unfortunately, this is very unlikely to be done in the near future.
    And as you can see, providing a good Wayland compositor is extremely difficult. We definitely don't want another one from scratch, and then implement all these extensions (screen capturing, color picking, remote desktop, XDG decoration, color management, HDR, etc.) for years.
    The MATE developers are considering Mir-over-Wayland solution.
    https://www.youtube.com/watch?v=qaezzAGWhOw
    It isn't a bad idea. However, in my opinion it would be better to make Mutter works flawlessly outside GNOME. Unfortunately, I don't believe that it is possible without forcing GNOME devs to collaborate with others.
    Please keep in mind that we talking about literally two developers (Martin Wimpress from MATE and William Wold from Canonical). Most of MATE devs are already exhausted, and Xfce devs (which currently aren't even involved) are still finishing the Xfce port on gtk+3, so as you can see, they are several years behind MATE.
    https://github.com/mate-desktop/marc...ment-416704305
    https://wiki.xfce.org/releng/4.14/roadmap



    Not all, but a lot of these things are fixable. However, someone has to do this and the vendor developers are not always interested in supporting Wayland by themselves. After all, I believe that a nice Pull Requests will do a job.
    Please keep in mind that just providing an API is not solution for the end users. They expect, that apps they are using will works flawlessly. Unfortunately, currently we have to many broken things under Wayland to say that it works well.
    One more thing: xkill obviously doesn't work for Wayland apps and there is no equivalent of this tool in GNOME/Wayland.

    So, as the end user I would like to see a replacement for all these X11-related utilities, like xdotool, xkill, etc.

    Comment


    • #52
      Originally posted by shmerl View Post
      That's nonsense, they are ignoring Linux because they don't follow kernel development requirements. It only creates problems.
      No, you are nonsensical because you are redefining the word 'ignore' and considering out of tree kernel modules as "ignoring" the kernel. Words have meanings. Use them properly and follow the requirements. Otherwise, it only creates problems.

      Comment


      • #53
        Originally posted by DanL View Post

        No, you are nonsensical because you are redefining the word 'ignore' and considering out of tree kernel modules as "ignoring" the kernel. Words have meanings. Use them properly and follow the requirements. Otherwise, it only creates problems.
        Not interested in demagoguery and defense of Nvidia's mess with claims of Linux support. Claims don't make them support Linux properly. Come back to this topic with your claims when they'll upstream their driver.

        Comment


        • #54
          Originally posted by debianxfce View Post
          Wayland was never intended as a replacement for X.
          That's the article writer's own opinion, which is wrong.

          The developer said in the blog linked by the very fucking article:

          "They got the headline wrong, though, it's not a new X server, it's a tiny display server + compositing manager."

          it's not a new X server != never intended as a replacement for X

          it's not a new X server = this is a display server using a different protocol

          Comment


          • #55
            Originally posted by shmerl View Post
            Claims don't make them support Linux properly. Come back to this topic with your claims when they'll upstream their driver.
            I never claimed that. Come back to this topic when you learn how to read and write properly.

            Comment


            • #56
              Originally posted by DoMiNeLa10 View Post

              As much as I love X, networking should not be a part of your windowing system, and solutions like VNC are the right way to go.
              What stupid "by fiat" decree! As much as I like webpages, networking shouldn't be a part of your solution: VNC and Word are the right way to view documents.

              Comment


              • #57
                Originally posted by shmerl View Post

                You can, because Nvidia ignores Linux. It's not the job of compositor developers to clean up the mess that Nvidia created. I have no respect for Nvidia and their practices, but if you are buying their hardware with broken drivers - do it at your own risk. That's my point. Developers should not support that in Wayland case.
                Nvidia developers have contributed EGLStreams backends for both Mutter and KWin. In what way do they ignore Linux?

                Comment


                • #58
                  Originally posted by xfcemint View Post
                  This is ridiculous. It is called process isolation, and it is a highly desired feature.

                  No, you can't trust your own processes. Because your 'own' process is actually a closed source game or a 3D renderer, and you have no contol over the source code. Or it might be a trojan.

                  An OS which can run untrusted processes with no security issues is a great benefit for the consumers.
                  If you can't trust a specific process then run it as another user. It's basic unix 101.

                  Originally posted by xfcemint View Post
                  If process isolation is not an issue, then perhaps ZombieLoad is also a non-issue. I mean, ZombieLoad is just about not trusting your own processes. And perhaps computer viruses are a non-issue either because, well, they are just some user processes, and all those should be fully trusted.
                  If that's what ZombieLoad does, yeah, it's a non-issue. But unfortunately it can also read kernel memory or memory from outside of the VM, so no, it's dangerous.

                  Comment


                  • #59
                    Originally posted by the_scx View Post
                    To be honest, in my opinion it shows that all this security-related hysteria is pointless, since this "protection" can be bypassed one way or anther. In fact, it only causes problems with various applications that worked well under X11 but are half-working or not-working under Wayland.
                    Amen, this sums up why Wayland will forever be garbage.

                    Comment


                    • #60
                      Originally posted by Vistaus View Post
                      Wait, did you just criticize X for the first time? I thought you always thought there was nothing wrong with it?
                      I honestly don't remember ever saying X11 is perfect. It sucks in many areas, but it is useable. I just consider Wayland beyond hope because it's literally unuseable lacking essential features. All the pseudo-security in the world isn't going to save it from that.

                      It's like being forced to use Windows 10, which is terrible, but at least it's better than a system (Wayland in this analogy) which has no internet connection at all "for safety".

                      Comment

                      Working...
                      X