SUMMARY *** Recording a window or an entire screen with OBS is broken in Plasma 6 RC2. Spectacle has the same problem for recordings, though screenshots work. When trying, I get a popup in the message area saying "Das Bildschirmvideo kann nicht gestartet werden - Failed to connect to PipeWire context". On the console from which I started OBS, it says "warning: [pipewire] Failed to start screencast, denied or cancelled by user". *** STEPS TO REPRODUCE 1. Open OBS 2. Add another source to the sources, either "Window Capture (PipeWire)" or "Screen Capture (PipeWire)" 3. A window (not belonging to OBS itself) will popup, asking you to select either a screen or a window to capture. Select any. OBSERVED RESULT A popup in the message are saying "Failed to connect to PipeWire context". The recording area in OBS stays empty. EXPECTED RESULT No error messages, and a live view of the selected window or screen appears in OBS. SOFTWARE/OS VERSIONS Windows: n/a macOS: n/a Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.93.0 KDE Frameworks Version: 5.249.0 Qt Version: 6.6.1 ADDITIONAL INFORMATION This used to work fine with Plasma 5 on Wayland, though I haven't tested it with Plasma 6 RC1. I get this console output in .local/share/sddm/wayland-session.log when I try to start a screen recording with OBS: ======= xdp-kde-wayland-integration: failed to start streaming ScreencastingStream(0x55f6853bd100) "Failed to connect PipeWire context" xdp-kde-screencast: Invalid window! QMap((0, QVariant(QString, "Luftrecht und Sicherheit – LBA – OpenUAV – Mozilla Firefox"))(1, QVariant(QIcon, QIcon("firefox",availableSizes[normal,Off]=QList(QSize(16, 16), QSize(22, 22), QSize(32, 32), QSize(48, 48), QSize(64, 64), QSize(128, 128), QSize(256, 256)),cacheKey=0x100000000)))(257, QVariant(QString, "firefox"))(258, QVariant(bool, false))(259, QVariant(bool, true))(260, QVariant(bool, false))(261, QVariant(bool, true))(262, Q Variant(bool, true))(263, QVariant(bool, true))(264, QVariant(bool, false))(265, QVariant(bool, false))(266, QVariant(bool, false))(267, QVariant(bool, false))(268, QVariant(bool, false))(269, QVariant(bool, false))(270, QVariant(bool, fal se))(271, QVariant(bool, false))(272, QVariant(bool, true))(273, QVariant(bool, true))(274, QVariant(bool, true))(275, QVariant(bool, true))(276, QVariant(QRect, QRect(2560,0 2560x1440)))(277, QVariant(uint, 5838))(278, QVariant(bool, fals e))(279, QVariant(QStringList, QList("9e528cdd-e14e-418b-8af3-b67fec93034f")))(280, QVariant(QByteArray, "{2a265327-b83f-4bfc-85a0-673065d86bae}"))) QObject::startTimer: Timers cannot have negative intervals QQuickItem: Cannot set FocusScope once item has children and is in a window. Service ":1.232" unregistered ======= I also get an enormous number of this message in that same file when trying to record a window with OBS or spectacle: QObject::startTimer: Timers cannot have negative intervals When trying to record using spectacle, the output in the sddm log looks like this: ======= dbus-daemon[4571]: [session uid=1000 pid=4571] Activating service name='org.kde.spectacle' requested by ':1.66' (uid=1000 pid=7593 comm="/usr/bin/krunner --daemon" label="kernel") dbus-daemon[4571]: [session uid=1000 pid=4571] Successfully activated service 'org.kde.spectacle' libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 kpipewire_record_logging: VAAPI: Display initialized kpipewire_record_logging: VAAPI: API version 1 . 20 kpipewire_record_logging: VAAPI: Mesa Gallium driver 23.3.1 for AMD Radeon RX 5700 XT (radeonsi, navi10, LLVM 17.0.6, DRM 3.54, 6.6.14) in use for device "/dev/dri/renderD128" libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 kpipewire_record_logging: VAAPI: Display initialized kpipewire_record_logging: VAAPI: API version 1 . 20 kpipewire_record_logging: VAAPI: Mesa Gallium driver 23.3.1 for AMD Radeon RX 5700 XT (radeonsi, navi10, LLVM 17.0.6, DRM 3.54, 6.6.14) in use for device "/dev/dri/renderD128" libva info: VA-API version 1.20.0 libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_20 libva info: va_openDriver() returns 0 kpipewire_record_logging: VAAPI: Display initialized kpipewire_record_logging: VAAPI: API version 1 . 20 kpipewire_record_logging: VAAPI: Mesa Gallium driver 23.3.1 for AMD Radeon RX 5700 XT (radeonsi, navi10, LLVM 17.0.6, DRM 3.54, 6.6.14) in use for device "/dev/dri/renderD128" [repeating for a while] ======= Pipewire itself is running, and I can connect to it using qpwgraph.
Could you try to see if screen sharing works for a freshly created user? Thanks!
I'm assuming you mean krfb when you say screen sharing, but in any case, none of these things work for a new user either.
The same problem occurs with Zoom when trying to share screen. This was working correctly on plasma 5.27.10 (wayland) With plasma-6.0.0 it works on Xorg and fails on Wayland.
Yesterday, I created a new user account, and screen sharing worked there. So I completely nuked my settings for everything not vital (saves, browser history, etc.), and this got screen sharing working on my main account. Tested a live stream, all good. Wake up the next day, login, and it's back to being broken with this error in everything [pipewire] Failed to start screencast, denied or cancelled by user Meaning, it's likely broken by a config change after one user login, perhaps on the next session after using screen share of any kind. I'd be fine with wiping said config at login for now, but I have absolutely no idea which one is relavent. I have so far tried deleting the xdg config, and the entire pipewire config folder and relogging, and these didn't work to clear the issue for even one session, but doing a mass wipe did, so it would likely be a good idea to hunt down which config is creating the problem so this issue can be resolved.
Remarking than in Gentoo I am using openrc, not systemd, to activate services. in .local/share/sddm/wayland-session.log I find this warnings/errors that might be related: (/usr/libexec/xdg-desktop-portal:2645): xdg-desktop-portal-WARNING **: 12:06:54.105: Failed connect to PipeWire: Couldn't connect to PipeWire kf.kio.gui: Failed to register new cgroup: "app-pam_kwallet_init-ee0be7f7c8a54329a488c7d4c30b9fed.scope" "org.freedesktop.DBus.Error.ServiceUnknown" "The name org.freedesktop.systemd1 was not provided by any .service files" kf.kio.gui: Failed to register new cgroup: "app-powerdevil-34e04bace542414490aaf20954391870.scope" "org.freedesktop.DBus.Error.ServiceUnknown" "The name org.freedesktop.systemd1 was not provided by any .service files" kf.kio.gui: Failed to register new cgroup: "app-baloo_file-62353f4a5da64f4dad630d8969c0b397.scope" "org.freedesktop.DBus.Error.ServiceUnknown" "The name org.freedesktop.systemd1 was not provided by any .service files" kf.kio.gui: Failed to register new cgroup: "app-pipewire-70b92ce0d61a4e51adc23c696c832609.scope" "org.freedesktop.DBus.Error.ServiceUnknown" "The name org.freedesktop.systemd1 was not provided by any .service files" kf.kio.gui: Failed to register new cgroup: "app-org.kde.kalendarac-8584ff4aa2ee46aaad09df352cd1d160.scope" "org.freedesktop.DBus.Error.ServiceUnknown" "The name org.freedesktop.systemd1 was not provided by any .service files" kf.kio.gui: Failed to register new cgroup: "app-kglobalacceld-61c1789c73514cfabf7197b66a310a4f.scope" "org.freedesktop.DBus.Error.ServiceUnknown" "The name org.freedesktop.systemd1 was not provided by any .service files" error creating screencast "Failed to connect PipeWire context"
https://pastebin.com/L9BSVK9H Here's an strace for OBS, I'm completely out of ideas.
Can you run your openrc equivalent of: systemctl --user status pipewire.service and make sure it's enabled and running >(/usr/libexec/xdg-desktop-portal:2645): xdg-desktop-portal-WARNING **: 12:06:54.105: Failed connect to PipeWire: Couldn't connect to PipeWire This is the killer line, we're trying to talk to pipewire and it's not running for whatever reason.
I think there may be two separate issues being discussed here. I'm seeing the same "[pipewire] Failed to start screencast, denied or cancelled by user" issue, and I'm using systemd. Pipewire is running the entire time, qpwgraph works, my music keeps playing. Logging in and out again fixes it for one run. If I exit OBS and then reopen it, the behaviour reproduces. All of this was working on 5.27.10, so I suggest we reopen this.
(In reply to Zane from comment #8) > I think there may be two separate issues being discussed here. > > I'm seeing the same "[pipewire] Failed to start screencast, denied or > cancelled by user" issue, and I'm using systemd. > Pipewire is running the entire time, qpwgraph works, my music keeps playing. > Logging in and out again fixes it for one run. If I exit OBS and then reopen > it, the behaviour reproduces. > > All of this was working on 5.27.10, so I suggest we reopen this. Is there anything specific that happens when you relog? I can't even get it to work again once after it gets "on its shit" without a full config flush since I can't seem to isolate which one causes this weirdness.
I can't see why this bug has been marked as solved and "not a bug". It's clearly still a bug, it's clearly a regression a from 5.27, and it's clearly not caused just by pipewire not actually running, since all reporters so far could confirm that, yes, pipewire is really running the whole time and reachable from various other pipewire frontends. From my point of view, this is even a rather major bug.
(In reply to Guido Winkelmann from comment #10) > I can't see why this bug has been marked as solved and "not a bug". It's > clearly still a bug, it's clearly a regression a from 5.27, and it's clearly > not caused just by pipewire not actually running, since all reporters so far > could confirm that, yes, pipewire is really running the whole time and > reachable from various other pipewire frontends. > > From my point of view, this is even a rather major bug. It's also not just a genroo thing, I for one am using Fedora, but had similar issues on Arch, which is SystemD, so it's not openrc related either.
(In reply to Melechtna Antelecht from comment #9) > > Is there anything specific that happens when you relog? I can't even get it > to work again once after it gets "on its shit" without a full config flush > since I can't seem to isolate which one causes this weirdness. I've found that when I relog, some processes (specifically the user dbus daemon, and pipewire) have persisted from the previous session. It's quite annoying tbh (even happens in Plasma 5). To work around this, after logging out I always enter a tty, "pkill -u $USER" everything, verify everything's dead, and only _then_ log back in. I suspect the core of this issue is caused by some dbus-related state going wonky somehere, in which case killing dbus temporarily solves it.
(In reply to Zane from comment #12) > (In reply to Melechtna Antelecht from comment #9) > > > > Is there anything specific that happens when you relog? I can't even get it > > to work again once after it gets "on its shit" without a full config flush > > since I can't seem to isolate which one causes this weirdness. > > I've found that when I relog, some processes (specifically the user dbus > daemon, and pipewire) have persisted from the previous session. It's quite > annoying tbh (even happens in Plasma 5). > To work around this, after logging out I always enter a tty, "pkill -u > $USER" everything, verify everything's dead, and only _then_ log back in. > > I suspect the core of this issue is caused by some dbus-related state going > wonky somehere, in which case killing dbus temporarily solves it. I'd agree, except, the issue occurs for me from first login (cold boot), until I relog (sometimes multiple are needed). So it can't be that, at least not in my case. Unless somehow these persist between reboots, and somehow I don't think so.