Plasma 5.13 release
Feb 19 2019
<Sho_> bshah: since there's no takers, i suggest you commandeer the revisions and finish them to the comments
<bshah> Okay, cool
Aug 3 2018
Jul 16 2018
Jul 10 2018
Jun 12 2018
Congrats on the great video, and thank you for your hard work!
Jun 1 2018
Thank you so much Lucas!
May 28 2018
So I made a few screen recordings, which include:
May 22 2018
Apr 25 2018
Unlikely, Gnome's shell runs in-process with the compositor, they don't need any IPC for the same use case.
afaik gnome already has this, do they have some sort of protocol there?
Apr 24 2018
mart/plasmavirtualdesktop branch on kwayland, i started the xml file for it, I'm trying to document it as well, to see if i'm getting the protocol right
Apr 21 2018
Apr 13 2018
Apr 12 2018
After much research my current plan looks like this:
Apr 9 2018
Apr 3 2018
Mar 26 2018
As I mentioned to @Kanedias on IRC, there is also remote desktop portal which I proposed as a GSoC task, see https://community.kde.org/GSoC/2018/Ideas#Project:_Remote_desktop_portal.
Mar 25 2018
I use a 33 point custom curve loaded via XF86VidModeSetGammaRamp, not a single value. Today's displays need some 'S' shaped curve, but unfortunately needs fine tuning for each display.
Hard requirements have been met by the two patches. Soft requirement was dropped, something to look into in the future.
Can the remote access protocol be extended in this way? It would make sense by its name to facilitate remote input support here as well.
This finally is ready to proceed, thanks everybody. D10965 to go. I'll begin working on KRfb integration with pipewire stream this week.
We should think about input support as now remote sessions are limited to view-only.
Mar 24 2018
Mar 20 2018
Xdg-desktop-portal-kde does it on its own, same way like kwrr (I actually took that part from kwrr).
Thanks for the answers. Sounds fine to me. Not sure if we only want to support the portals stuff and by that indirectly make it a standard in a broader sense, but if it works fine for everybody and there are no other solutions available, I'm certainly not against it.
Mar 19 2018
Mar 18 2018
Mar 13 2018
Mar 7 2018
So for an overview we now have:
Mar 3 2018
Feb 28 2018
Feb 27 2018
I think I know what's the problem with delete output. In KWayland in output.cpp: WaylandPointer<wl_output, wl_output_destroy> output. While this is technically correct it shouldn't destroy output right away.
It should call wl_output_release that will notify destruction to the server so it will know this client has no more bound outputs and RemoteAccess interface and stop sending buffers.