Announcement

Collapse
No announcement yet.

Prolific Red Hat Developer Starts Up "Wayland Itches" Project

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

  • #41
    Originally posted by SupposedlyFunny View Post

    I haven't followed the development, but did something improved from Torvalds' public "fuckyou Nvidia"?
    Their driver is no longer terrible?

    Comment


    • #42
      Originally posted by shmerl View Post
      Itches:

      1. Wayland is not limited to Gnome. There should be more coordinated cooperation between compositor developers (kwin, wlroots, mutter etc.).
      2. Freesync support.
      3. First class Vulkan/WSI support instead of usage of EGL and Co.
      4. No Wine support except through XWayland.
      5. Wayland should be replaced by Arcan.

      Comment


      • #43
        Originally posted by Britoid View Post
        If you started removing everything from X that's broken you'd end up with Wayland.
        Actually no, you won't. Wayland has some craptastic design decisions that will never go away because they are part of the design, so it's a hopeless protocol. Like, you know, querying absolute window positions, or integrating with another app's visuals and position. Because of monkeys who value pseudo-security and "privacy", you can't do this on Wayland. It's a lost cause.

        I mean... I understand limiting ability to view windows from processes running as other users, that's fine and X fails big time here. But Crapland has this pseudo-security bullshit mentality that you can't trust your own user's processes, which is pathetic and it will forever suck because of it.

        Comment


        • #44
          Originally posted by Weasel View Post
          Actually no, you won't. Wayland has some craptastic design decisions that will never go away because they are part of the design, so it's a hopeless protocol. Like, you know, querying absolute window positions, or integrating with another app's visuals and position. Because of monkeys who value pseudo-security and "privacy", you can't do this on Wayland. It's a lost cause.

          I mean... I understand limiting ability to view windows from processes running as other users, that's fine and X fails big time here. But Crapland has this pseudo-security bullshit mentality that you can't trust your own user's processes, which is pathetic and it will forever suck because of it.
          Wait, did you just criticize X for the first time? I thought you always thought there was nothing wrong with it?

          Comment


          • #45
            Originally posted by DanL View Post

            Quit exaggerating to the point of ridicule. Nvidia doesn't ignore Linux. They don't do things the way you want, but that's not equivalent to ignoring. Oh, and Nvidia is not alone in creating the whole GBM mess, and they at least contribute to one major compositor: https://www.phoronix.com/scan.php?pa...rged-KWin-5.16

            You may hate Nvidia (and there are some valid reasons to do so), but don't make BS claims about them.
            Not upstreaming their driver means they are ignoring Linux development methodology, and it's causing all the mess in result. And seriously, no one should be cleaning up this mess for them. Until they upstream it, they should be reminded what Linus told them. Sway and Kwin developers have this position and I fully support it.

            If Nvidia really so want it, let them contribute code that deals with their mess.
            Last edited by shmerl; 05-15-2019, 01:26 PM.

            Comment


            • #46
              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
              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.
              Last edited by the_scx; 05-15-2019, 06:31 PM.

              Comment


              • #47
                Originally posted by debianxfce View Post

                Read the history of wayland, it was never planned to replace X. As we see after 10 years, it is lacking features that X solutions have. So wayland and implementations are poorly designed and implemented.
                It was never planed to be a one-to-one replacement of X11, because X11 is flawed to the core. Not saying that Wayland is prefect, but it doesn't need a print protocol for example. X11 has to have functional knowledge of every window made it it's buffer, a buffer that is shared globally. Wayland doesn't repeat that error since the responsibility of the client to draw the in the buffer that is allocated to it and has to explicitly call for a shared buffer if it does need one.

                I get it, some things in X11 can be very well liked but wayland is a rather structural change.... it's not about to compete with a component that has been developed for over 30 years and it honestly doesn't try. This is on top of some really bad ideas that can't be patched out of the protocol because you would be force to brake it, on top of the fact that X11 has been shown to be rather brittle codebase over all.
                If you think that you can outdo the wayland/X11 developers on this, you can try... but Ubuntu tried that, we all have seen what has happened with mir, which was repeating old mistakes.

                Comment


                • #48
                  Originally posted by SupposedlyFunny View Post
                  I haven't followed the development, but did something improve from Torvalds' public "fuck you Nvidia"?
                  Nothing dramatic has changed in Nvidia's driver model, but again, that just means Nvidia doesn't do things the way a lot of kernel devs and users want. It doesn't mean they're "ignoring" Linux as shmerl said.


                  Comment


                  • #49
                    Originally posted by DanL View Post

                    Nothing dramatic has changed in Nvidia's driver model, but again, that just means Nvidia doesn't do things the way a lot of kernel devs and users want. It doesn't mean they're "ignoring" Linux as shmerl said.
                    That's nonsense, they are ignoring Linux because they don't follow kernel development requirements. It only creates problems. All you are saying is "they aren't ignoring, they are just standing on their head and refusing to do what's required". I call it ignore Linux. Kernel development has its rules, and if they don't follow them, they are harming everyone (which is clearly seen in every such problem throughout the whole stack that has to deal with their garbage).
                    Last edited by shmerl; 05-15-2019, 04:46 PM.

                    Comment


                    • #50
                      Originally posted by Weasel View Post
                      But Crapland has this pseudo-security bullshit mentality that you can't trust your own user's processes, which is pathetic and it will forever suck because of it.
                      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 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.

                      Comment

                      Working...
                      X