4 ms·

There's nothing inherently preventing any of these things from working on Wayland. I mean yes, the protocol (and its implementations) are meant to disallow prog

by alxlaz 7y ago

There's nothing inherently preventing any of these things from working on Wayland. I mean yes, the protocol (and its implementations) are meant to disallow programs from seeing each others pixels and input events by default and/or without authorization, which isn't a stupid idea at all. But you can certainly implement screenshots, video capturing, automatic input, screen sharing and whatever in Wayland compositors. I think Sway implements most of these things, in fact. (FWIW, X11's approach to program isolation isn't ideal for everything, either. The same things that make it so convenient to automate mouse and keyboard input make it very hard to write a good screen locker, for example.) Whether or not we'll see free (as in freedom and beer) compositors that conveniently implement all these things is a whole different story. A lot of XFree86's (and later Xorg's) feature set was developed by well-paid teams of experienced engineers, who benefited from a lot of work done by other well-paid teams on other platforms, and the architecture and licensing of the whole thing meant that everyone could benefit from their work. That's not really the case with Wayland. There's actually a lot of work, and a lot of money being poured into Wayland compositors. Lots of car infotainment systems run one, for example, and Wayland support has been pretty much a standard requirement for virtually every BSP I've worked on in the last four years. But most of that work is very system-specific, platform-specific, and its substantial part -- the code -- never gets upstreamed, because "upstream" is just a protocol spec. A lot of the Wayland protocol has been standardized that way, but it's still up to every compositor to implement it. There's some hope due to projects like wlroots and Drew de Vault, its lead developer, is one of those people who seem like they can pull anything off. (Oh yeah: https://drewdevault.com/donate/ https://drewdevault.com/donate/ ). But -- unlike twenty years ago -- there's very little commercial backing for Linux on the desktop. I don't know if the FOSS community will be able to keep up with these things.

sprash 7y ago
> There's nothing inherently preventing any of these things from working on Wayland. In theory that is correct. In practice, the Wayland protocol fails to address the required access control policy interfaces necessary for a modern Desktop to work. A Desktop is not a phone interface or a car entertainment system. Resource sharing that enables basic things like push-to-talk, remote work or full screen streaming are absolutely essential for a Desktop computing environment. Wayland developers push such functionality down as a particular "implementation detail" of a Wayland compositor, which is a huge mistake. Donating to braindead projects like wlroots will not solve the problem at all. Access control policy needs to be made part of the core protocol ASAP or Wayland will have no chance to succeed in any meaningful way in the future.
- alxlaz 7y ago
  That's really not how Wayland development works. Except for resource management and data transfer (wl_compositor, wl_shm_pool etc.), pretty much everything in the "core" Wayland protocol has originated in compositor implementations that were then standardized. "Donating to braindead projects like wlroots" is exactly how this problem is going to be solved. There's no Wayland cabal where people just sit around a table writing specifications in the hope that they'll eventually get implemented somewhere. This is pretty much how X11 was built, too, by the way.
  - sprash 7y ago
    > That's really not how Wayland development works Maybe then Wayland should change "how Wayland developement works" because after 10 years of developement the results are disappointing to say the least. Projects like the Arcan display server show that even a single dude writing stuff in his spare time can easily be more productive.
    - alxlaz 7y ago
      It's a development model that worked reasonably well for the X protocol. Wayland isn't great now but it's not much worse than X was in 1994, after 10 years of development (and the first version of X11, which saw the light of day in 1987 or so, was pretty different from the early drafts of the X protocol). There was no ICCCM back then (ok, there was ICCCM 1.0 but that wasn't anywhere near great or universal), no session management, no xkb, no xdamage, no Xinerama, no hotplug, no glx, no randr... It helped that there were a bunch of big players sinking lots of money into it, and the documentation was good enough that it was easy to get started -- way easier than it is with Wayland. So after 1993 or so things really started picking up speed. But Xfree cca. 1994 wasn't great.
      - sprash 7y ago
        > It's a development model that worked reasonably well for the X protocol. The development of early X11 didn't work very well at all. Even Keith Packard himself says so [1]. 1.: https://www.youtube.com/watch?v=cj02_UeUnGQ https://www.youtube.com/watch?v=cj02_UeUnGQ

by alxlaz 7y ago

sprash 7y ago

> There's nothing inherently preventing any of these things from working on Wayland. In theory that is correct. In practice, the Wayland protocol fails to address the required access control policy interfaces necessary for a modern Desktop to work. A Desktop is not a phone interface or a car entertainment system. Resource sharing that enables basic things like push-to-talk, remote work or full screen streaming are absolutely essential for a Desktop computing environment. Wayland developers push such functionality down as a particular "implementation detail" of a Wayland compositor, which is a huge mistake. Donating to braindead projects like wlroots will not solve the problem at all. Access control policy needs to be made part of the core protocol ASAP or Wayland will have no chance to succeed in any meaningful way in the future.

alxlaz 7y ago
That's really not how Wayland development works. Except for resource management and data transfer (wl_compositor, wl_shm_pool etc.), pretty much everything in the "core" Wayland protocol has originated in compositor implementations that were then standardized. "Donating to braindead projects like wlroots" is exactly how this problem is going to be solved. There's no Wayland cabal where people just sit around a table writing specifications in the hope that they'll eventually get implemented somewhere. This is pretty much how X11 was built, too, by the way.
- sprash 7y ago
  > That's really not how Wayland development works Maybe then Wayland should change "how Wayland developement works" because after 10 years of developement the results are disappointing to say the least. Projects like the Arcan display server show that even a single dude writing stuff in his spare time can easily be more productive.
  - alxlaz 7y ago
    It's a development model that worked reasonably well for the X protocol. Wayland isn't great now but it's not much worse than X was in 1994, after 10 years of development (and the first version of X11, which saw the light of day in 1987 or so, was pretty different from the early drafts of the X protocol). There was no ICCCM back then (ok, there was ICCCM 1.0 but that wasn't anywhere near great or universal), no session management, no xkb, no xdamage, no Xinerama, no hotplug, no glx, no randr... It helped that there were a bunch of big players sinking lots of money into it, and the documentation was good enough that it was easy to get started -- way easier than it is with Wayland. So after 1993 or so things really started picking up speed. But Xfree cca. 1994 wasn't great.
    - sprash 7y ago
      > It's a development model that worked reasonably well for the X protocol. The development of early X11 didn't work very well at all. Even Keith Packard himself says so [1]. 1.: https://www.youtube.com/watch?v=cj02_UeUnGQ https://www.youtube.com/watch?v=cj02_UeUnGQ