[Kde-hardware-devel] Review Request 126101: allow loading backends in-process

[Sebastian Kügler]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126101/
-----------------------------------------------------------

(Updated Nov. 20, 2015, 12:16 a.m.)


Review request for Plasma, Solid, Àlex Fiestas, Aleix Pol Gonzalez, Daniel Vrátil, and Martin Gräßlin.


Changes
-------

Thanks for reviewing again, latest changes address the remaining comments.

Most interesting change is that the plugin loading argument has moved from ConfigOperation into BackendManager, as suggested.

The code is now a bit more agressive towards switching backends, shutdownBackend is run whenever the mode or the backend changes. I've added there that in case we get a new backend requested, and the new backend would be loaded while the old isn't shut down, we run shutdownBackend() anyway. We know it's the right thing to do here, so instead of warning, or bailing out, we shutdown first, and then continue loading the new backend freshly.

make test passes entirely, though I get dbus timeouts in testconfigmonitor when running it directly from the commandline. It may (or may not) be related to the backendlauncher not shutting down correctly, but I haven't figured out if that's a new problem, or specific to a certain setup. I'll give this another good round of real world testing before pushing.


Repository: libkscreen


Description (updated)
-------

This patchset adds in-process operation to libkscreen

purpose:
- allow easier debugging
- for some backends (qscreen, upcoming kwayland) the out of process operation is not necessary since these backends are well-shielded

This implementation is backwards compatible and opt-in for running setups.

If the user exports KSCREEN_BACKEND_INPROCESS=1 before running, all operations will be done in process. Otherwise, the out-of-process mode is used.

Changes revolve around the ConfigOperations, the BackendManager (which "factories" the backends, either in- or out-of-process), and the plugin loading logic

Autotests should cover all the cases (and actually a few currently unsupported ones, such as using different backends in the same process).

Details on performance, etc.: http://vizzzion.org/blog/2015/11/wayland-and-libkscreen-benchmarks/


Diffs (updated)
-----

  CMakeLists.txt 86a0965 
  autotests/CMakeLists.txt 69af7f0 
  autotests/testconfigmonitor.cpp a051226 
  autotests/testinprocess.cpp PRE-CREATION 
  autotests/testqscreenbackend.cpp da4dbae 
  autotests/testscreenconfig.cpp ecbcedf 
  autotests/testxrandr.cpp b9b838a 
  backends/fake/fake.cpp 60264dd 
  src/backendlauncher/backendloader.cpp 52051df 
  src/backendmanager.cpp ca9c746 
  src/backendmanager_p.h c6418e2 
  src/config.cpp 75d947d 
  src/configmonitor.h b6f1189 
  src/configmonitor.cpp a14bc70 
  src/configoperation.h 2405d79 
  src/configoperation.cpp 87fe141 
  src/configoperation_p.h afdc462 
  src/getconfigoperation.h c85bfaa 
  src/getconfigoperation.cpp 22f92b4 
  src/output.cpp bd381fa 
  src/setconfigoperation.h 020a990 
  src/setconfigoperation.cpp 6ea944f 

Diff: https://git.reviewboard.kde.org/r/126101/diff/


Testing
-------

Added a ton of autotests, made sure all existing ones pass.

tried "KSCREEN_BACKEND_INPROCESS=1 kcmshell5 kscreen", all working as expected.


Thanks,

Sebastian Kügler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20151120/843506d9/attachment.html>