Minimal VNC server implementation

[DavidVentura]

Fixes #3473.
I wanted to have a direct VNC server sharing my scrcpy screen -- this is a work in progress towards that.

Code-quality wise it's pretty bad; a lot of copy-pasting the screen/display and just chucked the example libvnc eventloop thread, but it does function!

[rom1v]

Thank you for the prototype 👍 It's interesting. I keep it in some branch for now.

I'm not sure whether I want to add a VNC server directly in scrcpy (it is a "side" feature, and it typically does not provide the same performances).

I think it might require scrcpy to be a bit more "modular", so that we can compile independent "plugins" (I'm not very happy with the V4L2 sink and its bunch of ifdefs too). But on the other side, I don't want it to be as modular as VLC for example (this would require too much decoupling which add many constraints, that in practice prevent to implement some "simple" features because the abstractions need to be "too general"). An alternative would be to expose a libscrcpy and use this to create a VNC server binary.

These are just random thoughts, I keep the feature/need in mind. Thank you.

[rp1231]

This seems interesting.
But what does this pr exactly allow you to do?
I tried googling a little bit about vnc servers and understood that it was something about screen sharing......
Thanks

[DavidVentura]

@rp1231 a VNC server is an implementation of the "remote-framebuffer" protocol, in this case, it allows you to display and interact with the android device from another computer, not necessarily the one that's running scrcpy (and not the one where the device is plugged in).

@rom1v it's not the same performance, but it is pretty good, it feels "the same" when using a device for general purposes (did not try games / video).
It could be made more efficient in certain scenarios; as I didn't figure out a way to detect the "damage" in the video frames, every time something changes, the entire framebuffer is sent.

A libscrcpy would be pretty cool, and yeah, I did feel adding more ifdefs isn't really great. I'll think a bit for a way to refactor these.
I'm fine keeping the PR open - I have my own build so I'm covered

[rp1231]

@DavidVentura
Thanks for the explanation.
What use case do you use this for?
Especially in the case for scrcpy.

Also sorry for clogging up the pr thread with questions......

[DavidVentura]

@rp1231 I have a device that I need to access sporadically. I've left it connected to my server and can use VNC to access / interact with it via my laptop.

[rp1231]

@DavidVentura Ah ok, I see.
Thanks

[DavidVentura]

@rom1v I had something like this in mind
https://github.com/DavidVentura/scrcpy/pull/1/files
which can be extended to cover also V4L2 -- mostly it moves all the ifdef'd state into a plugin, which bypasses most of the ifdefs by having the plugin-specific data as an opaque void*

[mudebug77]

Thank you for sharing, this is a great suggestion. With VNC, it can be better expanded.