Announcement

Collapse
No announcement yet.

Prolific Red Hat Developer Starts Up "Wayland Itches" Project

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

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

    Leave a comment:


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

    Leave a comment:


  • starshipeleven
    replied
    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

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • the_scx
    replied
    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://github.com/foss-project/gree...ca96a853#about

    Unfortunately, OBS Studio is still working on Wayland support.

    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://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://gitlab.gnome.org/GNOME/gtk/b...kcolorpicker.c



    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.
    Created by: bendavis78 Using Archlinux, tried the gcolor3 package from AUR as well as gcolor3-git. When I click the eyedropper button, the mouse...

    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.
    An indicator for the touchpad. Contribute to atareao/Touchpad-Indicator development by creating an account on GitHub.

    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.
    dogtail is a GUI test tool and automation framework written in ​Python. This is an official repository and dogtail home.


    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://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml

    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.


    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


    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.
    Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

    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




    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.

    Leave a comment:


  • shmerl
    replied
    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; 15 May 2019, 04:46 PM.

    Leave a comment:


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


    Leave a comment:


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

    Leave a comment:


  • the_scx
    replied
    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://github.com/foss-project/gree...ca96a853#about

    Unfortunately, OBS Studio is still working on Wayland support.

    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://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://gitlab.gnome.org/GNOME/gtk/b...kcolorpicker.c



    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.
    Created by: bendavis78 Using Archlinux, tried the gcolor3 package from AUR as well as gcolor3-git. When I click the eyedropper button, the mouse...

    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.
    An indicator for the touchpad. Contribute to atareao/Touchpad-Indicator development by creating an account on GitHub.

    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.
    dogtail is a GUI test tool and automation framework written in ​Python. This is an official repository and dogtail home.


    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://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml

    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.


    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


    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.
    Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

    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




    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; 15 May 2019, 06:31 PM.

    Leave a comment:

Working...
X