3 ms·

> The solution is to use Pipewire and DBus to connect to proprietary APIs. I don't understand this at all. Can you open a bit more? To my understanding, curren

by nicce 4y ago

> The solution is to use Pipewire and DBus to connect to proprietary APIs. I don't understand this at all. Can you open a bit more? To my understanding, current screen recording is relying mainly on xdg-desktop-portal and it's variations. It depends on flatpak and glib and uses D-bus. None of these are proprietary to my knowledge. With these, it supports WebRTC out of the box for browser, and for example OBS studio supports natively, and works really well. Apps need to implement and use org.freedesktop.portal.* interfaces to support screen recording in Wayland.

happymellon 4y ago
Proprietary is probably the wrong word. Non-standardised perhaps, specific to the desktop implementation and by implementing the Wayland specification does not give you appropriate screensharing APIs in that namespace. Because the APIs that are exposed by Gnome, KDE, and wl-roots are all different. Flatpak has access to the `xdg-desktop-portal.*` namespace, but everyone has their own implementation so saying they use the standard namespace is misleading as it makes it sound like all the work is done. Pipewire masks all that by implementing everyone's API and then exposing this via the Pipewire API, neatly solving the Wayland limitation and providing a standard. The original statement was: > Wayland is not preventing screen sharing or recoring. The API supports it pretty well. No it does not. Pipewire does.
- nicce 4y ago
  I see now. Thanks for the info.
- vetinari 4y ago
  This is a fight implementations cannot win. So there is demand for API. Gnome, KDE, wl-roots implement it, in the discovery phase by their unique way, so we have 3 different APIs. Then, once the requirements are known, standardization happens and every compositor implements the standard API. So far, good. But what happens with the old, experimental APIs? Because meanwhile, there are apps, that do use them. Remove the old APIs and you will have cries on the Internets, how you break compatibility again (even if you announce deprecation plan years upfront). Do not remove them, and you have complains, that every compositor has its own API (ignoring, that there is a standardized one too, now). So, there's no pleasing everyone. Someone will complain. > No it does not. Pipewire does. xdg-deskop-portal-(gnome|kde|wlr), among other things, which do include desktop-specific dialogs related to the functionality.
  - happymellon 4y ago
    Of course they will. Normally though you have a roadmap with features that people want and screensharing was not a feature that Wayland wanted to get involved in because it runs against their ideology. That is simply all we are talking about. I don't think the situation that we are in now is terrible, it's just a shame that Wayland ignored it and so it's taken much longer than it should to get it in place.

by nicce 4y ago

happymellon 4y ago

Proprietary is probably the wrong word. Non-standardised perhaps, specific to the desktop implementation and by implementing the Wayland specification does not give you appropriate screensharing APIs in that namespace. Because the APIs that are exposed by Gnome, KDE, and wl-roots are all different. Flatpak has access to the `xdg-desktop-portal.*` namespace, but everyone has their own implementation so saying they use the standard namespace is misleading as it makes it sound like all the work is done. Pipewire masks all that by implementing everyone's API and then exposing this via the Pipewire API, neatly solving the Wayland limitation and providing a standard. The original statement was: > Wayland is not preventing screen sharing or recoring. The API supports it pretty well. No it does not. Pipewire does.

nicce 4y ago
I see now. Thanks for the info.
vetinari 4y ago
This is a fight implementations cannot win. So there is demand for API. Gnome, KDE, wl-roots implement it, in the discovery phase by their unique way, so we have 3 different APIs. Then, once the requirements are known, standardization happens and every compositor implements the standard API. So far, good. But what happens with the old, experimental APIs? Because meanwhile, there are apps, that do use them. Remove the old APIs and you will have cries on the Internets, how you break compatibility again (even if you announce deprecation plan years upfront). Do not remove them, and you have complains, that every compositor has its own API (ignoring, that there is a standardized one too, now). So, there's no pleasing everyone. Someone will complain. > No it does not. Pipewire does. xdg-deskop-portal-(gnome|kde|wlr), among other things, which do include desktop-specific dialogs related to the functionality.
- happymellon 4y ago
  Of course they will. Normally though you have a roadmap with features that people want and screensharing was not a feature that Wayland wanted to get involved in because it runs against their ideology. That is simply all we are talking about. I don't think the situation that we are in now is terrible, it's just a shame that Wayland ignored it and so it's taken much longer than it should to get it in place.