Yet another xdg-desktop-portal-gtk misadventures!

Help
1

hai everyone!! :smiley_cat:

happens only in x11 (e.g. leftwm). whomst a thunk it, mate!

systemd[1767]: Starting Portal service (GTK/GNOME implementation)...
.xdg-desktop-po[2317]: cannot open display:
systemd[1767]: xdg-desktop-portal-gtk.service: Main process exited, code=exited, status=1/FAILURE
systemd[1767]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.
systemd[1767]: Failed to start Portal service (GTK/GNOME implementation).

hehe
 but there’s more!!! this one makes me chortle and giggle quite a wee bit, haha! (after a reboot)

systemd[1866]: Failed to start Portal service (GTK/GNOME implementation).
systemd[1866]: xdg-desktop-portal-gtk.service: Start request repeated too quickly.
systemd[1866]: xdg-desktop-portal-gtk.service: Failed with result 'exit-code'.

and it repeats ad nauseam.

is this a hoo hoo or a haa haa moment, guys, does anyone know? i cant not use xorg until i finish all my silly little x11 exclusive games
 as soon as i do, x11 go byebye, mwahahaha!

ANYWAY!

no, unplugging and plugging it back again doesnt help. hmm, i really thought it would work this time though!

my $DISPLAY is :0 both in xorg and wl.

i also tried adding it thusly:

  xdg.portal.extraPortals = [
    pkgs.xdg-desktop-portal-gtk
  ];

unfortunately, to no avail
 even with lib.mkForce!

and nope, i have absolutely nothing in xdg.portal.config (for now). is that a problem, not changing anything?

in x11 i have these portal services launched:

xdg-desktop-portal-gtk (epic fail)
xdg-desktop-portal (worky yay)

as mentioned, in wayland (hyprland) i caught them all:

xdg-desktop-portal-gtk
xdg-desktop-portal-hyprland
xdg-desktop-portal

in another wayland (niri) session:

xdg-desktop-portal-gnome
xdg-desktop-portal-gtk
xdg-desktop-portal

interesting
 would you look at that! they all work (clarification: only in wayland!

of course, AS PER USUAL, i may have done something in my configuration.nix. oh, but what did i do last time
? I DONT REMEMBER! that’s the fun bit! im such a goof


but i really dont know
 a variable? perchance! i shall have a proper look at it all tomorrow, i suppose! :point_up: :nerd_face:

EDIT: whoopsie doodles, i forgot to say hello
 :sob: :sob: (sry it was 3 in the morning)

EDIT2: not a variable. i dont have anything of GTK_USE_PORTAL=1 or GDK_DEBUG=portals set at all. i dont even use them (at the moment).

people on the internet say that it’s a certified “session error”, however, i have literally nothing that changes .xinitrc and the like? okay, MAYBE its this thing, but i had THAT (see below) for the last couple a months and everything was alright?

  environment.etc."xdg/autostart/xrandr.desktop".text = ''
    [Desktop Entry]
    Type=Application
    Name=xrandr
    Exec=sh -c "xrandr --output eDP --off && xrandr --output DisplayPort-0 --mode 1280x1024 --rate 60.02 --primary"
    NoDisplay=true
  ''; # config.ron! -- 1280x1024@60.02, 1024x768@60.00, 1280x1024@75.03, 1024x768@75.03


which eventually starts After=graphical-session.target

nevermind how horrid it looks (but pls tell me if i can improve this somehow? do i actually put it into .xinitrc or something? services.xserver.displayManager.sessionCommands or environment.extraInit? i probably should
 i dont need a “desktop entry”!), this DOES NOT break a session, right? SURELY


EDIT: nah, mate. even without my xrandr script, the gtk portal’s still properly \033[0;31mF\033[0;32mU\033[0;33mC\033[0;34mK\033[0;35mE\033[0;36mD\033[0m, which is quite unfortunate
 i was thinking perhaps it’s the moment when it is executing, the monitors are blank, therefore it sees no display? but no.

but anyway
 the oddities dont stop here. the very same script i am talking about? it doesnt start either!

sh[1956]: /run/current-system/sw/bin/sh: regel 1: xrandr: opdracht niet gevonden
systemd[1883]: app-xrandr@autostart.service: Main process exited, code=exited, status=127/n/a
systemd[1883]: app-xrandr@autostart.service: Failed with result 'exit-code'.

excuse me, EXCUSE ME, you cant find xrandr? let me help you find xrandr:

~ where xrandr
/run/current-system/sw/bin/xrandr
~
~ which xrandr
/run/current-system/sw/bin/xrandr
~
~ xrandr
Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 16384 x 16384
eDP connected (normal left inverted right x axis y axis)
   800x1280      60.00 +
   800x600       60.00
   640x480       60.00
   256x160       58.79
DisplayPort-0 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024     60.02*+  75.02
   1280x960      60.00
   1280x800      59.91
   1152x864      75.00
   1280x720      60.00
   1024x768      75.03    60.00
   832x624       74.55
   800x600       75.00    60.32
   640x480       75.00    59.94
   720x400       70.08
~

see? worky. in bash, sh, zsh, etc.

EDIT: okay after removing the sh -c "" part and just using the Exec=xrandr, it says this then:

xrandr[2177]: /run/current-system/sw/bin/xrandr: unrecognized option '&&'
xrandr[2177]: Try '/run/current-system/sw/bin/xrandr --help' for more information.
systemd[2106]: app-xrandr@autostart.service: Main process exited, code=exited, status=1/FAILURE
systemd[2106]: app-xrandr@autostart.service: Failed with result 'exit-code'.


uhm
 what. but it literally applies the monitor changes? how can it fail, when it clearly worked? WHATEVER! it’s not even related to my portal situation


oh, by the way, i just noticed. bwahaha, xorg thinks that im using a DP connection. that’s hilarious! i am using HDMI to connect to a DVI-d (passive adapter)! (wait, now that i think about it, i think wayland also thinks the same? is this
 normal?)

but anyway, i have a slight suspicion it could be one of those “just pin a version ya @#$%!” situations, is it? but i raelly dont wanna do this, i have no idea how to, and i know it takes quite a lot of scary and unknown lines of code (unknown to me, that is, i am a noob, btw
)

also, i tried using my backup of flake.lock (sorry i keep forgetting to mention i am using flakes, nixos/nixpkgs/nixos-unstable branch, but do i have to? isnt it the norm by now using something “experimental”?) and no, nothing’s changed
 alas
 defeated, shamefully so

EDIT3: UH OH. but what’s this?

systemctl --user status xdg-desktop-portal.service

.xdg-desktop-po[3814]: Failed to ReadAll() from Settings implementation: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer 'org.freedesktop.impl.portal.desktop.gtk': startup job failed

what the hell?! time to debug


well. no. first of all, i just “fixed” this error by removing all the gtk* (settings) related folders in my .config folder (they were empty anyway), and now it’s gone, apart from a few “fallback” warnings, which is fine, because it is the only portal that exists in xorg (EDIT: maybe it would have been a better idea to use pkgs.nwg-look or something to wipe the configs? but i digress). but it all STILL revolves around this SPECIFIC error line which has no description whatsoever:

.xdg-desktop-po[1234]: cannot open display:

there is no relevant information on this in the whole of internet


EDIT4: i found this:

but it is utterly useless. i dont have xdg-desktop-portal-gnome (in my xorg session) and i ALREADY have dbus-broker services (nixos default)??? should i switch from gtk to gnome XDP? perchance. but i want to try something really quick
 STABLE. VERSION. it’s time to downgrade a package (it is my first time ever
), yay! :partying_face: :tada:

one moment please


EDIT5: WELP.

i tried downgrading the portal via


flake.nix

  ...
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    nixpkgs-stable.url = "github:nixos/nixpkgs/nixos-24.11"; # ALSO TRIED 25.05
  };
  ...

configuration.nix

  xdg.portal.extraPortals = [
    inputs.nixpkgs-stable.legacyPackages.${pkgs.system}.xdg-desktop-portal-gtk # pkgs.xdg-desktop-portal-gtk
  ];

and after half an hour of wasted time it just spat out this:

error: builder for '/nix/store/gg2vysicfpq7381dpd08bm5l1jgfkkh8-user-units.drv' failed with exit code 1;
       last 1 log lines:
       > ln: failed to create symbolic link '/nix/store/31j5i02v21z9xq4wj521pxvlfz353x6f-user-units/xdg-desktop-portal-gtk.service': File exists
       For full logs, run:
         nix log /nix/store/gg2vysicfpq7381dpd08bm5l1jgfkkh8-user-units.drv
error: 1 dependencies of derivation '/nix/store/lyscf981438rskkngw6pmrhvlj7ly9qf-etc.drv' failed to build
error: 1 dependencies of derivation '/nix/store/w1aap5nl7dcfd6xyb3l6h5xyqz5i80da-nixos-system-deck-25.11.20250913.c23193b.drv' failed to build

well. i dont think that’s a skill issue, at least. though i did have some difficulties setting another branch up
 i eventually used this (edited)
 and it worked (i dont care about the “verbosity” of the line, but i do care about whether it is an overlay or not
). but then i found this, which does
 pretty much the same thing, right? or maybe it is only for non-flake channels? i will make a post about it later on
 AFTER THIS!


but maybe it doesnt even work at all with any package? okay, let’s try


  environment.systemPackages = [
    inputs.nixpkgs-stable.legacyPackages.${pkgs.system}.hyfetch
  ];

and that worked for that - it compiled! epic. as i expected. now


now that downgrading didnt help, the portal situation ominously persists
 :sob:

2

Not saying you have to switch to wayland either, but xwayland can run games just fine in general. Unless some specific games are having issues?

1 Like
3

nah. there is this one game that is having massive memory leaks after like 30 minutes in wayland (because its not made for wayland). otherwise works quite well, actually.

4

That doesn’t make much sense, the game shouldn’t see any differences. xwayland is the same as running X11 from the game’s perspective.

There could be an xwayland bug that causes this, what game are you talking about specifically and how did you determine it’s a memory leak that doesn’t happen on X11? This smells like an XY problem, if we just figure out how to fix that you can stop messing with X11.

If you insist on keeping an X11 session, this is a typical case of a missing $DISPLAY variable in your dbus environment. It has nothing to do with whether a monitor is connected or not, the portal just doesn’t know which X11 server to render on (since there can be multiple).

Ultimately this means your X11 startup scripts don’t include:

exec dbus-update-activation-environment --systemd DISPLAY

I don’t know how you start leftwm, but a line like that should be somewhere in ~/.xinitrc or ~/.xprofile, depending on which variant of the xdm standard your login manager uses, or somewhere else if you build your own thing.

You’ve done a lot of random experimentation that probably breaks a bunch of other stuff (including mixing stable + unstable specifically for the portal implementations), please just revert all of that.

You’d have similar issues with your wayland sessions, but it sounds like your startup scripts for those already include a way to import variables into dbus. uwsm does this by default, I believe.

1 Like
5

ugh. BeamNG. it is notorious for memory leaks via xwayland / vulkan (EDIT: they’ve JUST released an update with native wayland support after almost 5 years! brilliant timing!). the developers are doing a bad job at optimising anything (nothing is multithreaded). it just never worked for anyone using gamescope, SteamOS or not. but that is out of topic
 (?). i keep an x11 session JUST FOR THIS GAME (i also need to use librewolf to upload game’s debug files, im doing some modding and mapping here and there, which uses a FileChooser implementation, actually, the game itself uses gtk3). i am pretty crazy like that :crazy_face:

clarification: the native linux binary.

nothing is typical to me in this universe
 :sob:

uhm
 i dont have anything like that. my leftwm starts via pkgs.tuigreet. i have no .xinitrc or .xprofile in my $HOME? BECAUSE everything worked without it literally just yesterday (and before that, for months)? do i put that line into .xinitrc?

wouldnt say it was random. when something breaks after you update
 what do you do? oh
 right
 you rollback. ah. the whole point of nixOS
 uhh
 let’s just say, the previous generations were accidentally wiped after someone ran the garbage collector
 would you “pin” or downgrade a package, then? that’s what i did


i did revert all of that, by the way, do not worry.

yep. i have a UWSM hyprland session. niri, however, is not. but portals work there just fine. i have no problem on wayland.

so
 uhm. dbus, huh? never needed to do anything with dbus in my life
 :woozy_face:

1 Like
6

NO WAY THAT WORKED. oh dear


  services.xserver.updateDbusEnvironment = true; # default = false

that’s all there was to it. tsk. yep.

:frog:

EDIT: also try:

  services.dbus.implementation = "broker"; # default = "dbus"
3 Likes
7

Huh, nice, I did not know about that option!

FWIW, ~/.xinitrc or ~/.xprofile get executed by the X server’s Xinit script, which runs before that session script. ~/.xinitrc is for startx-based display managers, and ~/.xprofile is for xdm-based display managers (which sounds like tuigreet behaves like one of the former?).

The reason there are two scripts that do the same thing when started by different launchers is historical and has to do with when X11 was all about launching a graphical session on a remote server; you wanted to run different scripts depending on whether you were using X11 locally or remotely, and startx is basically an abuse of the old mechanisms for launching X11 remotely.

You can create that file in your home directory and add whatever startup stuff you want to it. But that option is definitely what you want in this case.

Xwayland has nothing to do with vulkan, just start the game with its openGL renderer. I really don’t think you need to run it under X11, that memory leak likely occurs on X11 as well if you use the vulkan renderer.

This:

Screen flickering on wayland may happen on certain configurations

Is the only wayland-related bug, and is almost certainly just an instance of the lack of explicit sync on older nvidia drivers and on some versions with gsync. This should not happen on NixOS, since we’re way past those nvidia driver versions and the nixpkgs wlroots/xwayland versions have support for explicit sync.

No, actually, I’d probably pin my nixpkgs input to a commit from a few weeks ago. Flipping between stable/unstable is not “downgrading”, it involves far more unpredictable changes.

1 Like
8

mad, isnt it? i had it in my config, all along
 but i just forgot about it. kept it commented


.xinitrc you mean, right? yeah
 cos im not using that “xdm” thing or whatever that is.

i also have this, by the way:

  services.xserver.displayManager.startx.enable = true;

oh you dont know half the story. and it doesnt use opengl (and even if it did, its been deprecated, as in they’re just focusing on windows directX 11 and vulkan renderers). it only uses vulkan (again, native linux binary, $HOME/.local/share/Steam/steamapps/common/BeamNG.drive/BinLinux/BeamNG.drive.x64). apparently, not many players use it or even know about it - steam launches the proton version by default, and a casual steam gamer is clueless to the native binary’s existence in the game files. so, right now, i have nixOS on a steam deck. it’s great. but when i launch that game in wayland (via FHS
 cos its a “dynamically linked binary”, blah blah blah) (FHS’ing also in x11), my framerate gradually drops and i get massive stutters/freezes every 10 seconds (whilst playing ALONE, 1 car spawned), it is quite an annoying ordeal, having to reboot every now and then (it persists if i relaunch the game). in fact, on windows, i had many BSODs and memory leaks while playing this game (years ago, still happens tho). and im not the only one
 this is the most infuriating game to actually enjoy playing (and the painfully unrealistic physics).

EDIT: OMFG HAHAHA. they’ve just released an update today, and it includes
 NATIVE WAYLAND SUPPORT. @TLATER sorry for the ping, but that is just brilliant timing. i am getting rid of this fkn legacy x11 shite tomorrow, its about time! halfway there to actually being a good game. they still have to improve the atrocious tyre simulation (WIP)


nah. im not using novidia. never will. not even because they’re aggressively proprietary, but because i just dont see the reason why would i need raytracing, you know what i mean? just dont care, just like that. i prefer framerate over graphics without any fancy magical frame generators or whatever, the same applies to amd. i would get the last CPU/GPU/motherboard that doesnt have any of that. i always play on the “lowest” graphics setting, in any game, my entire life, even if my computer has the ability to push the highest of graphics (theres only a handful of games that i play that even have any graphics to talk about in the first place, so
 besides, 90% of them are simulators, sandbox and/or physics based, im quite boring)
 ever since i was young, i would concoct the most mad “fps config” you’d ever known, and it would include flat textures, lowpoly count and 0 particles. i still do! my configuration.nix is the craziest thing you will ever see
 when you’ll see it (i have to “prettify” it a bit, there’s about 13k lines)! i like playing games like this to this day. i mean, nobody batted an eyelid on such graphics 20 years ago


here’s a fun read: pages upon pages of silly little issues with the native linux version of beamNG (EDIT: irrelevant? see above)

sorry? i didnt downgrade the whole flake input branch or anything
 just the one package - the portal
? isnt that what i did? im not ever moving away from unstable, by the way, oh, speaking of which


what would be the equivalent of that for flakes? e.g. pkgs.unstable.librewolf? lots of renaming happening in specialArgs of flake.nix? (sorry, i dont actually know how to do it yet myself) cos i suppose that tutorial up there is for flakeless channels, right
?

9

xdm is what later evolved into gdm, lightdm, regreet, etc. Anything that launches environments defined via the freedekstop desktop environment specification is an xdm implementation; given that that option works for you this seems to include tuigreet. Some implementations don’t conform to the “spec”, to whichever extent it exists, either, so e.g. regreet will fail to execute the correct startup file.

startx is not one of these, so if you sometimes use startx and sometimes tuigreet you’d probably want to have both a .xprofile and a .xinitrc with the same contents.

But this is all irrelevant, since you’re not actually trying to define anything in your user’s X startup files.

That’s my point, you should have downgraded the whole branch, rather than grabbing a random package from stable. Stable and unstable are unrelated branches; stable is not an “older” version of unstable.

Stable packages could theoretically be more up-to-date than unstable packages, and if there is a regression in a specific package taking the latest stable version of that package will often not give you an older version of the package, so the regression will persist. Mixing channels if your intent is to downgrade does not make sense conceptually, and doesn’t help narrow down what caused the regression because the histories are unrelated.

Stable just means that updates don’t break backwards compatibility. It does not mean that your packages are outdated; packages can be updated even to the latest available version with no backwards incompatibilities (what we call “breakage”, which is a separate term from “bugs”). I don’t intend to convince you to use stable (though I believe most users who don’t contribute upstream should and only don’t because they don’t understand the technical term “stability” and believe it has something to do with testing or bugs), but simply to explain why using stable for your intended purpose doesn’t make sense.

If you want to do the equivalent of switching to an older generation, pick an older nixpkgs commit and change your main nixpkgs to that commit, rather than grabbing a single package from a commit on a different branch altogether.

If you use flakes, this can be achieved by appending a rev, e.g. to make your NixOS based on this commit from last week:

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable?rev=22a91035527daa9ad02f6e1c3be31984c73a89ee";
}

If you want to use the release tarball (which I generally recommend now), you can instead specify a specific release tarball (you can check which commits have tarballs available here, though sadly this is more difficult for unstable):

{
  inputs.nixpkgs.url = "https://releases.nixos.org/nixos/25.05/nixos-25.05.809711.8cd5ce828d5d/nixexprs.tar.xz";
}

This is what I mean by “pinning” - pick a specific commit/version and make nix use that, instead of asking it to grab the latest commit/version automatically. Flakes are technically pinned by default (through flake.lock), it’s just that you want to pin a different version than the one you have in there.

Using git and git checkout-ing an older commit would also trivialize this, since going to an older version of your flake.lock will just revert you to whatever nixpkgs version you were using at the time, without involving NixOS generations at all.

The point of explaining all of this is that next time you run into something like this, you can tell us the commit hash of the commit you were using before the update, and then the commit hash from after the update. This way we know the range of commits that might have introduced the regression, which helps a lot with debugging; though in this case I’m almost convinced it’s not the update that caused it but some unrelated changes you either didn’t think were important or forgot you made. Git helps you realize if you made such changes, too, and clever use of git log can show exactly what happened to people trying to help you as well.

I’d really recommend figuring out git if you haven’t, it’s an invaluable tool for so many things to the point that I think it should be taught in schools.

2 Likes