Provide list of currently running screencopy sessions

[tbe]

While currently, it is possible to fetch screencopy events (session started, session ended) via IPC Sockets, there is no information about already started sessions.

Tools that, for example, disable notifications, or show an icon if we have an active screencopy would need the information about already running sessions at startup.

[tbe]

Completely forget to mention it, i am willing to contribute.

[vaxerski]

thats true, shouldnt be hard to do with hyprctl. MRs welcome

[tbe]

Great!

The most logical point to get this information is CScreencopyProtocol::m_clients.

As this is a private member, i see two roads ahead:

a) Make CHyprCtl a friend of CScreencopyProtocol
b) provide a function in the interface of CScreencopyProtocol to get this information

My personal preference would be b.

[vaxerski]

of course B, but its not that simple, as for example xdph will always be a "client", but it doesn't always screenshare. The correct way is to note the frames copied and use heuristics to guess when a session is active (e.g. >5 frames copied in the last 2s)

[tbe]

As the tick handler already updates CScreencopyClient::m_sentScreencast, i would simply use this existing flag.

My bigger concern is, that the vector, holding the client pointers, is change while we read it. So, maybe i have to add some locking here.

[tbe]

I had a deeper look at the code today, and currently there are multiple operations done on std::vector members of the CScreencopyProtocol. Those are scattered over multiple classes and functions, and can be (at least to my understanding) executed from multiple threads. Those functions include vector manipulations like emplace_back and erase_if. None of those operations is guarded with a lock.

While i could just add a function here in the same style to get the currently active screencopy clients, invocation of this function will be via HyprCtl, and may occur at any time, leading to the risk of race conditions.

Instead of focusing on my initial feature request, i am currently considering reworking the Screencopy implementation in general, removing the risks of race conditions, and adding more information to the Client objects, like wayland client informations / PID. This would allow to get further informations like, who is recording the screen currently. Of course, everything via XDPH will not be identifiable (without modifications there at least), but it should still be a major improvement to the current state.

But also, i am new to this project, i may miss something, and locking is just not required for example.

@vaxerski any strong opinions?

[vaxerski]

hyprland is single threaded

[tbe]

Oh, i see. I just did a quick scan and discovered <thread> and <mutex> includes in the EventLoopManager.hpp and other locations. Sorry for that.

This is a little bit of offtopic, but do you mind if i create a cleanup MR, that removes the unused imports? There are quiet a few of them i fear.

[vaxerski]

feel free