6 ms·

*Wayland lacks many feature that users have come to rely on. Can you explain what you think these are? In my experience, this is not really the case.

Blikkentrekker 6y ago
An example would be that X11 has protocols to allow the manipulation of currently selected text. In Wayland no such protocol exists as it's entirely agnostic of how clients handle input and render text. The result is that on X11 I have a hotkey that automatically normalizes strings to their unicode normal form, something that is not as easily implementable in Wayland, or at all. A far more basic example is that in order to open new card packs in Hearthstone, to buypass the chore that that involves I can in X11 quite easily send an endless string of space keypreses to an application window without having that window even open or focused. — this is not generally possible in Wayland. Looking it up, a tool ydotool exists to bypass this limitation, which requires root access and directly accesses the input devices to do so.
- cycloptic 6y ago
  In Wayland, you would use the same method to manipulate the selection. Read it out from the server, do your transformation, then generate fake inputs to rewrite the text. Running ydotool requires elevated access with suid because that's a privileged operation -- if you're running X11 without a sandbox that has a similar drawback as it allows all clients to intercept inputs and send fake inputs to any window.
  - stelonix 6y ago
    Fake input under X11 (XTEST) is marked as fake input and any application receiving such events can choose to ignore it. Wine does it, for example.
    - cycloptic 6y ago
      Right, so that would be a place where something like ydotool would come in handy too because fake inputs coming from there wouldn't be coming from the XTEST device.
  - mook 6y ago
    Independent of Wayland or X11, why should a user not be able to take inputs for their own window (as in, the owning process is run as the same user)? Why does it require a tool that needs extra privileges (that presumably works by doing it at a lower level)? That's a genuine question — as in, I'm mostly thinking about Windows and how window message handling works with UAC windows. You can send messages to your own windows all day without needing extra permissions, but not other users' windows. I assume that's what you're referring to with the X11 sandbox; is it reasonable to set up Wayland _without_ such a sandbox?
    - chousuke 6y ago
      The short reason is that if the user can do it, so can any application running as the user. I don't know about you, but I'd prefer my applications not be able to inject and read inputs arbitrarily, though it may be that even stricter sandboxing is needed to make that a reality; Wayland being stricter than X11 is just one step along the way.
      - Blikkentrekker 6y ago
        > though it may be that even stricter sandboxing is needed to make that a reality; Wayland being stricter than X11 is just one step along the way. It is not a situation of “it may be”; it is a situation of “it is”. Right now, it is useless as the security boundary on Unix and any other operating system is fundamentally the user and malicious software that runs as one's user can modify every file and process one owns anyway. I read one comment a while back by a developer that illustrated the fruitlessness of Wayland by saying that it is essentially a lock on a door, that stands in the middle of room, that one can simply walk around, claiming to add security.
        cycloptic 6y ago
        That would be true if someone refused to use any form of sandboxing, however there are multiple sandboxing solutions available that the "door" works in combination with. That is the only real way to make this kind of security work on an ordinary Linux distribution, the approach used by Android where a new user is created for each application is not really feasible. There are also ways to sandbox X11, it's a bit harder to do, but you do have some options on how you'd like to do things.
thayne 6y ago
A few off the top of my head: - Take a screenshot, or share a single window - Screenshot, screenshare, or remote desktop/VNC server without having to use different protocols for different compositors - Use a third party app to control monitor outputs(resolution, orientation, framerate, layout, etc.) generally, for example arandr or xrandr (wlroots does support this) - Be able to do something like KeepassXC's "Autotyping", where it fills in a text field with the password from your password manager. - Have a third party app give a selection of open windows. I think all compositors have some API for this, but they are all different. (for example rofi's window switcher mode). Generally, I think the problem isn't so much things that can't be done in wayland at all, as the way to do them is different across different compositors, so whereas with X it was pretty straightforward to mix and match apps between different DEs and apps that worked on all of them. In wayland there are more apps that only work on gnome, only work on kde, or only work on wlroots based compositors. And some apps that duplicate parts of the code for all three.
- cycloptic 6y ago
  For screenshots or screensharing, please use the xdg-desktop-portal API. That should work correctly in X11, Wayland, and within a sandbox. For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox. For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell. Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.
  - Blikkentrekker 6y ago
    > For screenshots or screensharing, please use the xdg-desktop-portal API. That should work correctly in X11, Wayland, and within a sandbox. This does not allow one to write a screenshot application; this has a protocol that allows Flatpak applications to requæst that the compositor take one and as far as I know it only has support to take on from the entire screen. Most compositors also have the ability to take such screenshots outside of Flatpak; this simply moves it inside of it. The “screenshot issue” with Wayland is not that compositors can't take one; it's the lack of an the a.p.i.'s necessary to write software that can take one. > For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox. I could find nothing on this on the internet. > For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell. And that one “should not do this” yet this is supported and used by many on X11 would be one of the missing features that would lead to Wine developers not being interested in a Wayland port. > Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that. The problem is that these per compositor a.p.i.'s are unstable. GNOME extensions and KWIN scripts work by allowing one to directly hack the internals of the compositor in unstable ways; they are much like kernel modules and they break from version to version.

Blikkentrekker 6y ago

An example would be that X11 has protocols to allow the manipulation of currently selected text. In Wayland no such protocol exists as it's entirely agnostic of how clients handle input and render text. The result is that on X11 I have a hotkey that automatically normalizes strings to their unicode normal form, something that is not as easily implementable in Wayland, or at all. A far more basic example is that in order to open new card packs in Hearthstone, to buypass the chore that that involves I can in X11 quite easily send an endless string of space keypreses to an application window without having that window even open or focused. — this is not generally possible in Wayland. Looking it up, a tool ydotool exists to bypass this limitation, which requires root access and directly accesses the input devices to do so.

cycloptic 6y ago
In Wayland, you would use the same method to manipulate the selection. Read it out from the server, do your transformation, then generate fake inputs to rewrite the text. Running ydotool requires elevated access with suid because that's a privileged operation -- if you're running X11 without a sandbox that has a similar drawback as it allows all clients to intercept inputs and send fake inputs to any window.
- stelonix 6y ago
  Fake input under X11 (XTEST) is marked as fake input and any application receiving such events can choose to ignore it. Wine does it, for example.
  - cycloptic 6y ago
    Right, so that would be a place where something like ydotool would come in handy too because fake inputs coming from there wouldn't be coming from the XTEST device.
- mook 6y ago
  Independent of Wayland or X11, why should a user not be able to take inputs for their own window (as in, the owning process is run as the same user)? Why does it require a tool that needs extra privileges (that presumably works by doing it at a lower level)? That's a genuine question — as in, I'm mostly thinking about Windows and how window message handling works with UAC windows. You can send messages to your own windows all day without needing extra permissions, but not other users' windows. I assume that's what you're referring to with the X11 sandbox; is it reasonable to set up Wayland _without_ such a sandbox?
  - chousuke 6y ago
    The short reason is that if the user can do it, so can any application running as the user. I don't know about you, but I'd prefer my applications not be able to inject and read inputs arbitrarily, though it may be that even stricter sandboxing is needed to make that a reality; Wayland being stricter than X11 is just one step along the way.
    - Blikkentrekker 6y ago
      > though it may be that even stricter sandboxing is needed to make that a reality; Wayland being stricter than X11 is just one step along the way. It is not a situation of “it may be”; it is a situation of “it is”. Right now, it is useless as the security boundary on Unix and any other operating system is fundamentally the user and malicious software that runs as one's user can modify every file and process one owns anyway. I read one comment a while back by a developer that illustrated the fruitlessness of Wayland by saying that it is essentially a lock on a door, that stands in the middle of room, that one can simply walk around, claiming to add security.
      - cycloptic 6y ago
        That would be true if someone refused to use any form of sandboxing, however there are multiple sandboxing solutions available that the "door" works in combination with. That is the only real way to make this kind of security work on an ordinary Linux distribution, the approach used by Android where a new user is created for each application is not really feasible. There are also ways to sandbox X11, it's a bit harder to do, but you do have some options on how you'd like to do things.

thayne 6y ago

A few off the top of my head: - Take a screenshot, or share a single window - Screenshot, screenshare, or remote desktop/VNC server without having to use different protocols for different compositors - Use a third party app to control monitor outputs(resolution, orientation, framerate, layout, etc.) generally, for example arandr or xrandr (wlroots does support this) - Be able to do something like KeepassXC's "Autotyping", where it fills in a text field with the password from your password manager. - Have a third party app give a selection of open windows. I think all compositors have some API for this, but they are all different. (for example rofi's window switcher mode). Generally, I think the problem isn't so much things that can't be done in wayland at all, as the way to do them is different across different compositors, so whereas with X it was pretty straightforward to mix and match apps between different DEs and apps that worked on all of them. In wayland there are more apps that only work on gnome, only work on kde, or only work on wlroots based compositors. And some apps that duplicate parts of the code for all three.

cycloptic 6y ago
For screenshots or screensharing, please use the xdg-desktop-portal API. That should work correctly in X11, Wayland, and within a sandbox. For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox. For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell. Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that.
- Blikkentrekker 6y ago
  > For screenshots or screensharing, please use the xdg-desktop-portal API. That should work correctly in X11, Wayland, and within a sandbox. This does not allow one to write a screenshot application; this has a protocol that allows Flatpak applications to requæst that the compositor take one and as far as I know it only has support to take on from the entire screen. Most compositors also have the ability to take such screenshots outside of Flatpak; this simply moves it inside of it. The “screenshot issue” with Wayland is not that compositors can't take one; it's the lack of an the a.p.i.'s necessary to write software that can take one. > For generating fake inputs, a library is being worked on called libei, that also should work in X11, Wayland, and within a sandbox. I could find nothing on this on the internet. > For controlling monitor outputs and open windows, those APIs are different because each compositor has a different set of features for what those mean. Generally you should not be using random applications to configure monitor outputs, only your compositor's configuration tool is going to be reliable there. Applications that need to set custom resolutions can use the viewporter or use fullscreen-shell. And that one “should not do this” yet this is supported and used by many on X11 would be one of the missing features that would lead to Wine developers not being interested in a Wayland port. > Worst case scenario if you need to duplicate parts of the code for all three, I don't think that's a problem. Just put it in a library if it needs to be re-used, the only alternative there is that upstream maintains the relevant bits of that duplicate code, which I'm sure you can see why they would be reluctant to do that. The problem is that these per compositor a.p.i.'s are unstable. GNOME extensions and KWIN scripts work by allowing one to directly hack the internals of the compositor in unstable ways; they are much like kernel modules and they break from version to version.