Tweet
Originally posted by shmerl
View Post
-
5. Wayland should be replaced by Arcan. -
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.Originally posted by Britoid View Post
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
-
Wait, did you just criticize X for the first time? I thought you always thought there was nothing wrong with it?Originally posted by Weasel View PostComment
-
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.Originally posted by DanL View Post
If Nvidia really so want it, let them contribute code that deals with their mess.Last edited by shmerl; 15 May 2019, 01:26 PM.Comment
-
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.
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:
Of course, this works correctly under X11 session.Code:Unable to init server: Could not connect: Connection refused # Failed to parse arguments: Cannot open display:
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-...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.
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.
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.
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.Comment
-
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.Originally posted by debianxfce View Post
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
-
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).Originally posted by DanL View PostLast edited by shmerl; 15 May 2019, 04:46 PM.Comment
-
One more thing: xkill obviously doesn't work for Wayland apps and there is no equivalent of this tool in GNOME/Wayland.Originally posted by the_scx View PostRe: 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.
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:
Of course, this works correctly under X11 session.Code:Unable to init server: Could not connect: Connection refused # Failed to parse arguments: Cannot open display:
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-...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.
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.
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.
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.
So, as the end user I would like to see a replacement for all these X11-related utilities, like xdotool, xkill, etc.Comment
-
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.Originally posted by shmerl View PostComment
Comment