Nixpkgs: Startx displayManager doesn't pass xserverArgs to X

[Atemu]

Describe the bug
A clear and concise description of what the bug is.

When you use the startx display manager and try to use xserver options like autoRepeatDelay, they do not get passed on to the X executable (displayManagers are expected to do that).

To Reproduce
Steps to reproduce the behavior:

1. Set an xserver option like autoRepeatDelay
2. Use the startx displayManager
3. Notice there's no effect

Expected behavior
A clear and concise description of what you expected to happen.

It should apply the settings to the X server

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

If you had the same issue I did and want a quick fix, put your desired args in ~/.xserverrc.

Xinit has a way for specifying the flags system-wide via the xserverrc which is located in /etc/X11/xinit/xserverrc on a normal Freedesktop system.

We are not on such a system though, by looking at the strace of startx I found out that it tries to read the config from ${pkgs.xorg.xinit}/etc/X11/xinit/xserverrc which doesn't exist.

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

 - system: `"x86_64-linux"`
 - host os: `Linux 4.19.102, NixOS, 19.09.2070.b9cb3b2fb2f (Loris)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.2`
 - channels(root): `"nixos-19.09.2070.b9cb3b2fb2f"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
  - services.xserver.dislpayManager.startx

[rnhmjoj]

pinging creator of displayManager.startx: @xeji

[doronbehar]

I'm using displayManager.startx = enable and I use options to startx. BUT, I don't expect them to be embedded in the file $(which startx). Which makes sense IMO, because that's the whole point of using this "display manager" - you handle it your self. #80272 strives to fix your issue here but personally I see no need for a change.

[Atemu]

I don't expect them to be embedded in the file $(which startx)

They wouldn't be, the issue here is that Nixpkgs's xinit doesn't provide a system xserverrc which the system could use to set the system-wide xserver args.

/etc/X11/xinit/xserverrc exists on any normal distro but for us it's /nix/store/$hash-xinit-$ver/etc/X11/xinit/xserverrc which isn't particularly mutable and doesn't even exist by default.

This has nothing to do with the startx script.

that's the whole point of using this "display manager" - you handle it your self

If $HOME/.xserverrc exists, it preceeds any system-wide config (just like $HOME/.xinitrc); if you have a custom xserverrc to handle xserver args, nothing changes for you.

[Atemu]

Now that you mention it though, modifying the startx script slightly is much cleaner than what I did.
Not the server args though, just the sysserverrc variable.

[solna86]

I'm experiencing a potentially related issue @xeji @Atemu?

When using the default display manager, gpg does launch a X pinentry dialog. If I use startx it does use a curses pinentry, and it shouldn't.

I have narrowed it down to startx, but I haven't found which environment variable is responsible for this.

[primeos]

When using the default display manager, gpg does launch a X pinentry dialog. If I use startx it does use a curses pinentry, and it shouldn't.

Depending on your configuration changes that might be due to this logic of the NixOS module (which is a bit flawed as it's only an approximation).

[solna86]

@primeos Thanks. I don't use a desktop manager. I simply have xserver.enable = true and xserver.windowManager.stumpwm.enable = true.

With those 2 options, everything is fine and I get the expected X pinentry. I guess the GTK3 flavor.

When I also set xserver.displayManager.startx.enable = true in addition to those 2 options, I no longer get an X pinentry.

Do you think the logic of GnuPG you pointed to is behind this issue? I would naively think xserverCfg = config.services.xserver should not change by enabling startx.

Edit: I should also explain I'm starting X by running startx, and my .xinitrc just contains a line: exec stumpwm.

[solna86]

@primeos I have checked both NixOS configurations, with xserver.displayManager.startx.enable = true and false.

Both instantiate the same gpg-agent calling the same pinentry i.e, the corresponding gnupg and pinentry programs have identical hashes in the Nix store.

Unless I'm missing something obvious, it looks like a problem related to startx and the way it configures X at runtime.

[solna86]

Sorry for the multiple posts, I actually found the bug. It's an upstream issue in startx. They unset DBUS_SESSION_BUS_ADDRESS within startx and this is problematic.

Arch Linux patches startx to remove this line and pinentry runs fine instantiating the X dialog and not falling back to ncurses.

I will open a separate issue.

[doronbehar]

Well done @solna86. I was always curios why did I have to set it in my .xinitrc while back on Arch I didn't need to. :clap: Thanks a lot!

[solna86]

@doronbehar Thanks. That's one issue, but there are multiple issues within the startx script provided by upstream leading to the issue we are experiencing. I've detailed them in a new open issue:

https://github.com/NixOS/nixpkgs/issues/94375