I believe we don't call the XcbAtom::intern function in the X libinput backend, what we do in the evdev/synaptics constructor part. Question is if we just don't want to not send the relevant call on keypress after all in X libinput. Because libinput does the disable-on-keyboard thing internally and we don't need to send anything like we did before.

by kded on key press other than Kded Keyboard shortcuts

Do you mean it's sent on shortcut or not? Just wondering why I couldn't replicate the issue in my testing.

In D21278#466801, @davidedmundson wrote:

m_connection seems to be having null or 0x0 value.

Which means we're calling XcbAtom::atom after being constructed from the default constructor not the proper one.

That doesn't sound right. If you can explain why we end up in this situation and it's legit, I'll accept, otherwise it looks like we're just treating a symptom.

As Roman pointed out, X Libinput backend do not call XcbAtom::intern for m_touchpadOffAtom. Rightly said we're just treating a symptom.

In D21278#466804, @romangg wrote:

by kded on key press other than Kded Keyboard shortcuts

Do you mean it's sent on shortcut or not? Just wondering why I couldn't replicate the issue in my testing.

kded5 did not crash until I pressed some key which is not Kded Keyboard shortcuts. Like Ctrl+Alt+T did not crash it, but just pressing any other key crashed it.
Sending patch for it in a while.

Codewise looks fine. Good adaption in comparison to first revision! Question remains if we want to further disconnect/deactivate the applet functionality in case libinput is used. We don't need to watch the keyboard presses at all. Same holds for the Wayland case, where we wouldn't even need the kcminit at all (T6084).

Anyways, we can do small steps. This looks good already. Let's wait for some feedback from bug report and I would be happy with current revision.