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.
Sure, if that is the only program, but it is not. This kind of thinking drains batteries faster than necessary, drains the cache, and reduces CPU efficiency.
sleep() is a wasteful system call, a kludge at best, and is never the correct solution to a synchronization problem.
It's an irrelevant implementation detail. This is for a live call. You are streaming video at the same time, so there's no point in worrying about idling.
I'd even say that it's a good example for others, because the equivalent code with the event loop would be slightly more complicated (maybe 5 more lines?). Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example.
My guess is that somebody coded that event-loop-less X client not really familiar with the language and how to write Xlib apps. I partially assume this because C, C++ and especially Xlib are becoming less popular over time, so finding skilled practitioners to write it idiomatically is relatively rare now. This basic event loop stuff is something that maybe belongs in a library. So they just wrote library grade functionality themselves, badly. The commentary here is getting defensive about doing things the wrong way, coming up with lots of post hoc justification.
> You are streaming video at the same time, so there's no point in worrying about idling.
I'd argue it's completely opposite of this. You're streaming video, already putting some significant stress on the system. No reason to waste time (even if it's a minuscule amount) to make things worse.
> Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example.
And that's how we ended with e.g. modern IoT that kinda sorta works but accumulation of minor bad decisions (and some less minor bad decisions for sure) ends up making the whole thing a hot mess.
Sleeping for 100ms between checking for events will not produce a noticeable CPU load. The only reason this would drain the battery is because it can prevent the CPU from entering deeper powersaving states - but even for that 100ms is an eternity and video streaming will prevent that anyway.
Not my experience at all. Granted I haven't tried writing a loop like this in 20ish years, because once you spot that mistake you don't tend to make it again, and CPUs are better now.
Another thing to note is when you call sleep with a low value it may decide not to sleep at all, so this loop just might be constantly doing syscalls in a tight loop.
> Not my experience at all. Granted I haven't tried writing a loop like this in 20ish years, because once you spot that mistake you don't tend to make it again, and CPUs are better now.
You can trivially verify it by running the following, I have personally been using "sleep for 1ms in a loop to prevent CPU burn" for years and never noticed it having any impact, it's not until I go into microseconds when I can start noticing my CPU doing more busy work.
> Another thing to note is when you call sleep with a low value it may decide not to sleep at all, so this loop just might be constantly doing syscalls in a tight loop.
On what system? AFAIK, if your sleep time is low enough, it will round up to whatever is the OS clock resolution multiple, not skip the sleep call completely. On Linux, it will use nanosleep(2) and I cannot see any mention of the sleep not suspending the thread at all with low values.
If memory serves, Windows treats a sleep under the scheduler quantum length as a yield. It may take you off the cpu if there's something else to run but it may not. Meanwhile burning up cycles may prevent low power states.
At any rate, back to the code at hand, there are many ways to block on SIGINT without polling. But it's also hugely odd that this code does not read events from the X11 socket while it does so. This is code smell, and a poorly behaved X client.
You can't find that proof because Linux does the opposite. Unless your task is SCHED_REALTIME, all timers have a little bit of slack at the end that allows the kernel to group wakeup events. You can configure this (for non-RT tasks) with prctl(PR_SET_TIMERSLACK).
There is no code in nanosleep that converts it into a yield, and in fact a nanosleep(0) is a nanosleep(50µs) with the default timer slack value. If you want to yield, call sched_yield() …
I looked into this a bit further and it seems to be a range from [0,50]. [1] explains that if there is a pre-existing timer interrupt at 0, then the queue will be resumed at 0. But yes - given no other timers it will resume at 50.
It used to be the case that glibc implemented nanosleep for small values below the scheduling quantum with a spin loop. It was explicitly documented to do so.
This was changed sometimes in the last 20 years, probably with battery powered devices becoming more prevalent and CPUs implementing more advanced sleep states.
Whether the CPU is busy because of a loop with a sleep depends on the ration of the sleep time and the time to perform the rest of one loop iteration. Doing stuff in a loop iteration that takes 1min and then adding a ms sleep will not drop CPU usage a measurable amount.
The question is about waiting, i.e. when you have no real work to do. If you have significant work to do then there is no point in sleeping until that work is done.
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.
Wayland is more focused on security. That onion layer right there will increase the complexity of usage. X11 doesn't have the extra abstractions to limit and prevent intrusive interactions with the desktop.
Example of this would be where "runas /user:smith application.exe" is simple but does not work when a Windows Service is required to run an application as the user signed in. One must use Window's API to pull in the account's token and use more API to execute "application.exe". UltraVNC is a great source to see all the extras needed.
From a quick "how do I implement this in Python" with ChatGPT it seems to be about 30 lines, since most of the heavy lifting is done for you by the API.
As someone who uses LLM's regularly to assist in code creation, take that output with a huge grain of salt until you've actually tested it. Especially as it relates to Wayland, I've pulled my hair out trying to get an LLM to assist with very similar tasks to this.
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].
I think Wayland had made some mistakes, no doubt. Cursor shape just should've been part of the protocol. Wayland has its fair share of misfires.
That said, I understand what they were going for. They really wanted to make the compositor as small and simple as possible, so for example you would just use libwayland-cursor instead of bothering with cursors yourself. However there are a lot of ways libwayland-cursor worked out poorly... Not everyone agreed on how scaling should work, GTK4 ditched it for performance reasons, and overall it's just inconvenient for a lot of cases (languages other than C, sandboxing, etc.) And to make matters even worse, in practice every compositor needed to load and handle XCursor themes anyways...
That said, I think that it's okay if Wayland doesn't own the majority of the Linux desktop stack the way X11 did. It's fine for compositors and their helpers to implement protocols from other projects, too. That way Wayland can be more applicable to graphical machines other than desktops without bringing unnecessary baggage. It'll always have trade-offs, of course, but I think it's far from the end of the world.
re cursors: There is a replacement/amendment protocol for cursor handling coming though I don't know the current status of it. It seemed a lot easier to work with for the vast majority of cases.
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!
To the parent, splitbrain just got you to QA this for him. The true cost of software is the maintenance and QA, and he got you to do free work, and here I am doing free work writing about it. How hard we BOTH just got pwned! </joke>
haha yeah, its ok for a tool its really cool honestly :p just commenting on the 'so little code' might be good to check if the x y etc. are within the screen / set resolution perhaps.
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.
I never understood the rationale for Wayland's "security"...
All the programs that I use (ls, rm, vim, ...) can "spy" to each other, and have unrestricted read/write access to all the bytes in my home directory. That's the whole point: I run these programs to control said bytes. What's so special about the pixels of my screen that the programs that manipulate them need to be protected from each other? If anything, the pixels in my screen seem less critical to security that the bytes in my disk. But Wayland insists in making that difficult, for incomprehensible reasons. Those are my pixels and I want to do what I decide, not what Wayland lets me to. I control my programs, not the other way round. If I decide that this program reads one pixel on my whole screen, or the global mouse position, or whatever, I see no point in forbidding me to do it.
Of course, if I want to run some rogue program whose author I don't trust, I will do so inside a limited container. But this has nothing to do with graphical applications. I wouldn't like the rogue program to read my homedir either.
You already can with X11, for example running your rogue graphical program inside a graphical virtual machine. The vm gui will filter-out the events that happen outside the window and the rogue program will think it's running alone.
It's nice that wayland makes such containerization much lighter, at least concerning the GUI (you still need to hide your filesystem, network, etc if you want to run rogue programs under wayland). But I don't see the point in enforcing it for each and every one of your programs. It's extremely unergonomic.
I think the general direction where Wayland, Flatpak and other similar sandbox frameworks are going is that of users running proprietary, untrusted and more or less user-hostile apps on the desktop, just like on tables and smartphones.
I don't run "apps" on my PC. I run programs from a trusted source repository. I expect those programs to not be hindered in their attempts to serve me.
Where does this paranoia come from? The kind of attacks cited by Wayland advocates are all theoretically possible but virtually unheard of in practice. In any time in the past thirty years, has there ever been a case of a rogue program in the Debian repos that maliciously spies on the user by exploiting the open and trusting nature of X11? Even if you expand the scope of consideration to applications like browsers getting pwnd by RCE zero days and then doing this, how often does this actually happen? Maybe this degree of paranoia, fear of technically possible but actually extremely rare scenarios, makes sense for targeted individuals like reporters and whistleblowers operating in totalitarian countries, but for anybody else it seems insane. It's like having deadbolts on your bedroom door because you're afraid of somebody trying to kidnap you in the middle of the night, that extra security against such an unlikely threat isn't worth the inconvenience. Except actually, getting kidnapped in the middle of the night is probably a more common occurrence than getting pwned through X11 programs from your distro repos.
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.
I find it very interesting how much our threat model has changed in the last 10-15 years. We no longer trust even local software, as we have to assume everything is now malicious. Commercial software from "reputable" companies can't be trusted to not pull a ton of analytics and personal data off your computer. We now have to worry about every piece of software being a keylogger and spying on other windows/applications and reporting back.
We've had to give up so much flexibility. Wayland certainly focuses on plugging this hole, but it means we've lost all these cool utilities like this one. There was just so much you could do with devilspie, xdotool, and others to make sure my operating system and window environment worked for me.
I still really miss X11's Zaphod mode, where you had two independent X sessions (:0.0 and :0.1) on two different monitors, with different window managers and different windowing rules.
I miss the days of being able to trust my computer and trust my software.
If you can't trust your locally installed software, everything is lost. I understand where this new threat model comes from for some people but I'd rather continue to avoid bad software sources than hamstring my OS in the hopes of avoiding malware I installed on purpose.
I agree. But can you trust Zoom? What about Office or Photoshop? Can you trust Websites or your browser anymore? Even open source apps have analytics in them that may not be trustworthy anymore (firefox, audacity, ...).
I teach online for a living, and -- yep Zoom through FIREFOX only.
Coincidentally, it's also the best experience, for whatever reason it's the only on that supports virtual backgrounds on Linux for me? Neither Chrome nor Desktop seem to work for this.
As for the rest, they may have "analytics" (spyware) but are there any documented cases of any of them acting as an X11 keyloggers or covertly screenshotting the users desktop? Those are the threats Wayland asks us to fear. And Wayland won't protect us from the rest. If Firefox or Audacity phone home with reports about what I'm doing with those applications, Wayland won't stand in the way.
What is interesting is that physical home security has gone in the opposite direction - people are happy to put dozens of devices in they home which can (and some definitely do) stream everything they hear and see to the cloud.
FWIW, the threat model you're imagining is an attacker being able to run code to display directly to the desktop using the lowest level native API. A local[1] code exploit at the level of an interactive user is already a huge failure in the modern world.
Is that a reasonable argument against using X11? Sure, for some use cases. Is it a good argument for wayland/windows/OSX/whatever to do your tiling WM experimentation? Not really, those environments kinda suck for playing around with.
[1] Or "local-ish", your system or a trusted remote has to have been compromised already. Untrusted X11 protocol still exists but is deliberately disabled (and often blocked) everywhere. Even ssh won't forward it anymore unless you dig out the option and turn it on manually.
Isn't any app that can access read the x11 socket able to read any input? It's not just running an explicitly malicious app but also the risk of compromising an app which can read the x11 socket (e.g. Firefox)
It's also why there existed more advanced security extensions for X11 (like security labels for windows), but also why even bare-bones X11 had methods to ensure that only one specific application was getting input, specifically to handle secure input like with passwords.
Yes, exactly. I'm just saying that the response to a remote browser exploit in firefox is more likely to be "YIKES ZERO DAY IN FIREFOX!!!!!" and not "well it's a good thing we're running it in windows so it can't screenshot other apps or inject key events".
It's not like it's not a valid argument, just that it's sort of a nitpick. Security is hard, and defense in depth is a thing, but this particular attack surface is way, way back in the "depth" stack for a modern app deployment.
Javascript has managed to even ruin the linux desktop. Running every random JS application sent to your browser VM makes the browser insecure which means the entire computer can't be trusted. This is the reason things like the waylands enforce a smartphone like model of security where the user's applications aren't allowed to communicate or interact with other elements of the graphical desktop. Applications aren't trusted. So the user isn't trusted. A trade-off not worth it.
Huh? What are you trying to say? There's no conflict between distrusting applications and trusting the user. Even on Android (which is pretty paranoid these days), you, the user, can still opt to trust apps with things like accessibility API access and background location.
Why exactly should we perpetuate the insecure old single-privilege-level desktop model?
>Why exactly should we perpetuate the insecure old single-privilege-level desktop model?
Because after 10 years of heavy development none of the waylands have managed support simple things like screen readers. X11 supports screen readers and innumberable other vital accessibility features that wayland never will be able to. Some waylands might eventually develop extensions for their particular desktop but there won't ever be a way for wayland protocol because it can't. Security theater is more important than accessibility/usability for wayland that leaves many use cases and entire demographics of people out in the cold.
So yes, X11, which is still the least worst option. Better to have the ability to do all things than have to wait decades+ for developers to write complex extensions to do things (and just for their DE, causing fragmentation).
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.
By window manager started out as ~50 lines of Ruby copying an equivalent amount of C.
You can say many things about Wayland, but it's "simple" from a point of view I for one really do not care about. Wayland may be "simple" in some respects, but it makes most of the things I care about doing unnecessarily complex.
Lacking features isn't the same thing as "simpler", Wayland is great, but is very much a subset of the features implemented on an X11 desktop. Wayland doesn't do selections or provide any IPC mechanism of its own, much less something like an ICCCM that allows you to identify/target other users of the desktop and interact with them in a flexible way. In fact as I understand it the linked tool is in fact impossible to write in Wayland.
Again, this isn't the fault of "Wayland", which is just a compositor framework. The complaint is that the ecosystem of "desktop" software which evolved around Wayland is an ad hoc monstrosity that lacks the unified structure that its ancestor had way back in the X11R5 days.
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.
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.
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.
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.
Can someone explain why this is still an unmet need within the current video conference platforms? Giant monitors have become increasingly common-especially for the developers who might be working on these tools.
We, as engineers, can't expect everyone to know what OBS is, download it, learn in, and use it every day to enable their ability to share a sub-section of their monitor (regardless of its size.)
We, as engineers, _are_ expected to make our software easier to use and feature rich. Adding this capability into Zoom or Meet, etc. is a reasonable thing to expect from a software company of note. And people _do_ know what Zoom and Meet are, download them, learn them, and use them every day. Why not implement the feature directly into the software they're already using?
Also which percentage of people taking part in meetings with screen sharing are even allowed to "just install" OBS? More for developers, much less for other office workers.
I wouldn't mind switching between windows if I could use the GNOME Activities overview for that. But maybe that is not possible because there is no way to communicate the change in stream size if the windows have different sizes?
This is surely useful right now. I wonder what will happens to all the nice X11 tools once Wayland (hopefully soon) will be the golden standard. There are options to enable X11 behaviors in Wayland but I guess that is just a fallback to the insecure implementation.
That only works if the workspace is on an actual screen, because it's otherwise not rendered. Maybe the virtual monitor solution via xrandr would work for that, but I haven't yet tried that.
Wasn't the same thing posted for MacOS a few days back, can't recall the name? Looking at the time on the repo makes me think the author pushed after seeing people requesting something similar for Linux.
That's not quite the same. With DeskPad you have to move the window to the virtual monitor. clipscreen allows you to select a portion of your screen without moving any windows.
I use "Advanced Screen Share" for this purpose. it has a one time purchase if you want to remove a small overlay but it gets the job done and is installable through the app store.
you can just share multiple windows on the newest macOS and they will ne nicely arranged for viewers. You can even add the presenter thing to show your face next to them.
I don't know if std::condition_variable is async-signal safe, but an easy fix is to replace the sleeping with pause(2). There's also sigwait(3), which wouldn't need a signal handler.
That s very cool... Speaking of which: any easy way to allow two people, both on X, to both share and interact (keyboard and mouse) with a common X window?
The app that we d like to share and both control is a browser (running on a machine on our LAN) so a browser extension would work too I guess.
I think there was some way to do that with existing tools. I forget the details because I only threw it together as a bit of fun novelty. I think the terms to google are x2x and multiseat though, at least to start your search…
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.
See my blog post for some more details: https://www.splitbrain.org/blog/2024-10/11-introducing_clips...
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.
Neat trick. Another, similar one, is possible with "xrandr --setmonitor". That doesn't require starting a separate X server & WM instance:
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...
I love how simple this is- Barely 100 lines or C++ (ignoring comments). That's one thing that makes me prefer X11 over Wayland.
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.
This is what the pause(2) syscall was made for, waiting for a signal forever.
Sure, if that is the only program, but it is not. This kind of thinking drains batteries faster than necessary, drains the cache, and reduces CPU efficiency. sleep() is a wasteful system call, a kludge at best, and is never the correct solution to a synchronization problem.
It’s a good way to drain your battery on mobile devices, even if usage looks low.
Not that this matters for this particular tool.
> Not that this matters for this particular tool.
Then the code is perfectly appropriate.
It's a bad example for others and a bad habit to get into. If every program did this, we'd have trouble getting CPUs into deep idle states.
It's an irrelevant implementation detail. This is for a live call. You are streaming video at the same time, so there's no point in worrying about idling.
I'd even say that it's a good example for others, because the equivalent code with the event loop would be slightly more complicated (maybe 5 more lines?). Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example.
My guess is that somebody coded that event-loop-less X client not really familiar with the language and how to write Xlib apps. I partially assume this because C, C++ and especially Xlib are becoming less popular over time, so finding skilled practitioners to write it idiomatically is relatively rare now. This basic event loop stuff is something that maybe belongs in a library. So they just wrote library grade functionality themselves, badly. The commentary here is getting defensive about doing things the wrong way, coming up with lots of post hoc justification.
> You are streaming video at the same time, so there's no point in worrying about idling.
I'd argue it's completely opposite of this. You're streaming video, already putting some significant stress on the system. No reason to waste time (even if it's a minuscule amount) to make things worse.
> Striving for "doing things right" when the wrong thing is perfectly appropriate would be a bad example.
And that's how we ended with e.g. modern IoT that kinda sorta works but accumulation of minor bad decisions (and some less minor bad decisions for sure) ends up making the whole thing a hot mess.
Sleeping for 100ms between checking for events will not produce a noticeable CPU load. The only reason this would drain the battery is because it can prevent the CPU from entering deeper powersaving states - but even for that 100ms is an eternity and video streaming will prevent that anyway.
[dead]
Not my experience at all. Granted I haven't tried writing a loop like this in 20ish years, because once you spot that mistake you don't tend to make it again, and CPUs are better now.
Another thing to note is when you call sleep with a low value it may decide not to sleep at all, so this loop just might be constantly doing syscalls in a tight loop.
> Not my experience at all. Granted I haven't tried writing a loop like this in 20ish years, because once you spot that mistake you don't tend to make it again, and CPUs are better now.
You can trivially verify it by running the following, I have personally been using "sleep for 1ms in a loop to prevent CPU burn" for years and never noticed it having any impact, it's not until I go into microseconds when I can start noticing my CPU doing more busy work.
> Another thing to note is when you call sleep with a low value it may decide not to sleep at all, so this loop just might be constantly doing syscalls in a tight loop.On what system? AFAIK, if your sleep time is low enough, it will round up to whatever is the OS clock resolution multiple, not skip the sleep call completely. On Linux, it will use nanosleep(2) and I cannot see any mention of the sleep not suspending the thread at all with low values.
If memory serves, Windows treats a sleep under the scheduler quantum length as a yield. It may take you off the cpu if there's something else to run but it may not. Meanwhile burning up cycles may prevent low power states.
At any rate, back to the code at hand, there are many ways to block on SIGINT without polling. But it's also hugely odd that this code does not read events from the X11 socket while it does so. This is code smell, and a poorly behaved X client.
I thought that Linux behaved the same, but I'm not finding any proof in `man 2 nanosleep`...
You can't find that proof because Linux does the opposite. Unless your task is SCHED_REALTIME, all timers have a little bit of slack at the end that allows the kernel to group wakeup events. You can configure this (for non-RT tasks) with prctl(PR_SET_TIMERSLACK).
https://lxr.linux.no/#linux+v6.7.1/kernel/time/hrtimer.c#L20...
https://www.man7.org/linux/man-pages/man2/PR_SET_TIMERSLACK....
Sorry! I was looking for documentation that on Linux sleep(0) yields.
There is no code in nanosleep that converts it into a yield, and in fact a nanosleep(0) is a nanosleep(50µs) with the default timer slack value. If you want to yield, call sched_yield() …
I looked into this a bit further and it seems to be a range from [0,50]. [1] explains that if there is a pre-existing timer interrupt at 0, then the queue will be resumed at 0. But yes - given no other timers it will resume at 50.
1. https://people.kernel.org/joelfernandes/on-workings-of-hrtim...
It used to be the case that glibc implemented nanosleep for small values below the scheduling quantum with a spin loop. It was explicitly documented to do so.
This was changed sometimes in the last 20 years, probably with battery powered devices becoming more prevalent and CPUs implementing more advanced sleep states.
> never noticed
I'd love to see numbers with a Kill-A-watt between the PC and the wall
Why? Running an empty loop a thousand times a second is literally almost nothing to any cpu released in the past 20yrs at least
Running an empty loop with no sleep or other yield type operation will peg one of your cores if you pin it to that core.
compile that with -O0 and see what happens.When did we say anything about no sleep or yield? That's completely different. Read the thread.
"A thousand times a second" obviously implies sleep or yield unless your computer is old enough to be your grandfather.
For science, literal proving hypotheses science
Whether the CPU is busy because of a loop with a sleep depends on the ration of the sleep time and the time to perform the rest of one loop iteration. Doing stuff in a loop iteration that takes 1min and then adding a ms sleep will not drop CPU usage a measurable amount.
The question is about waiting, i.e. when you have no real work to do. If you have significant work to do then there is no point in sleeping until that work is done.
FYI the code has been updated to use sigwait instead.
This is a sleep which allows the kernel scheduler to move to a new process and not a busy-wait so it will have very very low processor usage.
In Wayland you just start a capture with the xdg-desktop-portal API and it notifies the user and let them select the area to capture.
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.
Wayland is more focused on security. That onion layer right there will increase the complexity of usage. X11 doesn't have the extra abstractions to limit and prevent intrusive interactions with the desktop.
Example of this would be where "runas /user:smith application.exe" is simple but does not work when a Windows Service is required to run an application as the user signed in. One must use Window's API to pull in the account's token and use more API to execute "application.exe". UltraVNC is a great source to see all the extras needed.
From a quick "how do I implement this in Python" with ChatGPT it seems to be about 30 lines, since most of the heavy lifting is done for you by the API.
As someone who uses LLM's regularly to assist in code creation, take that output with a huge grain of salt until you've actually tested it. Especially as it relates to Wayland, I've pulled my hair out trying to get an LLM to assist with very similar tasks to this.
It means you got to tickle the banana, good luck making sure that the gorilla holding it is fine with that.
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].
[1]: https://wayland.app/protocols/cursor-shape-v1#compositor-sup...
I think Wayland had made some mistakes, no doubt. Cursor shape just should've been part of the protocol. Wayland has its fair share of misfires.
That said, I understand what they were going for. They really wanted to make the compositor as small and simple as possible, so for example you would just use libwayland-cursor instead of bothering with cursors yourself. However there are a lot of ways libwayland-cursor worked out poorly... Not everyone agreed on how scaling should work, GTK4 ditched it for performance reasons, and overall it's just inconvenient for a lot of cases (languages other than C, sandboxing, etc.) And to make matters even worse, in practice every compositor needed to load and handle XCursor themes anyways...
That said, I think that it's okay if Wayland doesn't own the majority of the Linux desktop stack the way X11 did. It's fine for compositors and their helpers to implement protocols from other projects, too. That way Wayland can be more applicable to graphical machines other than desktops without bringing unnecessary baggage. It'll always have trade-offs, of course, but I think it's far from the end of the world.
re cursors: There is a replacement/amendment protocol for cursor handling coming though I don't know the current status of it. It seemed a lot easier to work with for the vast majority of cases.
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.
for example. run ./clipscreen 1 2 3 4
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!
To the parent, splitbrain just got you to QA this for him. The true cost of software is the maintenance and QA, and he got you to do free work, and here I am doing free work writing about it. How hard we BOTH just got pwned! </joke>
will work for food
haha yeah, its ok for a tool its really cool honestly :p just commenting on the 'so little code' might be good to check if the x y etc. are within the screen / set resolution perhaps.
Is it much more difficult under Wayland?
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.
Wayland merged the image-capture-source and image-copy-capture protocol extensions earlier this year: https://www.phoronix.com/news/Wayland-Merges-Screen-Capture
> Wayland intentionally makes this more difficult,
some men just want to watch the world burn
And Wayland keeps their apps from spying on the rest of my screen!
I never understood the rationale for Wayland's "security"...
All the programs that I use (ls, rm, vim, ...) can "spy" to each other, and have unrestricted read/write access to all the bytes in my home directory. That's the whole point: I run these programs to control said bytes. What's so special about the pixels of my screen that the programs that manipulate them need to be protected from each other? If anything, the pixels in my screen seem less critical to security that the bytes in my disk. But Wayland insists in making that difficult, for incomprehensible reasons. Those are my pixels and I want to do what I decide, not what Wayland lets me to. I control my programs, not the other way round. If I decide that this program reads one pixel on my whole screen, or the global mouse position, or whatever, I see no point in forbidding me to do it.
Of course, if I want to run some rogue program whose author I don't trust, I will do so inside a limited container. But this has nothing to do with graphical applications. I wouldn't like the rogue program to read my homedir either.
The rationale is that you can have a GUI in one of those limited containers and not spy on all your other windows.
You already can with X11, for example running your rogue graphical program inside a graphical virtual machine. The vm gui will filter-out the events that happen outside the window and the rogue program will think it's running alone.
It's nice that wayland makes such containerization much lighter, at least concerning the GUI (you still need to hide your filesystem, network, etc if you want to run rogue programs under wayland). But I don't see the point in enforcing it for each and every one of your programs. It's extremely unergonomic.
I think the general direction where Wayland, Flatpak and other similar sandbox frameworks are going is that of users running proprietary, untrusted and more or less user-hostile apps on the desktop, just like on tables and smartphones.
I don't run "apps" on my PC. I run programs from a trusted source repository. I expect those programs to not be hindered in their attempts to serve me.
Where does this paranoia come from? The kind of attacks cited by Wayland advocates are all theoretically possible but virtually unheard of in practice. In any time in the past thirty years, has there ever been a case of a rogue program in the Debian repos that maliciously spies on the user by exploiting the open and trusting nature of X11? Even if you expand the scope of consideration to applications like browsers getting pwnd by RCE zero days and then doing this, how often does this actually happen? Maybe this degree of paranoia, fear of technically possible but actually extremely rare scenarios, makes sense for targeted individuals like reporters and whistleblowers operating in totalitarian countries, but for anybody else it seems insane. It's like having deadbolts on your bedroom door because you're afraid of somebody trying to kidnap you in the middle of the night, that extra security against such an unlikely threat isn't worth the inconvenience. Except actually, getting kidnapped in the middle of the night is probably a more common occurrence than getting pwned through X11 programs from your distro repos.
This was in the wrong thread…
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.
Hackable is right. But not always in the positive sense of the word.
I find it very interesting how much our threat model has changed in the last 10-15 years. We no longer trust even local software, as we have to assume everything is now malicious. Commercial software from "reputable" companies can't be trusted to not pull a ton of analytics and personal data off your computer. We now have to worry about every piece of software being a keylogger and spying on other windows/applications and reporting back.
We've had to give up so much flexibility. Wayland certainly focuses on plugging this hole, but it means we've lost all these cool utilities like this one. There was just so much you could do with devilspie, xdotool, and others to make sure my operating system and window environment worked for me.
I still really miss X11's Zaphod mode, where you had two independent X sessions (:0.0 and :0.1) on two different monitors, with different window managers and different windowing rules.
I miss the days of being able to trust my computer and trust my software.
If you can't trust your locally installed software, everything is lost. I understand where this new threat model comes from for some people but I'd rather continue to avoid bad software sources than hamstring my OS in the hopes of avoiding malware I installed on purpose.
I agree. But can you trust Zoom? What about Office or Photoshop? Can you trust Websites or your browser anymore? Even open source apps have analytics in them that may not be trustworthy anymore (firefox, audacity, ...).
I teach online for a living, and -- yep Zoom through FIREFOX only.
Coincidentally, it's also the best experience, for whatever reason it's the only on that supports virtual backgrounds on Linux for me? Neither Chrome nor Desktop seem to work for this.
This is why I don't run Zoom or Office or Photoshop or versions of Firefox or Audacity not distributed by Debian.
Browser sandboxes pretty heavily though of course one does want to be a bit careful there too.
Zoom through a browser only.
As for the rest, they may have "analytics" (spyware) but are there any documented cases of any of them acting as an X11 keyloggers or covertly screenshotting the users desktop? Those are the threats Wayland asks us to fear. And Wayland won't protect us from the rest. If Firefox or Audacity phone home with reports about what I'm doing with those applications, Wayland won't stand in the way.
> If you can't trust your locally installed software, everything is lost.
That's only true if you decide to trust it.
You can deal perfectly well with software you distrust, and not have it harm your system.
Yes. By not running it.
What is interesting is that physical home security has gone in the opposite direction - people are happy to put dozens of devices in they home which can (and some definitely do) stream everything they hear and see to the cloud.
> Commercial software from "reputable" companies can't be trusted to not pull a ton of analytics and personal data off your computer.
Thankfully, for a lot of software, there is no reason to ever give them network access in the first place.
It very much is. I expect programs running on my computer to not be restricted in how they can help me.
FWIW, the threat model you're imagining is an attacker being able to run code to display directly to the desktop using the lowest level native API. A local[1] code exploit at the level of an interactive user is already a huge failure in the modern world.
Is that a reasonable argument against using X11? Sure, for some use cases. Is it a good argument for wayland/windows/OSX/whatever to do your tiling WM experimentation? Not really, those environments kinda suck for playing around with.
[1] Or "local-ish", your system or a trusted remote has to have been compromised already. Untrusted X11 protocol still exists but is deliberately disabled (and often blocked) everywhere. Even ssh won't forward it anymore unless you dig out the option and turn it on manually.
Isn't any app that can access read the x11 socket able to read any input? It's not just running an explicitly malicious app but also the risk of compromising an app which can read the x11 socket (e.g. Firefox)
It's also why there existed more advanced security extensions for X11 (like security labels for windows), but also why even bare-bones X11 had methods to ensure that only one specific application was getting input, specifically to handle secure input like with passwords.
Yes, exactly. I'm just saying that the response to a remote browser exploit in firefox is more likely to be "YIKES ZERO DAY IN FIREFOX!!!!!" and not "well it's a good thing we're running it in windows so it can't screenshot other apps or inject key events".
It's not like it's not a valid argument, just that it's sort of a nitpick. Security is hard, and defense in depth is a thing, but this particular attack surface is way, way back in the "depth" stack for a modern app deployment.
Javascript has managed to even ruin the linux desktop. Running every random JS application sent to your browser VM makes the browser insecure which means the entire computer can't be trusted. This is the reason things like the waylands enforce a smartphone like model of security where the user's applications aren't allowed to communicate or interact with other elements of the graphical desktop. Applications aren't trusted. So the user isn't trusted. A trade-off not worth it.
Huh? What are you trying to say? There's no conflict between distrusting applications and trusting the user. Even on Android (which is pretty paranoid these days), you, the user, can still opt to trust apps with things like accessibility API access and background location.
Why exactly should we perpetuate the insecure old single-privilege-level desktop model?
>Why exactly should we perpetuate the insecure old single-privilege-level desktop model?
Because after 10 years of heavy development none of the waylands have managed support simple things like screen readers. X11 supports screen readers and innumberable other vital accessibility features that wayland never will be able to. Some waylands might eventually develop extensions for their particular desktop but there won't ever be a way for wayland protocol because it can't. Security theater is more important than accessibility/usability for wayland that leaves many use cases and entire demographics of people out in the cold.
So yes, X11, which is still the least worst option. Better to have the ability to do all things than have to wait decades+ for developers to write complex extensions to do things (and just for their DE, causing fragmentation).
The most hackable would have been a Lisp based desktop.
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 is simple because it shoves all the responsibilities to somewhere else.
By window manager started out as ~50 lines of Ruby copying an equivalent amount of C.
You can say many things about Wayland, but it's "simple" from a point of view I for one really do not care about. Wayland may be "simple" in some respects, but it makes most of the things I care about doing unnecessarily complex.
Walyand probably would have been better if wlroots had been developed as a (whatever this means) first-party “built-in” library.
Even then, "tinywl" which aims to be a "minimum viable product" Wayland compositor based on wlroots is almost 1k lines:
https://github.com/swaywm/wlroots/tree/master/tinywl
Lacking features isn't the same thing as "simpler", Wayland is great, but is very much a subset of the features implemented on an X11 desktop. Wayland doesn't do selections or provide any IPC mechanism of its own, much less something like an ICCCM that allows you to identify/target other users of the desktop and interact with them in a flexible way. In fact as I understand it the linked tool is in fact impossible to write in Wayland.
Again, this isn't the fault of "Wayland", which is just a compositor framework. The complaint is that the ecosystem of "desktop" software which evolved around Wayland is an ad hoc monstrosity that lacks the unified structure that its ancestor had way back in the X11R5 days.
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.
How do people discover these things?
Isn't that the same of how you select multiple files in most file managers?
Shift+Click: select from currently selected item to clicked item
Ctrl+Click: add/remove clicked item to set of selected items
Sure, but the idea you can share multiple windows this way.
Can Google Meet (or hangout or w/e they call it now adays) do some of this?
Reading documentation, usually: Sharing your desktop, screen, or content in https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_arti...
More useful shortcuts in https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_arti...
The same question I asked (that was me after using Zoom for 3+ years).
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.
https://github.com/BlankSourceCode/obs-zoom-to-mouse
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.
You probably can. I never used OBS, but it's probably a bit more than a 20kb binary though ;-)
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.
I'm not aware of company issued computer with x11. Is it really a thing ?
Some companies let you run Linux on their company issued computer.
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.
OBS lets you share a window or just the client area of an app.
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.
A lot more work involved, though.
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.
You can do this with xzoom, which also allows magnification from x1 upwards - is there an advantage I'm missing here?
Wow, this is fantastic! This exact use case, on Linux, is why our company selected Zoom instead of Meet.
Awesome!
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.
Wow that is also very cool. For those wondering, this is what it looks like:
Putting the two together is easy too:
$ clipscreen $(slop -F "%x %y %w %h")
NB. The lack of quotes around $() enables wordsplitting to occur.
I think you got the size and position switched.
Or
$ clipscreen $(slop | tr -s "+x" " ")
this is just cmd+shift+5 in a Mac OS
Is it? I thought that took a screenshot, not fed coordinates to a program (in this case a screen sharing program)
Did you have any issues implementing?
Can someone explain why this is still an unmet need within the current video conference platforms? Giant monitors have become increasingly common-especially for the developers who might be working on these tools.
Maybe because a workaround with OBS isn't that difficult?
You might have missed the point being made here.
We, as engineers, can't expect everyone to know what OBS is, download it, learn in, and use it every day to enable their ability to share a sub-section of their monitor (regardless of its size.)
We, as engineers, _are_ expected to make our software easier to use and feature rich. Adding this capability into Zoom or Meet, etc. is a reasonable thing to expect from a software company of note. And people _do_ know what Zoom and Meet are, download them, learn them, and use them every day. Why not implement the feature directly into the software they're already using?
Also which percentage of people taking part in meetings with screen sharing are even allowed to "just install" OBS? More for developers, much less for other office workers.
You can literally do this with just xrandr.
xrandr --setmonitor screenshare 2560/1x1440/1+0+0 none
To make the selection interactive, the command becomes:
geo=$(slop -f '%w/1x%h/1+%x+%y') && xrandr --setmonitor screenshare "$geo" none
Also looks like one can just do
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.
In fairness; that and the overlay is what is happening, just from C++. Props for nice oneliner none the less. :)
Nice. This is the first time I read about creating a virtual monitor in X.
This is brilliant. I've wanted this so many times and had to awkwardly switch between window being shared instead.
I wouldn't mind switching between windows if I could use the GNOME Activities overview for that. But maybe that is not possible because there is no way to communicate the change in stream size if the windows have different sizes?
This is surely useful right now. I wonder what will happens to all the nice X11 tools once Wayland (hopefully soon) will be the golden standard. There are options to enable X11 behaviors in Wayland but I guess that is just a fallback to the insecure implementation.
I've looking for something like this for quite sometime. It's simple, clean and elegant.
This is only helpful if you are using a desktop environment. What about window managers like i3?
I'm not sure about i3 but you can have floating windows in DWM and move them to the targeted area with the mouse
I've always wanted something like this, but for i3 workspaces. Something like "share workspace 2." Anyone know how to accomplish this?
That only works if the workspace is on an actual screen, because it's otherwise not rendered. Maybe the virtual monitor solution via xrandr would work for that, but I haven't yet tried that.
I was just about to go looking for something like this! I'll look so pro on the meeting tomorrow :)
Dang. I need this for Mac. I’ve been wishing I had exactly this for years.
Wasn't the same thing posted for MacOS a few days back, can't recall the name? Looking at the time on the repo makes me think the author pushed after seeing people requesting something similar for Linux.
edit: Here you go https://github.com/Stengo/DeskPad
DeskPad was discussed there: https://news.ycombinator.com/item?id=41800602 And for Windows there is RegionToShare https://github.com/tom-englert/RegionToShare
That's not quite the same. With DeskPad you have to move the window to the virtual monitor. clipscreen allows you to select a portion of your screen without moving any windows.
I use "Advanced Screen Share" for this purpose. it has a one time purchase if you want to remove a small overlay but it gets the job done and is installable through the app store.
you can just share multiple windows on the newest macOS and they will ne nicely arranged for viewers. You can even add the presenter thing to show your face next to them.
I'm waiting for ffmpeg to implement pipewire screen grab so it could work on Wayland.
Can you not use std::condition_variable to avoid the active waiting of the signal?
I don't know if std::condition_variable is async-signal safe, but an easy fix is to replace the sleeping with pause(2). There's also sigwait(3), which wouldn't need a signal handler.
signalfd or ppoll or a million other options
Neat. Now I want for Wayland. Don’t use X11 for some years.
Never to late to upgrade to X11 :)
That s very cool... Speaking of which: any easy way to allow two people, both on X, to both share and interact (keyboard and mouse) with a common X window?
The app that we d like to share and both control is a browser (running on a machine on our LAN) so a browser extension would work too I guess.
I think there was some way to do that with existing tools. I forget the details because I only threw it together as a bit of fun novelty. I think the terms to google are x2x and multiseat though, at least to start your search…
My preferred solution for that would be a VNC server (so that it shares the whole screen) installed in a VM.
[flagged]
As per the blog post, only Zoom allows to stream a selected area of the screen. What other proprietary SW can do this?
With this tool, they should all be able to
I'm not sure what you are referring to. What's the proprietary solution you're suggesting here?
OBS has had the ability to do this for quite some time
[flagged]