Commit graph

8 commits

Author SHA1 Message Date
Nikolay Amiantov
522b4b4b4d primusLib: move to fetchFromGitHub (and fix strange checksum error) 2016-05-20 13:05:17 +03:00
Nikolay Amiantov
9b7edbeb2f primus: propagate stdenv to primusLibs 2016-03-31 19:52:33 +03:00
Nikolay Amiantov
56ffc2ecd2 primus: 1.0.0748176 -> 20151204, add useNvidia flag 2015-12-05 00:54:09 +03:00
Vladimír Čunát
21e3ff658a x11: replace its usage by xlibsWrapper directly
Scilab note: the parameters already had pointed to nonexistent dirs
before this set of refactoring. But that config wasn't even used by
default.
2015-09-15 12:08:24 +02:00
Pascal Wittmann
bb9e9cc3f8 Turned some meta.maintainers into lists 2015-05-14 19:09:43 +02:00
Nikolay Amiantov
a1440a679d primus: remove old workaround, fix LD_LIBRARY_PATH 2015-03-09 23:02:47 +03:00
Pascal Wittmann
f55545c0c9 fix maintainer information
s/maintainer/maintainers
2014-12-20 21:54:22 +01:00
Corey O'Connor
b2f3e10a35 Add primus and extend bumblebee to support 32bit/64bit multilib architectures.
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.
2014-11-29 16:42:00 -08:00