RealVNC Remote Desktop Wants To Support Wayland

[Ancurio]

You have no guarantee other compositors will handle it that way (I know it's most likely, but not guaranteed), and those are the ones likely to show real world usage.

Well, those compositors would just always give the entire screen rect as damage. It would still work (albeit slow as hell). I think something like damage tracking could just be made mandatory to the extension.

No, the screen recording functionality would be in the client, which requests the full composited buffer from the compositor, via an interface defined in the protocol. So it would be up to the compostitor to decide which clients are allowed to access the compositor in this way and how that is configured.

Hm okay, so we are talking about the same thing after all. I just got really confused when you started out saying "I think it'd be easiest to just implement it in the compositor." even though I was talking about the exact same concept.

Yes, it makes sense. Because compositors may use different assumptions.
"One size will fit all" is not the best programming paradigm ever. Actually, it's specifically because X suffered from this problem that we are changing to wayland. Wayland enforces as little as possible.
Some libs are provided, though, and you can write extensions to the protocol. Extensions that any compositor may, or may not support. Or may support with some other lib.

Do you know what the word "interface" as a software term means? It is a way for two or more software components to talk to each other without knowing about their inner workings. It is the reason a GTK app can run under almost any X11 WM. Now, tell me, assuming there is a simple extension defined which says:
"I as the compositor will provide you with either the screen buffer, or a client's buffer at your choice, preferably as a resource bindable as a GL texture, but SHM buffers are fine too".
What kind of "assumptions" of different compositors would make this troublesome? Either you can provide the above requirements, or you can't. That's it.
Oh, and I also wonder what kind of conditions would encourage developers to port/write their software for wayland. "Write one backend that works with all compositors exposing that interface" vs "first split my entire codebase into a library, then write 20 backends for each compositor out there". Hmmm..

[daniels]

Anything done in Mir can't (because of GPLv3) be directly integrated into Wayland. Also, if I understand correctly what the GPLv3 means, some algorithms might be patented and only usable if taking the code from the GPLv3 implementation, which means it can't even be reimplemented locally on Wayland, because it uses a different license. Features on Wayland going into Mir, well, they can copy whatever they want, the license allows them. I ignore if it's technically feasible, and it probably would take some work to port anyway. But if it's this way, then I hope Mir fans don't complain when someone points out Canonical is leeching from a project they did spread pretty harsh comments about.

funny how mark complains about wayland, accusing intel of paying collabora to keep code proprietary in order to deliberately sabotage mir (which, fwiw, is total total rubbish and 100% unfounded), but he doesn't seem to have any problem with mir depending on xkbcommon, which i wrote at collabora for intel. with neither an apology for the former, nor a thanks for the latter. oh well.