It was already ordered after systemd-udev-settle.service, but that
doesn't do anything if no other units require
systemd-udev-settle.service. This was causing random failures during X
server startup, e.g.
machine# [ 12.691372] display-manager[607]: (EE) open /dev/dri/card0: No such file or directory
http://hydra.nixos.org/build/41062823
gnome-x-session provides good defaults which we really should not
override.
We have to add assertions to gdm.nix if the user specified one of those.
enableTCP must be configured through a gnome setting
dunno why we have terminate but it probably breaks stuff
We should expose configFile so we can use it from gdm module.
* x11 module: don't restart the display manager indefinitely
If the display managers crashes continuously in loops it prevents the
user from switching to the console and try to fix things. Especially
when using the "auto" display manager it can happen quite easily.
* x11 module: fix display manager restart timeouts
It takes more than 1 second to boot the X server.
---
Using the configure option relieves us of the patch and passing the path
via the env var in many places. Also the env var may not be inherited
when components like gdm spawn new sessions.
We were pulling in 44 MiB of fonts in the default configuration, which
is a bit excessive for headless configurations like EC2
instances. Note that dejavu_minimal ensures that remote X11-forwarded
applications still have a basic font regardless.
This ensures that "journalctl -u display-manager" does what you would
expect in 2016. However, the main reason is to ensure that our VM
tests show the output of the X server.
A slight problem is that with KDE user switching, messages from the
various X servers end up in the same place. However, that's an
improvement over the previous situation, where the second X server
would overwrite the /var/log/X.0.log of the first. (This was caused by
the fact that we were passing a hard-coded value for -logfile.)
Commit 98d9bba introduced this option as a nullOr type and it actually
checks whether null has been set and only appends -dpi if that's the
case. So let's actually set the default to null instead of 0.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
GnuPG 2.1.x changed the way the gpg-agent works, and that new approach no
longer requires (or even supports) the "start everything as a child of the
agent" scheme we've implemented in NixOS for older versions.
To configure the gpg-agent for your X session, add the following code to
~/.xsession or some other appropriate place that's sourced at start-up:
gpg-connect-agent /bye
GPG_TTY=$(tty)
export GPG_TTY
If you want to use gpg-agent for SSH, too, also add the settings
unset SSH_AGENT_PID
export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"
and make sure that
enable-ssh-support
is included in your ~/.gnupg/gpg-agent.conf.
The gpg-agent(1) man page has more details about this subject, i.e. in the
"EXAMPLES" section.
- if xserver.tty and/or display are set to null, then don't specify
them, or the -logfile argument in the xserverArgs
- For lightdm, we set default tty and display to null and we determine
those at runtime based on arguments passed. This is necessary because
we run multiple X servers so they can't all be on the same display
Ctrl+Alt+Backspace is usually enabled by default under X, and is a
keyboard shortcut that forcefully kills the current X server. This can
lead to data loss by users if accidentally pressed. This commit
introduces a new option, services.xserver.enableCtrlAltBackspace, that
is *disabled* by default. If set to true, the previous behavior can be
restored.
A similar decision was made by the Ubuntu team, and is documented here:
https://wiki.ubuntu.com/XorgCtrlAltBackspace
