I’ve been using both KDEconnect and Scrcpy for a long time now, and it would be really nice to integrate both tools.
So, recently apple announced that in MacOS sequoia there will be a function to stream and use iphone on Mac wirelessly, and basically it’s everything that scrpcy does, but in an easy and clean way.
Unfortunately, in order for scrcpy to work wirelessly, we need to know the IP address of the phone, and this is not always trivial if the phone is sitting away, especially if we plan to use it within different networks.
KDEconnect integration would simplify this in two ways:
- a button to launch scrcpy right on the menu, instead of going through the terminal
- provide the IP (that is known to KDEconnect) to the script in order to simplify the process
I think KDEconnect would benefit from this as well, by being more appealing to the end user, especially right now since the hype created by apple.
The connection script is very easy, and there are instructions for the setup on the scrcpy wiki, but unfortunately right now i don’t have much time to work on a merge request 
1 Like
I think one issue is that scrcpy has a dizzying array of options, and it lacks any sort of user interface to control them. It’s configured entirely through command-line parameters (and/or perhaps a config file? I’m not even sure). Which makes KDEConnect acting as a launcher for it a difficult prospect. Either it has to support all of those options, or ScrCpy still needs to be hand-configured by the user in advance, so that KDEConnect can launch it “blind”, effectively. (In terms of knowing whether a ScrCpy session is (a) possible, and then (b) is up and working successfully after launch.)
And the thing is… realistically, ScrCpy is hard to use. It’s not necessarily hard to just get a remote mirror of a device up and running. (Though I’ve had bad luck using it over TCP, as opposed to USB which is much easier.) But to even reach “I see my device screen!” when using TCP can involve a lot of fiddly troubleshooting, and often requires a deeper understanding of that dizzying array of options. Particularly if you want to make full use of all of its features.
I think it’s a great tool, no question, and it does really impressive things. But it suffers a lot (IMHO) from not having any sort of local UI of its own beyond the mirroring window that pops up for the remote device.
The best thing that could happen to the ScrCpy project would be for someone to create a friendly config/control/management tool — with complete local GUI — in the basic model of, say, Remmina. If that existed, it would probably make more sense to flip things around, and instead teach that tool to talk to KDEConnect.
Imagine a ScrCpy-manager tool that, to augment its local configuration, had the ability to query KDEConnect for paired device IPs to display in its device manager. (Something it could easily do, via KDEConnect’s D-Bus interface.)
As-is, ScrCpy doesn’t feel like a great fit for KDEConnect — to me, and this is of course all IMHO — particularly because it wouldn’t even be involved in the actual ScrCpy session at ALL. Its whole job would be passing an IP to a script. Unless I’m mistaken, that would make a ScrCpy plugin the first and only KDEConnect plugin that has no interaction with the remote device whatsoever.
There’s a project called scrcpygui, which can be added as dependency ig and make it talk via KDE connect. Or just integrate KDE connect directly with custom options for scrcpy. Anyway it’ll be a great integration and bridge between using PC and mobile 
1 Like
There is, but that project was abandoned two years ago and has received no further development.
It seems to be the one people still gravitate towards, though.
There’s also at least scrcpy-plus which has a very… enthusiastic developer, based on their reddit posts about it, but I don’t have much insight into its quality/utility. It appears to be Electron-based (but then again so are plenty of other applications these days) and written in Vue.
1 Like