Should the patch be backported to 5.13 since it's a fix for the daemon according to the description?

I guess so.

This doesn't seem to be in Plasma/5.13.

This patch seems to have broken things ("kcm does not load") by what people reported in irc for 5.13.1.

By a quick investigation the main reason is, that the old plugin binary with the name "kded_touchpad" is used both to provide the plugin for kcm as well as the plugin for the kded.
See how both plugins had been registered for the TouchpadPluginFactory in the removed file plugins.cpp, with two plugin metadata desktop files referencing the very plugin "kded_touchpad" to find their repective plugin (the second via the "kcm" id): kcm_touchpad.desktop and kded_touchpad.desktop

By turning the actual plugin into the new-style "embedded json in custom path" type plugin, the plugin metadata for the kcm plugin is now pointing into the void, as both the name is now wrong as well is the plugin no longer in the common plugin dir, but in a subdir (not sure if kcm plugins are searched also in subdirs). In any case, the kcm plugin is no longer registered now in a factory, so even if the plugin was found, there is no kcm to load.

No idea where the actual bug this patch was supposed to fix is coming from, but it has broken things in a different way :)

One solution might be to properly split the current single plugin binary into 2 separate plugin binaries, one per kcm and one per kded plugin, and add a shared private lib for the stuff they might share.

Given the D-Bus object path for the module is generated from the moduleid, which is set by kded using the KPluginMetaData::pluginId (in KDEDModule *Kded::loadModule(const KPluginMetaData &module, bool onDemand), a fix might have been instead to set in the kded_touchpad.desktop file this entry: X-KDE-PluginInfo-Name=touchpad

Apologies for the unforeseen trouble. I'll revert the committed change for now, and then investigate the fix that @kossebau suggests in the previous comment. If this doesn't work then I'll look into splitting the kded and kcm modules into separate ones with a common library.

Regression has been reported as bug 395622. Please close when fixed.

In D13360#280205, @marten wrote:

Apologies for the unforeseen trouble.

Happens also to the best now and then, and only to get better the next time :)

I'll revert the committed change for now, and then investigate the fix that @kossebau suggests in the previous comment.

Given the commits seems that worked out? Good, so I did not misread the kded code.

In the meantime I had tried to investigate where the X-KDE-DBus-ModuleName had been introduced in kdelibs/kde frameworks history and where/why it faded again, but so far have not found it being used at kded core at any time, only found traces in outer code spheres.

So am going to create some patches to wipe out the last traces of that key from other KDE code, everything I saw should work good enough using the plugin id, either derived from binary name or set by metadata (X-KDE-PluginInfo-Name with desktop file and KPlugin/Id with JSON). So in the future no-one can be confused by that non-working key anymore.

I didn't fully follow this saga, but AFAICS this patch was reverted (commit 3432c3342b1f801, bug 395622), so we still rely on desktop files to load the touchpad kded module. Can this patch be applied again now that commit f040cdb399b (X-KDE-PluginInfo-Name=touchpad) is in, or is something else missing?