Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add PipeWire camera/screen sharing support #132

Open
intgr opened this issue Jun 12, 2023 · 2 comments
Open

Add PipeWire camera/screen sharing support #132

intgr opened this issue Jun 12, 2023 · 2 comments
Labels
enhancement New feature or request wishlist Low-priority "maybe" tasks

Comments

@intgr
Copy link
Owner

intgr commented Jun 12, 2023

Hopefully it's possible to implement this with filesystem ACLs, just like PulseAudio/Wayland.

Haven't looked into this in detail yet.
@intgr intgr mentioned this issue Jun 12, 2023
Closed
@intgr intgr added the enhancement New feature or request label Jun 12, 2023
@intgr intgr added the wishlist Low-priority "maybe" tasks label Oct 12, 2023
@anzix anzix mentioned this issue Nov 30, 2024
Open
@anzix
Copy link

anzix commented Dec 2, 2024 •
edited
Loading

Here are my tests on the KDE Plasma Wayland session. When I launch ego with Firefox by checking the site https://permission.site by clicking on "Screen Share", when selecting "Entire screen", the Portal Screen/Window Picker window does not appear, respectively, the preview window is not visible. The only thing that works is the XWayland Video Bridge, but I don't want to choose it because it doesn't happen the first time it sets the correct proportions when Sharing the Screen (it displays normally on the screenshot)

Screenshot_20241202_154052
Screenshot_20241202_154300
Screenshot_20241202_155554
Screenshot_20241202_155607

There is no information in the Firefox logs, however, when using Ungoogled Chromium (possibly on regular Chromium), these errors occur at the start (both through XWayland using xhost, and on native Wayland using the browser flag --ozone-platform-hint=auto)

$ ego -vvv -u anon env LANG=C chromium
...
[868502:868809:1202/155839.945515:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.DBus.StartServiceByName: object_path= /org/freedesktop/DBus: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
[868502:868502:1202/155839.946435:ERROR:object_proxy.cc(576)] Failed to call method: org.freedesktop.portal.Secret.RetrieveSecret: object_path= /org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.Secret” on object at path /org/freedesktop/portal/desktop
[868502:868502:1202/155839.946450:ERROR:secret_portal_key_provider.cc(150)] Failed to retrieve secret: No response from portal.

I suspect that this is a conflicting running dbus process, or probably some permissions not set for dbus. I'm not sure for sure.

There are also other interesting logs, for example, inside the second user, the systemd status of the xdg-dekstop-portal service is such warnings

$ ego -vvv -u anon env LANG=C systemctl --user status xdg-desktop-portal
...
● xdg-desktop-portal.service - Portal service
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
     Active: active (running) since Mon 2024-12-02 16:12:19 +05; 2min 25s ago
 Invocation: 626f733e06dd40b3868d9b050f7f9544
   Main PID: 2512754 (xdg-desktop-por)
      Tasks: 7 (limit: 18997)
     Memory: 3M (peak: 3.7M)
        CPU: 47ms
     CGroup: /user.slice/user-1001.slice/[email protected]/session.slice/xdg-desktop-portal.service
             `-2512754 /usr/lib/xdg-desktop-portal

Dec 02 16:12:19 arch xdg-desktop-por[2512754]: Choosing gtk.portal for org.freedesktop.impl.portal.FileChooser as a last-resort fallback
Dec 02 16:12:19 arch xdg-desktop-por[2512754]: Choosing gtk.portal for org.freedesktop.impl.portal.AppChooser as a last-resort fallback
Dec 02 16:12:19 arch xdg-desktop-por[2512754]: Choosing gtk.portal for org.freedesktop.impl.portal.Print as a last-resort fallback
Dec 02 16:12:19 arch xdg-desktop-por[2512754]: Choosing gtk.portal for org.freedesktop.impl.portal.Notification as a last-resort fallback
Dec 02 16:12:19 arch xdg-desktop-por[2512754]: Choosing gtk.portal for org.freedesktop.impl.portal.Inhibit as a last-resort fallback
Dec 02 16:12:19 arch xdg-desktop-por[2512754]: Choosing gtk.portal for org.freedesktop.impl.portal.Access as a last-resort fallback
Dec 02 16:12:19 arch xdg-desktop-por[2512754]: Choosing gtk.portal for org.freedesktop.impl.portal.Account as a last-resort fallback
Dec 02 16:12:19 arch xdg-desktop-por[2512754]: Choosing gtk.portal for org.freedesktop.impl.portal.Email as a last-resort fallback
Dec 02 16:12:19 arch xdg-desktop-por[2512754]: Choosing gtk.portal for org.freedesktop.impl.portal.DynamicLauncher as a last-resort fallback
Dec 02 16:12:19 arch systemd[2511547]: Started Portal service.

Inside the second user, when launching the browser, other systemd services such as pipewire, pipewire-pulse and wireplumber work properly, without errors

@intgr
Copy link
Owner Author

intgr commented Dec 9, 2024

While experimenting with Wayland #168, I discovered that PipeWire also supports a "security context" system similar to Wayland.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request wishlist Low-priority "maybe" tasks
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@intgr @anzix