But at the same time I find it a bit sad example of how much effort to and how much corner case fiddling such conceptually very simple tasks have to take.
Caricatyring here, but it is essentially just blitting pixels over a network connection. I don't think it should be that hard a task with a more reasonable underlying stack. Plan 9 (and probably many other sadly forgotten systems) showed how something like scrcpy can fall out more or less automatically from a better designed system.
Maybe I'm underestimating some fundamental complications, but I can't help but feel something has gone very wrong with how we do things with computers. Maybe something like worse is better on piles of previous worse is better.
- 4 bytes a pixel = 2073600 * 4 = 8294400 = 8.2 MB / frame.
- 8.2 MB frame * 60 fps = 480 MB/sec = 3.2 gbps = an order of magnitude higher than even your average techie's internet entire pipe. That's for 1080p. The market baseline for resolution, 4K, 4x's that. 240 fps (market baseline for gamers) adds another 4x. ~50 gbps
As long as you're willing to accept intellectually that _sometimes_ there will be video-like content played, where more than 10% of the pixels change in a frame, you now _need_ to assume some form of compression algorithm is applied on every frame, i.e. do video encoding.
Scrcpy is different because it does not require you to.install anything on the phone. It uses the built-in debugging tools (which you need to just activate in a few clicks).
But the scrcpy code is not about this, it's all hidden behind the libraries and in the hardware. What scrcpy has to do is micromanage and hack the APIs on the both sides for this all to happen in the guts of the systema.
I don't see a reason why all this couldn't be done with something like /dev/remote/window < /dev/screen
Of course there would be a lot of magic happening at the implementation level, but it's not like you type in all the HTTP protocol and negotiate the compression algorithm manually when you go to a website.
The (old!) Apple iPad cable runs BSD Unix and does real time video encoding.
The PC side isn't complex either. You take those packets from the phone, run it through a decoder that draws the frames to a texture which you can show in a window.
Edit: I have a OnePlus nord n30 5G that released with Android 13. Is it eligible for this feature? Iirc OnePlus said it will only give this budget phone one (1) version upgrade so wondering if a December feature drop counts as a second upgrade… :(
Maybe won’t even matter if this requires specialized hardware :(
Make of that what you will.
I dropped my phone and the screen broke. The touchscreen worked, but no backlight.
Luckily I had enabled Android debugging. It took a bit of trial and error but I managed to unlock the phone and then accept the adb key from my laptop.
After that, scrcpy let me grab all my files and transfer everything to my new phone.
If you have an android device take a few minutes to get scrcpy set up. It just might let you recover from a dead screen some day.
In your case where the backlight dies it often helps to shine a flashlight on the screen and it will usually become more intelligible.
One thing to keep in mind is that android will revoke saved debug-computers after 7 days or something meaning you have to press a popup to accept the connection. You can turn that off in the developer options and then you won't need any interactions on the device to start scrcpy (as longs as it is a computer you've used before with adb).
I also have kdeconnect installed on everything, but android will remove its permissions if I don't use it often enough.
Kde connect is also great! You can prevent Android from revoking permissions under the app info menu. It's labeled as "pause app activity if unused."
1 - https://f-droid.org/en/packages/com.dozingcatsoftware.vector...
