| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
/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 eef9a8ac2a30b495ff7184382ed0dbd73b3b88e4. 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.
|
| |
|
|
| |
CC: #5070.
|
| | |
|
| | |
|
| |
|
|
| |
blacklist the radeon driver when ati_unfree is installed.
|
| | |
|
| |
|
|
|
| |
I'm sorry; I didn't notice Eelco renamed the option.
My dry-run didn't catch that one with nvidia driver, no idea why.
|
| |
|
|
| |
so all users get this variable, thanks to work from #2692.
|
| | |
|
| |
|
|
| |
LD_LIBRARY_PATH. Fix that, fix bumblebee module loading and make the socket group configurable
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Fixes #2242 in a different way (cleaner, I hope).
|
| |
|
|
| |
Close #2200. Thanks to @cpages for suggesting and testing this.
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Signed-off-by: Shea Levy <shea@shealevy.com>
|
| | |
|
| | |
|
| |
|
|
|
| |
It's redundant because you can (and should) specify an option type, or
an apply function.
|
| |
|