Auf Mastodon ansehen
qdbus / qdbus6
Der "Zauber" passiert mittels qdbus bzw. qdbus6, mit dem man unter KDE verschiedenste Dinge tun kann. Alles nicht auf den ersten Blick klar, aber wir brauchen hier nur wenig davon.
Bei mir in Solus heißt der Befehl qdbus6 in Abgrenzung zur qt5-Variante qdbus(5). Unter Debian ist es wohl qdbus (ohne 6). Das müsst ihr entsprechend eurer Distribution anpassen.
Liste an Geräten abrufen
Folgender Befehl ruft eine Liste an allen vorhandenen Geräten ab, über die KDE Kenntnis hat.
qdbus org.kde.KWin /org/kde/KWin/InputDevice org.freedesktop.DBus.Properties.Get org.kde.KWin.InputDeviceManager devicesSysNamesErklärung:
- org.kde.KWin - wir möchten mit KWin, dem KDE Window Manager bzw. Wayland Compositor reden.
- /org/kde/KWin/InputDevice - wir suchen darin alle Eingabegeräte.
- org.freedesktop.DBus.Properties.Get - wichtig ist das "Get", d.h. wir holen uns Informationen.
- org.kde.KWin.InputDeviceManager devicesSysNames - das ist eine nur-lesbare Liste an Strings:
property read QStringList org.kde.KWin.InputDeviceManager.devicesSysNamesEs kann sich lohnen, Teile des Befehls mal weg zu lassen und zu schauen, was alles angeboten wird, wenn ihr mal schauen wollt.
Damit bekommen wir eine Liste an Events, die uns aber noch nichts sagen:
event4
event0
event1
...Wir müssen schon wissen, was die einzelnen Geräte sind. Touchpad? Tastatur? Touchscreen? Wir fragen das also ab. Für das event0 sieht das so aus:
qdbus org.kde.KWin /org/kde/KWin/InputDevice/event0 org.freedesktop.DBus.Properties.Get org.kde.KWin.InputDevice nameErklärung
- org.kde.KWin - wir reden wieder mit KWin.
- /org/kde/KWin/InputDevice/event0 - Abfrage geht an das Objekt event0.
- org.freedesktop.DBus.Properties.Get - Wir holen wieder einen Wert.
- org.kde.KWin.InputDevice name - Wir fragen den Namen des Eingabegeräts ab.
Das Ergebnis sieht dann (bei mir) so aus:
~$ qdbus org.kde.KWin /org/kde/KWin/InputDevice/event0 org.freedesktop.DBus.Properties.Get org.kde.KWin.InputDevice name
Lid SwitchAha, das ist also der "Deckel" des Laptops.
In einem Skript kann man das zusammensetzen, sodass für jedes Eingabegerät in einer Liste der jeweilige "Name" also Funktion ausgegeben wird. Das ist original von Amine Hassane und tut noch mehr. Ich habe es hier gekürzt auf das, was uns interessiert. Das Gesamt-Skript findet ihr in den Quellen.
#!/usr/bin/env bash
SERVICE="org.kde.KWin"
DBUS_PATH="/org/kde/KWin/InputDevice"
INTERFACE="org.kde.KWin.InputDevice"
METHOD_GET="org.freedesktop.DBus.Properties.Get"
find_devices() {
local DM_INTERFACE="org.kde.KWin.InputDeviceManager"
local DM_PROPERTY="devicesSysNames"
for sysname in $(qdbus "$SERVICE" "$DBUS_PATH" "$METHOD_GET" "$DM_INTERFACE" "$DM_PROPERTY" | sort); do
name=$(qdbus "$SERVICE" "${DBUS_PATH}/${sysname}" "$METHOD_GET" "$INTERFACE" name)
echo -e "$sysname \t $name"
done
}
find_devices
Bei mir sieht das Ergebnis so aus:
event0 Lid Switch
event1 Power Button
event2 Sleep Button
event3 AT Translated Set 2 keyboard
event4 Video Bus
event5 XXXX0000:05 0911:5288 Touchpad
event6 Intel HID events
event7 Intel HID 5 button array
event8 Goodix Capacitive TouchScreenSpannend sind für ich die Tastatur event3 und das Touchpad event5.
(De-)Aktivieren von events
Über qdbus kann ich einzelne Eingabegeräte aus- bzw. einschalten, wenn ich die Events kenne. Das sieht für das event3 so aus:
/usr/bin/qdbus org.kde.KWin /org/kde/KWin/InputDevice/event3 org.freedesktop.DBus.Properties.Set org.kde.KWin.InputDevice enabled falseErklärung:
- org.kde.KWin - Wiedermals reden wir mit KWin.
- /org/kde/KWin/InputDevice/event3 - Wir sprechen das Objekt event3 an. Nach Liste oben ist das bei mir die Tastatur.
- org.freedesktop.DBus.Properties.Set - Wir wollen einen Wert setzen. Bisher haben wir ja nur welche eingeholt.
- org.kde.KWin.InputDevice enabled false - Es geht um das Eingabegerät, wobei wir den Wert der Variable "enabled" mit false (oder true) setzen wollen.
Skript zum (De-)Aktivieren
#!/usr/bin/bash
SERVICE="org.kde.KWin"
DBUS_PATH="/org/kde/KWin/InputDevice"
INTERFACE="org.kde.KWin.InputDevice"
METHOD_GET="org.freedesktop.DBus.Properties.Get"
METHOD_SET="org.freedesktop.DBus.Properties.Set"
PROPERTY="enabled"
DBUS="/usr/bin/qdbus"
# Liste an Geräten:
devices=(3 5)
for device in "${devices[@]}"; do
# Pfad zum Gerät:
PATH="${DBUS_PATH}/event$device"
# Hole Zustand des Geräts (false oder true)
status=$($DBUS "$SERVICE" "$PATH" "$METHOD_GET" "$INTERFACE" "$PROPERTY")
# Wechsele den Zustand, außer es wird "enable" als Argument mitgegeben, sodass dann immer aktiviert wird.
if [ "$1" = "enable" ]; then
status=true
else
status=$([[ "$status" == "false" ]] && echo true || echo false)
fi
# Neuen Zustand setzen:
$DBUS "$SERVICE" "$PATH" "$METHOD_SET" "$INTERFACE" "$PROPERTY" "$status"
done
Dieses Skript habe ich mir als "Starter" ins Startmenü bzw. als Knopf in die KDE control station, sodass ich das schnel togglen kann.
Fehler und Optimierungsbedarf:
- Aus mir unbekannten Gründen musste ich bei diesem Skript den Pfad zu qdbus6 explizit angeben. Ich bin dankbar für sachdienliche Hinweise, warum...
- Ich habe das Phänomen bemerkt, dass "Touch to Click" beim Touchpad teilweise nicht mehr funktioniert, wenn ich mittels Skript umschalte.
- Man muss manuell ein mal herausfinden, was die zu blockierenden Geräte-IDs sind, weil diese sich von Gerät zu Gerät unterscheiden. Auf der anderen Seite ist das aber auch schwer zu bewerkstelligen, weil nicht jeder will ja "alles" gesperrt bzw. aktiviert haben. Vielleicht will man auch nur das Touchpad (de-)aktivieren?
- Es kann sich lohnen, das Skript mit "enable" beim Herunterfahren auszuführen, sodass beim nächsten Hochfahren alles aktiviert ist. Dafür geht ihr in die Systemeinstellungen -> Autostart -> Neue Hinzufügen -> Abmeldungsskript und fügt dort das Skript ein.
Fazit
qdbus ist ein interessantes Werkzeug, mit dem man auf der anderen Seite aber auch wieder viel kaputt machen kann. Ein mal deaktivierte Tastatur bleibt (bis nach Neustart oder sogar darüber hinweg) deaktiviert. Man sollte also beim Testen vorsichtig sein und eine zweite Tastatur oder so zur Hand haben.
Quellen:
