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.

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

Unable to Share Specific Chrome Window in Screen Sharing - Shares Entire Screen Instead #16

Closed
rmasad opened this issue Mar 10, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@rmasad
Copy link

rmasad commented Mar 10, 2024

Sway Version: 1.8

Description:
I have encountered a significant issue while attempting to share a specific window from Chrome during video calls or screen sharing sessions (like Google Meets). Instead of sharing just the selected Chrome window, the entire screen gets shared, including all open applications and desktop activities. This problem specifically occurs when trying to share a window; however, sharing a single tab within Chrome or the entire screen functions as expected. This issue raises privacy concerns and limits the flexibility needed during presentations or collaborative work sessions.

Steps to Reproduce:

  1. Open Chrome and navigate to any website.
  2. Start a video call using Google Meets (or any other application where the issue occurs).
  3. During the call, choose to share your screen and select the option to share a window.
  4. Select a Chrome window from the list of available windows to share.

Expected Behavior:
Only the selected Chrome window should be shared with participants, hiding any other applications or desktop activities.

Actual Behavior:
The entire screen is shared instead of just the selected Chrome window, displaying all open applications and desktop activities to the participants.

@rmasad rmasad added the bug Something isn't working label Mar 10, 2024
@SoumyaRanjanPatnaik
Copy link
Collaborator

Hi @rmasad. AFAIK, this is a known issue for sway. Wayland currently lacks a protocol that allows for sharing windows. This comment tracks the status / progress for window sharing.

@SoumyaRanjanPatnaik
Copy link
Collaborator

Currently the best workaround for this is to create a headless display and share that instead of one of your physical monitors. You can then move any windows you want to share.

@SoumyaRanjanPatnaik
Copy link
Collaborator

As a side note, sway 1.9 is availabe in noble as part of regolith 3.2 beta 1 release. Although it is unlikely to fix this, you can still give it a try. https://regolith-desktop.com/docs/reference/Releases/regolith-3.2-release-notes/

@rmasad
Copy link
Author

rmasad commented May 21, 2024

Reading the threads on the topic, have you analyzed Regolith+hyprland? It looks like a version of sway with fewer problems.

@SoumyaRanjanPatnaik
Copy link
Collaborator

The regolith ecosystem was originally built mainly around i3 as the window manager. sway, being as close to a drop-in as possible, made creating a functionally equivalent desktop environment reasonably straightforward. Another benefit of sticking with sway is the stability / backwards compatibility it provides. It has been in development since almost 9-10 years now. In comparison, the development effort required to keep up with Hyprland would probably be significantly more, given its rapid development speed.

That said, imagining a Hyprland based version of Regolith is not entirely impossible. I have occasionally considered trying this out as a hobby project, but it would require a lot more time and effort than any of us can spare.

@rmasad
Copy link
Author

rmasad commented May 22, 2024

Thanks @SoumyaRanjanPatnaik

@rmasad rmasad closed this as completed May 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants