The switch from slim to lightdm in #30890 broke some nixos tests
because lightdm by default doesn't permit auto-login for root.
Override /etc/pam.d/lightdm-autologin to allow it.
Switch from slim to lightdm as the display-manager.
If plasma5 is used as desktop-manager use sdddm.
If gnome3 is used as desktop-manager use gdm.
Based on #12516
The wallpaper used is *structurally compatible* with the other one,
meaning that the logo is at the same location, and not bigger.
It has one drawback: the logo is brighter, which clashes with the grub
usage. This is to be fixed with new options in grub.
The default session might be found in `extraSessionFilePackages`, but it's not
viable to detect at evaluation time, so emit a warning.
In LightDM instead of checking `defaultSessionName` against
`displayManager.session.names` we rely on the assertions in
`desktopManager` and `windowMananger` and just check that there's at least one
default set. The second assertion could never actually be triggered.
This makes it easier to support a wider variety of .desktop session files. In
particular this makes it possible to use both the «legacy» sessions and upstream
session files.
We separate `xsession` into two parts, `xsessionWrapper` and `xsession`.
`xsessionWrapper` sets up the correct environment and then lauches the session's
Exec command (from the .desktop file), falling back to launching the default
window/desktopManager through the `xsession` script (required by at least some
nixos tests).
`xsession` then _only_ handles launching desktop-managers/window-managers defined
through `services.xserver.desktopManager.session`.
Pass gnome-session to extraSessionFilePackages, remove unnecessary environment variables, move the rest out of old session option, and then drop the option.
Previously, the mkDesktops function produced a flat package containing
session files in the top level. As a preparation for introduction of
Wayland sessions, the files will now be placed to $out/share/xsessions.
This adds configuration options which automate the configuration of NVIDIA Optimus using PRIME. This allows using the NVIDIA proprietary driver on Optimus laptops, in order to render using the NVIDIA GPU while outputting to displays connected only to the integrated Intel GPU. It also adds an option for enabling kernel modesetting for the NVIDIA driver (via a kernel command line flag); this is particularly useful together with Optimus/PRIME because it fixes tearing on PRIME-connected screens.
The user still needs to enable the Optimus/PRIME feature and specify the bus IDs of the Intel and NVIDIA GPUs, but this is still much easier for users and more reliable. The implementation handles both the X configuration file as well as getting display managers to run certain necessary `xrandr` commands just after X has started.
Configuration of commands run after X startup is done using a new configuration option `services.xserver.displayManager.setupCommands`. Support for this option is implemented for LightDM, GDM and SDDM; all of these have been tested with this feature including logging into a Plasma session.
Note: support of `setupCommands` for GDM is implemented by making GDM run the session executable via a wrapper; the wrapper will run the `setupCommands` before execing. This seemed like the simplest and most reliable approach, and solves running these commands both for GDM's X server and user X servers (GDM starts separate X servers for itself and user sessions). An alternative approach would be with autostart files but that seems harder to set up and less reliable.
Note that some simple features for X configuration file generation (in `xserver.nix`) are added which are used in the implementation:
- `services.xserver.extraConfig`: Allows adding arbitrary new sections. This is used to add the Device section for the Intel GPU.
- `deviceSection` and `screenSection` within `services.xserver.drivers`. This allows the nvidia configuration module to add additional contents into the `Device` and `Screen` sections of the "nvidia" driver, and not into such sections for other drivers that may be enabled.
To update the plasma start menu `kbuildsyscoca5` needs to be executed.
There are several people complaining about missing applications in their
plasma start menu.
This patch adds a activationScript for plasma, that runs
`kbuildsyscoca5` for each user that has `isNormalUser` == `true`.
Fixes issue #33231 and makes it possible to enable Plasma and KDE at the same time.
Previously, this worked like this:
- The gdk-pixbuf package comes with a cache file covering the modules bundled
with gdk-pixbuf.
- The librsvg package comes with a cache covering modules from gdk-pixbuf as
well as librsvg.
- plasma5 and xfce modules set the environment variable GDK_PIXBUF_MODULE_FILE
to the one from librsvg, so that SVG was supported in addition to the
formats supported by gdk-pixbuf. However if both were enabled a configuration
conflict would result (despite setting to the same value).
While this sort of worked (ignoring the conflict which perhaps could be hacked
around), it is unscalable and a hack, as there would be a real problem when one
wanted to add a third package that supports additional image formats.
A new NixOS module (gdk-pixbuf) is added with a configuration option
(modulePackages) that other modules use to request specific packages to be
included in the loaders cache. When any package is present in the list, the
module generates a system-wide loaders cache which includes the requested
packages (and always gdk-pixbuf itself), and sets the environment variable
GDK_PIXBUF_MODULE_FILE to point to the generated cache file.
The plasma5 and xfce modules are updated to add librsvg to modulePackages
instead of setting GDK_PIXBUF_MODULE_FILE.
Note that many packages create wrappers that set GDK_PIXBUF_MODULE_FILE,
some directly to the one from librsvg. Therefore this change does not
change the existing hack in the librsvg package which ensures that
file is generated. This change aims only to solve the conflict in the
global environent variable configuration.
toPath has confusing semantics and is never necessary; it can always
either just be omitted or replaced by pre-concatenating `/.`. It has
been marked as "!!! obsolete?" for more than 10 years in a C++
comment, hopefully removing it will let us properly deprecate and,
eventually, remove it.
The original idea behind this change (described in ticket #11064) was to
improve the assertions to avoid that users of the X server accidentally
forget to configure a DM or WM.
However this caused several issues with setups that require X, but no DM
or WM. The keymap testcases became instable as well as now disabling DMs
needs to be done explicitly.
(see https://github.com/NixOS/nixpkgs/pull/31268#issuecomment-347080036)
In the end the idea behind the change and #11064 was obviously a
mistake, so reverting it completely for now should be fine.
X libraries in LD_LIBRARY_PATH seem to not be needed anymore.
I've tracked this addition as far as I could
(02cef04c81) and they seem to be added for unfree
NVIDIA and ATI drivers but at least for NVIDIA they are not needed anymore. We
can add them with patchelf instead if it turns out to be the case with ATI.
Currently broken on NixOS due to hardcoded modprobe binary path (see
bug #30756 from Oct 2017), no activity on a proposed fix for months.
As the protocol is terribly broken anyways, let's better remove it
completely, and not talk about anymore ;-)
Closes#30756.
Commit 1f2b938 introduced a module for evilwm as a window-manager, but
did not actually add this module to window-manager's default.nix which
renders it useless.
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
This makes memoization of Nixpkgs evaluation less effective, since
some Nixpkgs invocations may have 'config = {}' while others may have
'config = { xorg = {}; }'.
Instead set 'config = {}'.
mate-control-center depends on mate-settings-daemon, but the later needs
gsettings schemas provided by the former. To fix this the gsettings schema
path from mate-control-center is added to XDG_DATA_DIRS at session
startup.
