[Bug 296799] SDDM-launched Plasma Wayland session never becomes the active ConsoleKit session on its VT (regression)
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Wed Jul 15 10:38:37 BST 2026
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296799
Bug ID: 296799
Summary: SDDM-launched Plasma Wayland session never becomes the
active ConsoleKit session on its VT (regression)
Product: Ports & Packages
Version: Latest
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: Individual Port(s)
Assignee: ports-bugs at FreeBSD.org
Reporter: delleceste at gmail.com
CC: desktop at FreeBSD.org, kde at FreeBSD.org
CC: desktop at FreeBSD.org, kde at FreeBSD.org
## Summary
Starting a **Plasma 6 Wayland** session from **SDDM** fails: the session
process is spawned on a
fresh VT but never becomes the *active* ConsoleKit session on `seat0`, so
`kwin_wayland` cannot
`TakeDevice` the DRM/input nodes and aborts within ~0.6 s. The **same session
command works
perfectly when launched from a foreground getty login**. X11 sessions via SDDM
are unaffected.
This worked until roughly a few weeks ago and is a **regression**.
## Environment
- FreeBSD 15.1-RELEASE, amd64 (`__FreeBSD_version` 1501000)
- sysutils/consolekit2 **2.0.0_1**
- x11/sddm **0.21.0.36_3** (0.21.0-36-gc2b97dd)
- plasma6-kwin / plasma6-plasma-workspace **6.6.6**, KF6 6.26.0, Qt6 6.11.1
- GPU: NVIDIA RTX A400, proprietary driver 595.84 (nvidia-drm KMS;
`hw.nvidiadrm.modeset=1`)
- Seat management: ConsoleKit2 (no logind/seatd in use by kwin, which uses
`KWin::ConsoleKitSession`)
## Symptom (SDDM path)
`/var/log/sddm.log`:
```
HELPER: Starting Wayland user session: ".../wayland-session"
"...plasma-dbus-run-session-if-needed .../ck-launch-session
.../startplasma-wayland"
HELPER: Jumping to VT 10
HELPER: VT mode didn't need to be fixed
DAEMON: Session started true
DAEMON: Auth: sddm-helper exited with 125 # ~0.6 s later
```
The session log (`~/.local/share/sddm/wayland-session.log`) is **0 bytes**.
When run with output
captured, `kwin_wayland` prints:
```
No backend specified, automatically choosing drm
kwin_core: Could not determine the active graphical session
kwin_wayland_drm: drmModeListLessees() failed: Invalid argument
```
`console-kit-daemon` logs (present since well before this regression, so likely
not the whole story):
```
console-kit-daemon: WARNING: Error waiting for native console 2 activation:
Inappropriate ioctl for device
console-kit-daemon: WARNING: failed to change drm master setting. Error: Device
busy / Invalid argument
```
The SDDM greeter's Xorg runs on **VT 9** (`-seat seat0 vt9`); the Wayland
session is launched on
**VT 10**. The greeter is only stopped *after* the session has already exited.
## What works (getty path) — and the diagnostic contrast
>From a **foreground getty login** (VT 1):
```
dbus-run-session ck-launch-session startplasma-wayland
```
→ a fully working Plasma Wayland session **with input**. `ck-list-sessions` for
it:
```
seat = 'seat0'
session-state = 'active'
active = TRUE
x11-display = '' # Wayland, no X
display-device = '/dev/ttyv0'
VTNr = '1'
```
i.e. the session is active because it is **born on the already-foreground VT
(VTNr 1); no VT
switch is required**. ConsoleKit correctly brokers both the DRM node and the
(root-owned,
`0600 root:wheel`) `/dev/input/event*` nodes to the unprivileged compositor.
Under SDDM the session is placed on **VT 10** (not foreground) and something
must (a) switch the
console to VT 10 and (b) have ConsoleKit detect that switch and re-mark the
active session. **That
switch-and-activate step is what fails** — the session never reaches
`active=TRUE`, hence kwin's
"Could not determine the active graphical session".
X11 via SDDM works because the X server (run as root) supplies the VT/display
binding that lets
ConsoleKit mark the session active (that session shows `active=TRUE, VTNr=9,
x11-display=:0`).
## Minimal reproducer
1. Enable SDDM, select the "Plasma (Wayland)" session, log in → returns to
greeter; 0-byte
`wayland-session.log`, `sddm-helper exited with 125`.
2. From a text console (getty) login: `dbus-run-session ck-launch-session
startplasma-wayland` →
works. `ck-list-sessions` shows the session `active=TRUE` on the foreground
VT.
## Regression / suspected cause (not confirmed)
Last-known-working was ~early June 2026; first failing session log is
2026-06-12. The most
conspicuous change in that window is **sysutils/consolekit2 1.2.6_6 → 2.0.0
(2026-05-26)**, a
major-version update of exactly the component responsible for VT/seat
activation. This is *not*
proven — concurrent Qt/Plasma updates (6.5.x → 6.6.x) also landed. `consolekit2
2.0.0_1` does
**not** fix it.
The `console-kit-daemon` "native console activation: Inappropriate ioctl for
device" warning
predates the regression (seen since 2026-04-02 under 1.2.6), so either it was
previously
non-fatal, or the regression is a subtler behavioral change in the
switch-activate path.
I'm happy to test a **consolekit2 1.2.6 downgrade** (dependency-safe; all
dependents require only
`>1.2.5`) to confirm/deny consolekit2 as the culprit, and to provide any
further logs
(`ck-list-sessions`, full `sddm.log`, kwin `QT_LOGGING_RULES='kwin_*=true'`
output, dmesg).
## Note for triagers
The failure is specifically the **VT-switch-and-activate** path (SDDM issues
`VT_ACTIVATE` to a
non-foreground VT; ConsoleKit must detect it and mark the session active). A
getty session on the
foreground VT sidesteps it entirely and works. This likely narrows the fix to
consolekit2's VT
monitoring on FreeBSD and/or SDDM's VirtualTerminal handoff
(`x11/sddm/files/patch-src_common_VirtualTerminal.cpp`).
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the kde-freebsd
mailing list