I have a big 49" wide screen monitor and sharing my screen in Google Meet was cumbersome because you can only share a window or the whole screen, but not a screen region.
So I wrote a small tool that uses the xrandr extension to mirror an area to a virtual monitor which then can be shared.
This is very cool and definitely useful when you have a large screen at your disposal. I have a 27" screen which doesn't give you as much screen real-estate as yours.
So what I'm using is a script which spawns a separate Xephyr window as DISPLAY 9, and puts a bunch of windows on that screen. https://gist.github.com/radupotop/d77a47767e2e65a7e7d40d1ea8...
I use this as my demo environment.
However, both Xephyr/Xnest and "xrandr --setmonitor" create separate non-overlapping screen(s), which means sharing part of a window (say, browser sans chrome [1]) can't be done here, but is possible with OP's tool.
[1] EDIT: "chrome", as in - parts of browser's window other than webpage itself: tabs, URL bar, bookmarks, etc...
The code is a little weird. There is no XLib event loop. It calls sleep(100) in a loop until it hits SIGINT. That will have high cpu usage for no reason.
It will not, even adding just a 1ms sleep in a loop will drop CPU usage to barely noticeable levels, 10 wakes a second is barely anything for any CPU from the past 3 decades.
Yes, but I believe op was refering to how interacting with all things Wayland seems to be more involved than with x11. I'm not sure this is indeed like this, I have zero experience in developing for Wayland, but I think this is what op meant.
This certainly is an elegant X.org party trick that can't be done easily in almost any other windowing system: creating a virtual Xrandr display that overlaps with existing physical displays. It's slightly awkward since if it exits outside of sigint it will leave a virtual output and no overlay window but that's a pretty minor issue. (All of that having been said, I would strongly advise to not over-index on SLoC as a measure of quality or elegance.)
This flat-out can't be done in Wayland. Though all is not lost, you might not need this at all in Wayland. The standard way to capture the screen from an unprivileged process in Wayland is through desktop portals, and at least KDE supports a wide variety of different capture options including capturing a rectangle of the screen. I haven't tried, but I suspect this is even true when running X.org applications, thanks to XWaylandVideoBridge.
I am not really thrilled about D-Bus stuff everywhere, but it is nice that you can pretty much override any screen capture behavior you want by changing the org.freedesktop.impl.portal.ScreenCast implementation: I think that's actually a step in a better direction versus having every application implement its own functionality for selecting capture targets.
To me it's quite sad that for a lot of things, the "standard" way of doing something is not actually part of the standard (XDG portals, third party protocols, etc.). Yes, X.org is old, bloated, unmaintainable and whathever, but at least every desktop environment used the same X server implementation and the same tools worked everywhere.
Besides the duplication of efforts in implementing the same stuff over and over, now someone developing somewhat non-trivial programs needs to be aware of the differences in supported features and non-standard extensions in all desktops, for example [1].
there's very little code because there's very little error handling / sanity checking.
not saying X11 isn't hackable and cool, but a lot of code gets bloated and complex (and robust!) by not assuming perfect usage.
True. If something goes wrong this will just crash. But to be fair, the only error handling I could think of would probably just exit with a vague error message... Pull requests to make it more robust welcome anyway!
Yeah. I mean, not to deny the decades of arguments over its warts, but it's kind of amazing to me the extent to which X11 has emerged as, well, the simplest/best and most hackable desktop graphics environment available. You want to play a trick, it's right there. The ICCCM got a ton of hate back in the early 90's, but... no one else has an equivalent and people still innovate in the WM space even today.
X11 is the opposite of simple and hackable. What you are thinking of as "hackable" is actually the result of it having a ton of legacy features that enable users to do neat tricks.
Wayland breaks a lot of these tools because it is so much simpler than X.
Wayland intentionally makes this more difficult, because one of the security goals of the project is that (by default) Wayland clients shouldn't have visibility into other clients' window contents/events/etc.
Of course, it still needs to be possible under Wayland, because there are plenty of legitimate use-cases (screenshots, screen sharing, video capture, etc.), but it was a non-goal to make it as simple as X.
Also, I remember a friend showing me in Zoom that you can share not just one but multiple screens/windows—press the SHFT key while clicking the windows you want to share.
Do I understand correctly that you could to this with OBS on any platform, including Wayland? I'm reading many comments that make me think either many people don't know about OBS, or I'm overestimating it's abilities.
I don't understand, what is the significance of a 20kb binary? The only person using this would be someone who takes Zoom meetings on a company-issued computer and I can't imagine such machines are disk space-constrained.
It can do that, yes, but it's a bit more work. There are several GUI hoops you'll have to run through to get that to work, and if you have to adjust it each and every time, before a meeting, then it would become burdensome. But yes, it can be done.
With OBS, you can add an entire screen to your canvas and then add a filter to crop it down to a particular part of that screen. This nets you the same results as the small C++ tool being proposed here.
With my 49" I use OBS + Mouse follow script + OBS preview window on laptop screen and share my entire laptop screen. That way I know the window size is suitable for others viewing from their laptops and the preview follows my mouse and you can tweak zoom levels and mouse boundaries on the fly. Also the OBS preview window opens on launch, without opening the main OBS window. So you never have to see/interact with the main OBS window/application again so it really feels standalone which is great.
When I click share in Jitsi (or whatever) on KDE 6.1 w/ Wayland in Chromium, I get offered to share the 'Entire Screen". After that dialog another one pops up with the options 'Full Workspace', 'New Virtual Output', 'Rectangular Region' and a list of my displays. 'Rectangular Region' allows to share a selected part of the screen, 'New Virtual Output' instantly creates a virtual screen, visible in KDE 'Display Configuration' that may or may not be positioned on top of pre-existing physical displays.
Built it and took a fullscreen screenshot with GIMP to figure out the width/height/x/y coordinates I wanted and tested with Google Meet. Working perfectly!
https://github.com/naelstrof/slop Can also use a utility like this one, which lets you select an area of the screen and output it in a specified format.
Readit News
So I wrote a small tool that uses the xrandr extension to mirror an area to a virtual monitor which then can be shared.
See my blog post for some more details: https://www.splitbrain.org/blog/2024-10/11-introducing_clips...
https://askubuntu.com/q/150066#998435
However, both Xephyr/Xnest and "xrandr --setmonitor" create separate non-overlapping screen(s), which means sharing part of a window (say, browser sans chrome [1]) can't be done here, but is possible with OP's tool.
[1] EDIT: "chrome", as in - parts of browser's window other than webpage itself: tabs, URL bar, bookmarks, etc...
This flat-out can't be done in Wayland. Though all is not lost, you might not need this at all in Wayland. The standard way to capture the screen from an unprivileged process in Wayland is through desktop portals, and at least KDE supports a wide variety of different capture options including capturing a rectangle of the screen. I haven't tried, but I suspect this is even true when running X.org applications, thanks to XWaylandVideoBridge.
I am not really thrilled about D-Bus stuff everywhere, but it is nice that you can pretty much override any screen capture behavior you want by changing the org.freedesktop.impl.portal.ScreenCast implementation: I think that's actually a step in a better direction versus having every application implement its own functionality for selecting capture targets.
Besides the duplication of efforts in implementing the same stuff over and over, now someone developing somewhat non-trivial programs needs to be aware of the differences in supported features and non-standard extensions in all desktops, for example [1].
[1]: https://wayland.app/protocols/cursor-shape-v1#compositor-sup...
for example. run ./clipscreen 1 2 3 4
Wayland breaks a lot of these tools because it is so much simpler than X.
Of course, it still needs to be possible under Wayland, because there are plenty of legitimate use-cases (screenshots, screen sharing, video capture, etc.), but it was a non-goal to make it as simple as X.
Wayland merged the image-capture-source and image-copy-capture protocol extensions earlier this year: https://www.phoronix.com/news/Wayland-Merges-Screen-Capture
Deleted Comment
Shift+Click: select from currently selected item to clicked item
Ctrl+Click: add/remove clicked item to set of selected items
More useful shortcuts in https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_arti...
xrandr --setmonitor screenshare 2560/1x1440/1+0+0 none
geo=$(slop -f '%w/1x%h/1+%x+%y') && xrandr --setmonitor screenshare "$geo" none
xrandr --delmonitor screenshare
before this to seamlessly update the shared region — Chrome will immediately pick up the change and continue sharing the updated virtual monitor.
Deleted Comment
A lot more work involved, though.
https://github.com/BlankSourceCode/obs-zoom-to-mouse
Awesome!