Recent updates causing xdg-desktop-portal issues

Desktop Environments Plasma
1

So, I did an update, which I do about weekly-ish mostly, not too frequently, and am being left with a new issue I’m not sure how to deal with.

I use Deskflow which is like Barrier, and Synergy before it, to share my keyboard & mouse over multiple computers. This is how I discovered the problem quickly, because it stopped working outright.

Turns out, what the cause seems to be stemming around xdg-desktop-portal, which provides the support for xdg-portals. I’m using KDE Plasma, so I have xdg-desktop-portal-kde installed as well.

Secondly, this only effected my desktop. My tabtop (laptop/tablet Lenovo Yoga), this still works without issue, but also doesn’t get nearly as much use.

So, ultimately the baseline is, when I now login to my KDE Plasma desktop from sddm, xdg-desktop-portal gives a log entry:

Feb 10 09:52:29 midgaard xdg-desktop-por[1768]: No skeleton to export

When this happens, Deskflow can’t find the InputCapture portal at all, and thus fails.

systemctl --user restart xdg-desktop-portal

Fixes the issue for this session. No long entries other than it stopped and started.

Before I had the xdg-desktop-portal-gtk also installed, likely for Flatpak and font related specific issues, and I would get these log entries:

Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: No skeleton to export
Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: Choosing gtk.portal for org.freedesktop.impl.portal.FileChooser as a last-resort fallback
Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: Choosing gtk.portal for org.freedesktop.impl.portal.AppChooser as a last-resort fallback
Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: Choosing gtk.portal for org.freedesktop.impl.portal.Print as a last-resort fallback
Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: Choosing gtk.portal for org.freedesktop.impl.portal.Notification as a last-resort fallback
Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: Choosing gtk.portal for org.freedesktop.impl.portal.Inhibit as a last-resort fallback
Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: Choosing gtk.portal for org.freedesktop.impl.portal.Access as a last-resort fallback
Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: Choosing gtk.portal for org.freedesktop.impl.portal.Account as a last-resort fallback
Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: Choosing gtk.portal for org.freedesktop.impl.portal.Email as a last-resort fallback
Feb 10 09:35:54 midgaard xdg-desktop-por[3303408]: Choosing gtk.portal for org.freedesktop.impl.portal.DynamicLauncher as a last-resort fallback

Of course, removing the -gtk portals also removes those messages.

I could really use some help here fixing this issue, as strongly familiar with whats’ causing this to begin with.

Thanks,
Psi-Jack

2

This almost feels like some kind of new race condition issue. My custom-made KeePassXC unlocker sometimes fails as well, but it ultimately ends up working too on a restart of it.

But, I implemented, a temporary bandaid for now, to sleep and restart xdg-desktop-portal, and that’s working. And I tested on a clean new user, and it’s working there too. So, I’d like to figure out the root cause, and solve it without re-implanting myself into a new user account, that’s tedious as all heck.

3

So, it seems to be a kernel issue, of all things, I don’t get how a kernel could effect this though… But I was using linux-lqx, the Liqourix kernel, and I switched off to linux-lts, no issue. linux-zen, no issue. So, weird…

4

Annnnnnnd… Problem is back yet again, doesn’t matter what kernel I run.

5

Don’t count out kernel issues yet. The previous LTS kernel was 6.6.xx, and it was the previous kernel on Arch until just over a week ago. It is still an LTS kernel, though. You can install it like this below, as it’s no longer offered directly in the official repos.

yay -S linux-lts66 linux-lts66-headers

See if it fixes the issue. Eventually, the official repo’s LTS kernel, 6.12.xx, will be just as stable as the previous 6.6.xx.

6

So, this issue is in fact still ongoing, and it’s a really weird issue. I don’t know what to do. I’ve done and seen differences in /proc/pidof xdg-desktop-portal/environ before and after restarting xdg-desktop-portal, confirming it seems to be somewhat of a race condition, even simple things like XDG_CURRENT_DESKTOP is not even set before, but is after.

7

I Just created /etc/systemd/user/xdg-desktop-portal.d/override.conf to bandaid this issue as-if a race condition:

[Service]
ExecStartPre=/usr/bin/sleep 1

Seems to have solved a lot of issues I was having with all this, as sad as it sounds…

8

I’ve been having the same problem. I only noticed it because light/dark themes weren’t being automatically set correctly in apps. I set up an autostart script to restart xdg-desktop-portal on login. Seems to have fixed the problem for now. Not sure why the first start of the service is not actually successful, but I’m not knowledgeable in Linux enough to figure it out. Once in a while the script doesn’t actually work, but I just manually run the script then. I’ll probably try out your solution.

9

So I ultimately found what my real problem was. I had a number of user services that were bound to default.target in my user, and this caused the issue of xdg-desktop-portal to be run before the desktop environment due to the other user targets. Things like my own keepassxc-unlocker, an arctis-nova chatmix service, and more, and once I moved all those, that actually worked/required a GUI, to graphical-session.target instead, it fixed the actual xdg-desktop-portal service itself. Shows you how fragile systemd can actually end up still being and run into race conditions that are apparently an afterthought.

10

how does a user profile get mucked up like that? different accounts? or wheel groups? did you assign them (the services) to default.target inadvertently?
[this one is interesting. Ive had a crabby xdg-portal before that wouldn’t launch crap. couldn’t figure it out so reinstalled etc.]