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.
By default, OnlyKey device (https://crp.to/p/) won't work on Linux (and,
therefore, NixOS). This is unintuitive and requires one to search for a
solution in the documentation.
This change allows one to enable OnlyKey device support directly from
their NixOS configuration.
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
* digitalbitbox: init at 2.2.2
The commits that lead to this have been squashed from independent
commits see branch @vidbina/add/digitalbitbox-wip that did the
following:
- 0a3030fa0ec digitalbitbox: init at 2.2.2
- c18ffa3ffd4 digitalbitbox: moved meta to EOF
- 0c5f3d6972a digitalbitbox: using preConfigure + configureFlags
- a85b1dfc3fd digitalbitbox: nativeBuildInputs
- 90bdd35ef0f digitalbitbox: autoreconfHook
- 91810eea055 digitalbitbox: default installPhase & makeWrapper
- 90e43fb7e2a digitalbitbox: doc rm $PWD hack & printf-tee deal
- fd033b2fe5a digitalbitbox: cleanup, alphabetically sort attrs
- c5907982db3 digitalbitbox: added hardware module
- 88e46bc9ae0 digitalbitbox: added program module
- amend to change name: dbb-app -> digitalbitbox
- amend to add install instructions based on feedback
(https://github.com/NixOS/nixpkgs/pull/33787#issuecomment-362813149)
- amend to add longDescription
- moved program to its own dir
- overridable udev rules handling
- added docs to manual
- added package attr to program module
- added package attr to hardware module
* digitalbitbox: use libsForQt5.callPackage
All available options were just enabling
hardware.enableRedistributableFirmware. There were nix files without
modules which weren't referenced anywhere.
Due the recent inclusion of broadcom-bt-firmware in enableAllFirmware,
it was required to set `nixpkgs.config.allowUnfree` to obtain the full
list. To make this dependency more explicit an assertion is added and an
alternative option `enableRedistributalFirmware` is provided to only
obtain firmware with an license allowing redistribution.
This PR adds support for ```iio-sensor-proxy``` used by GNOME v3 and
others for reading data from the accelerometer, gps, compass and similar sensors
built into some relatively recent laptops.
Additionally, there is a NixOS module exposed via hardware.sensor.iio
for enabling services, udev rules and dbus services.
ckb is a driver for Corsair keyboards/mice. It also contains a graphical tool for configuring their LED backlight settings.
The driver is implemented as a userland daemon. A NixOS module is included that runs this as a systemd service.
...instead of mesa_noglu.out. Closures of systems remain unchanged,
as both are in (and the .out output is very small anyway).
This is to make sure that we use lib*GL* that aren't slowed down by grsecurity.
The pre-sleep service exits if any command fails. Unloading facetimehd
without it being loaded blocks subsequent commands from running.
Note: `modprobe -r` works a bit better when unloading unused modules,
and is preferrable to `rmmod`. However, the facetimehd module does not
support suspending. In this case, it seems preferable to forcefully
unload the module. `modprobe` does not support a `--force` flag when
removing, so we are left with `rmmod`.
See:
- https://github.com/NixOS/nixpkgs/pull/14883
- https://github.com/patjak/bcwc_pcie/wiki#known-issues
This commit adds the firmware for the Intel 2200BG wireless cards for
the ipw2200 kernel module. Also it changes the
networking.enableIntel2200BGFirmware option to set it as
hardware.firmware since firmware-linux-nonfree does not contain the
appropiate firmware anymore. Also hardware.enableAllFirmware does enable
the intel2200BGFirmware now.
This is essentially what's been done for the official NixOS build slaves
and I'm using it as well for a few of my machines and my own Hydra
slaves.
Here's the same implementation from the Delft server configurations:
f47c2fc7f8/delft/common.nix (L91-L101)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Added configurations to `bumblebee` package to easy multiple monitors on Optimus
machines.
The behaviour of the default `bumblebee` package hasn't change, so this change
is backwards compatible. Users who want to connect a monitor to their discrete
card should use the package `bumblebee_display` instead.
Also added new configuration option to nixos bumblebee module:
```
hardware.bumblebee.connectDisplay = true
```
will enable the new configuration, but the default is still false.
/run/opengl-drivers should contain only libGL-related libraries, not
stuff like udev. Injecting anything into LD_LIBRARY_PATH is dangerous
because it can break applications that expect a different version of
the library.
Caused by eef9a8ac2a. Fixes#5371.
Using primusrun will work as expected in a multilib environment. Even if the initial program
executes a antoehr program of the another architecture. Assuming the program does not modify
LD_LIBRARY_PATH inappropriately.
This does not update virtualgl for seemless multilib. I was unable to get a mixed 64/32 bit
environment to work with VirtualGL. The mechanism VirtualGL uses to inject the fake GL library would
fail if both 32bit and 64 bit libraries were in the environment. Instead the bumblebee package
creates a optirun32 executable that can be used to run a 32bit executable with optimus on a 64 bit
host. This is not created if the host is 32bit.
For my usage, gaming under wine, the primusrun executable works as expected regardless of
32bit/64bit.
Previously all card-specific stuff was scattered across xserver.nix
and opengl.nix, which is ugly. Now it can be kept together in a single
card-specific module. This required the addition of a few internal
options:
- services.xserver.drivers: A list of { name, driverName, modules,
libPath } sets.
- hardware.opengl.package: The OpenGL implementation. Note that there
can be only one OpenGL implementation at a time in a system
configuration (i.e. no dynamic detection).
- hardware.opengl.package32: The 32-bit OpenGL implementation.
Fixes#2379.
The new name was a misnomer because the values really are X11 video
drivers (e.g. ‘cirrus’ or ‘nvidia’), not OpenGL implementations. That
it's also used to set an OpenGL implementation for kmscon is just
confusing overloading.
Using pkgs.lib on the spine of module evaluation is problematic
because the pkgs argument depends on the result of module
evaluation. To prevent an infinite recursion, pkgs and some of the
modules are evaluated twice, which is inefficient. Using ‘with lib’
prevents this problem.
* Bump bumblebee to 3.2.1
* Remove config.patch - options it added can be passed to ./configure now
* Remove the provided xorg.conf
Provided xorg.conf was causing problems for some users,
and Bumblebee provides its own default configuration anyway.
* Make secondary X11 log to /var/log/X.bumblebee.log
* Add a module for bumblebee
