Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with xdg-desktop-portal #44

Open
gen2brain opened this issue Nov 16, 2024 · 26 comments
Open

Problem with xdg-desktop-portal #44

gen2brain opened this issue Nov 16, 2024 · 26 comments

Comments

@gen2brain
Copy link

The startlxqtwayland script sets XDG_CURRENT_DESKTOP="LXQt:$COMPOSITOR:wlroots", in my case compositor is labwc. Does : mean something or this is just a custom thing to allow you to initialize the right backend? I think that is what broke portals loading in my case for the Wayland session as they all have UseIn, i.e. UseIn=LXQt.

I used the systemctl --user edit xdg-desktop-portal.service and I override this:

[Service]
Environment="XDG_CURRENT_DESKTOP=LXQt"

And I have this in ~/.config/xdg-desktop-portal/portals.conf:

[preferred]
default=lxqt;gtk;
org.freedesktop.impl.portal.FileChooser=lxqt;gtk;
org.freedesktop.impl.portal.Screencast=wlr
org.freedesktop.impl.portal.Screenshot=wlr

So now the situation is better, but I still have to do systemctl --user restart xdg-desktop-portal once before I have all the portals loaded, the service is initially started but without any portal implementation loaded.

@tsujan
Copy link
Member

tsujan commented Nov 16, 2024

Does : mean something

XDG_CURRENT_DESKTOP has always been a colon separated list of strings, although that list may have a single string. All codes that use it should handle it as so.

And yes, the panel uses it for choosing the backend, although there are only 2 Wayland backends for now.

but I still have to do systemctl --user restart xdg-desktop-portal

Join the club ;) See lxqt/lxqt#2586. I use this in a startup script for my 3 Wayland sessions:

if ! pidof "xdg-desktop-portal-lxqt" 1 > /dev/null; then
    systemctl --user restart xdg-desktop-portal.service &
fi

For me, LXQt portal is started correctly only in Labwc (although I haven't checked it since its previous version, working under LXQt+kwin_wayland).

@gen2brain
Copy link
Author

Thanks, I tried to search for a separator but found nothing. So I don't need an override, I will just add what you did. And I guess I will file some issues for a few apps I am using that don't seem to handle XDG_CURRENT_DESKTOP correctly.

@tsujan tsujan changed the title XDG_CURRENT_DESKTOP and xdg-desktop-portal Problem with xdg-desktop-portal Nov 16, 2024
@tsujan
Copy link
Member

tsujan commented Nov 16, 2024

Let's reopen this with a new title — a Discussion page isn't enough for keeping track of it.

@tsujan tsujan reopened this Nov 16, 2024
@gen2brain
Copy link
Author

Can this be related to the lxqt/xdg-desktop-portal-lxqt#47 I filed? IMO it is much nicer to have a systemd and user service that can be controlled.

@tsujan
Copy link
Member

tsujan commented Nov 16, 2024

Can this be related to the lxqt/xdg-desktop-portal-lxqt#47 I filed?

I doubt it. My questions:

  • Why does it work fine when logging into the X11 session?
  • Why does it work fine with some Wayland sessions?
  • And, why does it work in all Wayland sessions for @stefonarch? He has all supported sessions.

@gen2brain
Copy link
Author

Well, while you mentioned the X11 session, I first upgraded to 2.1.0, after using it for years on Gentoo and it all just worked. Gentoo still doesn't have lxqt-wayland-session ebuild and I made one myself to try the Wayland. After that, and after I reboot, I cannot start the X session properly, sometimes it works, but sometimes black screen. My solution is to start the Wayland session, which also will not start, just labwc starts, then I start the LXQt session from the labwc menu, one time, two times and third will work and will start many panels. After that, I can normally start both X11 and Wayland sessions. Every time I reboot I can reproduce this. Sometimes, if I wait long enough it will start. Any sub-sequence start will work almost instantly though.

This is all off-topic for this issue, if I can collect something that makes sense I will open one. I like to collect and have xsession.log, now wsession.log for all the GUI apps warnings and debug. But I don't see anything there.

@tsujan
Copy link
Member

tsujan commented Nov 16, 2024

That's very strange because lxqt-wayland-session doesn't touch the X11 session. Are you sure that the problem isn't in the desktop display manager (e.g., SDDM)?

@gen2brain
Copy link
Author

I don't have any display manager, I use startx that will use my modified startlxqt script, and now startw to start a Wayland session, which is just a little modified startlxqtwayland script.

@tsujan
Copy link
Member

tsujan commented Nov 16, 2024

My wild guess is that, for some reason, Wayland is running when you log into an X11 session, and X11 is running when you log into a Wayland session.

@tsujan
Copy link
Member

tsujan commented Nov 16, 2024

Here I use SDDM and have no issue about switching between three Wayland sessions and the X11 session. I use SDDM's default settings.

EDIT: SDDM is not bug-free, but most of the time (99%), it lets me change the session without problem.

@gen2brain
Copy link
Author

I will try to find out more about this. I don't like that sometimes if I wait it works. What is it waiting for, will try to get more info. I prefer to have ctrl+alt+backspace configured to kill quickly the X and now W session and start again, I never liked the display managers.

@tsujan
Copy link
Member

tsujan commented Nov 16, 2024

When you say that, after logging into LXQt+Labwc, your problem disappears, it means that now lxqt-session ends the session correctly on logging out, such that you could log into LXQt+X11 without problem — and the same there. So, something should be wrong before logging into an LXQt session

@gen2brain
Copy link
Author

Very strange is that something is affecting the X11 session, that never happened before. I once saw for X session in logs, something like Qt cannot load xcb plugin, but it is there, "but it is there" is part of the message, of course I know it is there.

@gen2brain
Copy link
Author

I will try to get more info, but I will need to reboot several times, when I find the time I will do it.

@tsujan
Copy link
Member

tsujan commented Nov 16, 2024

Qt cannot load xcb plugin, but it is there

X11 isn't running then. That confirms my guess.

@gen2brain
Copy link
Author

Well, X is running and is showing the black screen (until I killall -9 X from other vt, because setxkbmap -option terminate:ctrl_alt_bksp is in lxqt autostart, it doesn't get there, I must kill it manually), and sometimes if I wait for it just continues to load the lxqt session. This is all for another issue, sorry, but for now, I have no idea who is to blame and where to file the issue.

@stefonarch
Copy link
Member

I had a look at my config dir and I've no config file for portals at all in my home...

@tsujan
Copy link
Member

tsujan commented Nov 16, 2024

I had a look at my config dir and I've no config file for portals at all in my home...

It isn't needed anymore, after lxqt/xdg-desktop-portal-lxqt@2f26908. I don't have it either.

@gen2brain
Copy link
Author

Ok, I have much more info, I have found what is going on. It is related to xdg-desktop-portal, not to the Wayland session but I guess better to stay in this issue for context.
I rebooted many times and confirmed that if I start a plain openbox or plain labwc session there are no issues, both start instantly. Also, both LXQt X's and Wayland's sessions will start if I give them some time (one minute approximately), X sessions will be cripled because nothing starts in the tray, and Wayland's looks a little better.

Attached are the collected logs, they are similar to the X session, but the Wayland session doesn't have so much noise so is easier to debug. I have this in my script, exec $COMPOSITOR -C $XDG_CONFIG_HOME/labwc -S lxqt-session 2>&1 | ets >$HOME/.local/share/wsession.log so I can get a nice session log with timestamps, and I have watched the DBus session with dbus-monitor --session | ets > /tmp/dbus.txt & and also all the file modifications with inotifywait -m -r /home | ets > /tmp/inotify.txt 2>&1. From the logs, you can see that from the start until the session gets going it needs 30 seconds. Then lxqt-panel needs around 15 seconds to start. Just a note that the start time is inserted manually in the log file, it was saved in another file.

From the DBus log, and at that time when the panel was waiting to start I could see that it requested something about portals. I also noticed that sometimes when I systemctl --user restart xdg-desktop-portal it takes a lot of time, and sometimes is instant. So I removed the whole package with emerge -C xdg-desktop-portal and bam, no more issues, everything started instantly.

Now I need to debug more what is going on with xdg-desktop-portal, but I would argue that it should not affect LXQt in such a way. Probably you are waiting for the DBus response or something like that, although you probably have a reason to do so.

wsession.log
dbus.txt
inotify.txt

@gen2brain
Copy link
Author

Some more info. I added systemd service for xdg-desktop-portal-lxqt dbus service like in my issue, and noticed in journal logs that its timeouts, and in other issues like flatpak/xdg-desktop-portal#986 I saw that the reason can be that the signal it sends is not recognized and they suggested dbus-broker. After I installed and enabled dbus-broker instead of regular dbus X session started working. I am guessing you are already using dbus-broker since you didn't have issues with the X session.

Anyway, there are more issues, like flatpak/xdg-desktop-portal#1032, or flatpak/xdg-desktop-portal#801, then there is https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/74, and also, what I experience currently, when I kill the X or W session, the xdg-desktop-portal is still running, that should not happen and is the cause for all kind of problems. Gnome even restarts the dbus session on exit https://gitlab.gnome.org/GNOME/gnome-session/-/blob/main/data/gnome-session-shutdown.target#L26. And I don't use DM so I don't get to have graphical-session.target. All in all, bullshit all around, this is not ready for usage. It doesn't help that every DE implements its own API even for screenshots, i.e. not usable. I am going back to X and will check occasionally the progress.

@tsujan
Copy link
Member

tsujan commented Nov 18, 2024

I am guessing you are already using dbus-broker

Yes. These are my installed dbus packages (from Arch):

dbus 1.14.10-2
dbus-broker 36-4
dbus-broker-units 36-4
dbus-c++ 0.9.0-12
dbus-glib 0.112-4
python-dbus 1.3.2-4
xdg-dbus-proxy 0.1.6-1

@tsujan
Copy link
Member

tsujan commented Nov 18, 2024

BTW, this problem doesn't seem to happen for me with kwin_wayland anymore. Of course, I still have the workaround, but my log shows that xdg-desktop-portal-lxqt is started normally.

However, I prefer to keep that simple workaround, because the problem may be random.

@gen2brain
Copy link
Author

To me it looks like you are even not allowed anymore to have both Gnome and KDE on the same system because both come with XDP, there are a gazillion issues if you dare to have both. This is just silly, but let's give it some time.

@tsujan
Copy link
Member

tsujan commented Nov 18, 2024

I have LXQt, KDE, GNOME and Enlightenment on my old laptop, and there's no problem. On this one (the laptop I use), I only have LXQt and KDE.

@gen2brain
Copy link
Author

I only started having problems when I wanted to try the Wayland session and I installed a couple of Flatpak apps, which implies you must have all that portal stuff etc. Everything was boring for years up until I wanted to try new XDG "standards".

@tsujan
Copy link
Member

tsujan commented Nov 18, 2024

I installed a couple of Flatpak apps, which implies you must have all that portal stuff etc.

Frankly, I disliked the idea of "portal" before, because it caused troubles for me in X11, a year ago. However, it works fine now, under both Wayland and X11. My theory is that there was a transition period, when things didn't work properly.

As for Flatpak, I avoid it like the plague ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants