transmission-qt does not inhibit KDE idle sleep while torrents are downloading

Alan Hovgaard alan.hovgaard at gmail.com
Mon Sep 21 10:42:01 BST 2026


Hello Transmission and Plasma/PowerDevil developers,

I am writing as a Linux user of transmission-qt on KDE Plasma. This is
a report of a long-standing feature gap in the Qt client, plus a
description of a local workaround that works on Plasma 6. I hope it is
useful if you implement sleep inhibit in transmission-qt, or if anyone
is looking at how PowerManagement inhibitions behave on Plasma.

This is the same gap as:

  https://github.com/transmission/transmission/issues/7982
  https://github.com/transmission/transmission/issues/195
  https://github.com/transmission/transmission/issues/5530

I am not subscribed to plasma-devel; please tell me if this should
have gone only to Bugzilla/GitHub.


Environment
===========

- Arch Linux, KDE Plasma 6.7.5, Wayland
- transmission-qt 4.1.3-2 (extra)
- PowerDevil auto-suspend after 60 minutes of inactivity on AC
- Display turn-off after 15 minutes (this should keep working)
- Downloads are often long-running; the machine is otherwise idle


What happens
============

If transmission-qt is downloading and I leave the machine idle, Plasma
still treats the session as idle. After 60 minutes PowerDevil
suspends. That kills peer connections and interrupts the download.

transmission-qt does not appear in PowerDevil's inhibition list while
downloading. systemd-inhibit --list also shows no Transmission
sleep/idle lock.

The settings key already exists in ~/.config/transmission/settings.json:

  "inhibit-desktop-hibernation": false
  "inhibit_desktop_hibernation": false

Enabling it has no effect in the Qt client. There is also no Qt
Preferences UI for it.


Why
===

This is implemented in the GTK client, not in Qt.

GTK (gtk/Session.cc) watches TR_KEY_inhibit_desktop_hibernation and,
when there is at least one non-stopped torrent, calls:

  org.gnome.SessionManager.Inhibit(
      "Transmission BitTorrent Client",
      xid=0,
      "BitTorrent Activity",
      flags=4)   /* inhibit suspending the session or computer */

It releases the cookie when torrents stop or the pref is off.

On KDE, org.gnome.SessionManager is typically not present, so even a
Qt port of that exact call would not be enough by itself. Plasma's
power manager is PowerDevil. It honours:

  org.freedesktop.PowerManagement.Inhibit.Inhibit(app, reason)

which kde-inhibit --power uses. PowerDevil then shows a PolicyAgent
inhibition of type "sleep" (InterruptSession). That blocks automatic
suspend/hibernate. It does not keep the screen on, and it does not
block an explicit Sleep from the user (menu, power button, etc.).

So the missing piece is: transmission-qt never takes that inhibition,
even though the pref and GTK behaviour already exist.


Local workaround (what I did, how it works)
===========================================

Until the Qt client does this itself, I run a small user service that
holds the same FDO inhibition PowerDevil already understands, but only
while a download is actually writing data.

What it does:

- A systemd --user service, wanted by graphical-session.target, runs a
Python helper for the life of the Plasma session.
- Every 15 seconds it looks for a process whose /proc/<pid>/comm is
exactly "transmission-qt".
- It reads /proc/<pid>/io write_bytes. Seeding is mostly reads;
downloading writes payload to disk (here, also over CIFS). If
write_bytes grows by at least 64 KiB in that window, the session is
treated as downloading.
- It then calls, on the session bus, and keeps the connection alive:

    org.freedesktop.PowerManagement
      /org/freedesktop/PowerManagement/Inhibit
      org.freedesktop.PowerManagement.Inhibit.Inhibit(
          "transmission-qt", "Downloading torrents")

- PowerDevil lists it as:

    sleep  transmission-qt  "Downloading torrents"  block

- The lock is dropped 5 minutes after the last write burst, or
immediately if transmission-qt exits. That covers cache flushes and
short stalls without keeping the machine awake all night for a
seed-only or paused session.
- Screen-off, lock, lid, and a user-initiated Sleep are left alone.

Verified on this machine while a live download was writing about 10 MB
/ 15 s: PolicyAgent.ListInhibitions and ActiveInhibitions both showed
the transmission-qt sleep block, and auto-suspend no longer applied.

I used write_bytes instead of RPC because rpc-enabled is off in this
Qt session. A first-party implementation should use session/torrent
state (active downloads, or rateDownload > 0), matching GTK more
closely. GTK currently inhibits for any non-stopped torrent, including
seeding. My workaround is narrower on purpose: only downloading.


What I would like from transmission-qt
======================================

Please implement inhibit-desktop-hibernation in the Qt client, for a
local session:

1. Honour the existing settings key (and expose the GTK checkbox in Qt prefs).
2. On Linux, take org.freedesktop.PowerManagement.Inhibit while
torrents are active (or, better, while downloading). That is the API
kde-inhibit --power uses and what PowerDevil surfaces in the battery
applet.
3. Also keep org.gnome.SessionManager.Inhibit(flags=4) so
GNOME/Cinnamon keep working, as GTK already does.
4. Hold the D-Bus name for the life of the cookie. One-shot
qdbus/busctl calls are released as soon as the unique name disappears;
PowerDevil also delays listing inhibitions by a few seconds, but the
lock itself is active as soon as Inhibit returns.
5. Do not use a logind idle inhibit or SessionManager flag 8 unless
you also want to prevent screen-off. Users who set "sleep after 60
minutes" often still want the display to blank.

A Qt-side implementation would remove the need for this helper on KDE,
and would fix the same idle-sleep problem on other desktops that
implement the FDO PowerManagement inhibit interface.

Happy to test a patch on Plasma 6.7 Wayland.

Thank you for Transmission, and thanks to the PowerDevil maintainers
for a sleep inhibit that applications can actually use.

Best regards,
Alan Hovgaard
alan.hovgaard at gmail.com


More information about the Plasma-devel mailing list