| Summary: | xdg-desktop-portal-kde misbehaves and returns incorrect values when an unrelated systemd user unit fails | ||
|---|---|---|---|
| Product: | [Plasma] xdg-desktop-portal-kde | Reporter: | SC <kde> |
| Component: | general | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | aleixpol, bharadwaj.raju777, jgrulich, kde, nate, sitter |
| Priority: | NOR | ||
| Version: | 5.27.5 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=458865 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
SC
2023-06-02 05:47:20 UTC
Cannot reproduce on master, where we have radically refactored code though. > - Neither of my two tested VMs have this issue, including:
> - EndeavourOS KDE
Is the VM fully updated to the same release as your laptops? If yes, then there might be something in the configuration of your machines that is causing early startup. If not, then what happens if you do update it, without changing anything else?
Also cannot reproduce on master, when following the exact steps indicated. (In reply to Bharadwaj Raju from comment #2) > Is the VM fully updated to the same release as your laptops? If yes, then > there might be something in the configuration of your machines that is > causing early startup. Yep they are all fully updated. Fedora 38's KDE version (and version of related components) are all up to date with Arch. I'll run `systemd-analyze plot` on Monday on all my machines to look for any startup order differences. Okay. After some time of forgetting about this issue, I think I found an important lead. It seems like it's somehow related to a startup failure of ibus when using `--panel=/usr/lib/kimpanel-ibus-panel` (which frankly, is just bizarre). Follow the following steps to reproduce: 1. Create a fresh Linux VM (I tested Fedora 38 & EndeavourOS) with KDE. 2. Install `xdg-desktop-portal` and `xdg-desktop-portal-kde`, and set KDE theme to `Breeze Dark`. 3. Reboot and run the colour scheme query: `qdbus org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Settings.Read "org.freedesktop.appearance" "color-scheme"`. 4. Expected: `1`; actual: `1`. 5. Create `~/.config/systemd/user/ibus@.service` and write the following content: ``` [Unit] Description=Intelligent Input Bus [Service] ExecStart=/usr/bin/ibus-daemon --replace --xim --panel=/usr/lib/kimpanel-ibus-panel Environment=DISPLAY="%I" [Install] WantedBy=default.target ``` 6. Enable this service with `systemctl --user enable "ibus@$DISPLAY.service"` and reboot. 7. Run `systemctl --user status "ibus@$DISPLAY.service"` and verify that it has failed. - The reason for this failure seems to be unrelated to this issue; it seems to be some kind of "unit started too soon". Adding `ExecStartPre=/usr/bin/sleep 10` is a quick and dirty way to prevent the failure, although I am yet to find a proper fix. 8. Rerun colour scheme query. 9. Expected: `1`; actual `2`. 10. Add `ExecStartPre=/usr/bin/sleep 10` to the ibus unit to prevent the failure and reboot. 11. Run `systemctl --user status "ibus@$DISPLAY.service"` and verify that it no longer fails. 12. Rerun colour scheme query. 13. Expected: `1`; actual `1`. I was only able to notice that this is the source of this issue because I was switching back to using fcitx5 after 2 years on ibus. When I disabled this ibus service, the colour scheme problem went away. I'm keeping this issue open because IMO the failure of a completely unrelated service should not be causing the desktop portal to misbehave. And if all this is sounding ridiculous to you, trust me, I know. It's just as ridiculous and bizarre to me, which was part of the reason it took ages for me to diagnose. I will be updating the title to something more reflective of the newly uncovered information. Oh and, before step 5, obviously you should install `ibus` using whatever package manager it is on your distro. I forgot to mention that. |