20 Oct 2024 |
K900 | And that's obviously not arch specific | 20:33:39 |
Atemu | I think we won't get around special-casing proprietary drivers that have a 32bit attr | 20:34:06 |
Atemu | Best we can do is standardise this attr | 20:34:22 |
K900 | No | 20:34:31 |
K900 | I just had the horriblest ideaest | 20:34:37 |
K900 | hardware.graphics.extraPackages = pkgs: if pkgs.stdenv.is64bit then [ config.hardware.nvidia.package ] else [ config.hardware.nvidia.package.lib32 ] | 20:35:04 |
K900 | That doesn't solve the "how do we know if this package is 32-bit" issue though | 20:36:14 |
Atemu | Oh neat idea we could make drivers have a drivers output/attr (that was in my original design anyways) and then make the nvidia package expose that attr in this way | 20:36:25 |
K900 | I guess we can set passthru.is32BitTrustMeBro = true | 20:36:35 |
K900 | In reply to@atemu12:matrix.org Oh neat idea we could make drivers have a drivers output/attr (that was in my original design anyways) and then make the nvidia package expose that attr in this way But that won't let you make it arch specific | 20:37:05 |
K900 | Is the problem | 20:37:07 |
K900 | Like the problem with Nvidia is that we can't get from root pkgs to the correct Nvidia just by attrpath | 20:38:09 |
K900 | No adding of outputs changes that | 20:38:38 |
Atemu | Hm, and we're selecting it from some variable too, not a pkgs attr | 20:38:50 |
K900 | Yep | 20:38:56 |
K900 | Unless we change hardware.nvidia to take a version string | 20:39:14 |
K900 | Instead of a package name | 20:39:16 |
K900 | But that's so fucked up | 20:39:28 |
K900 | And I don't want to own that change | 20:39:33 |
K900 | Or anything else Nvidia related for that matter | 20:40:20 |
Atemu | Okay perhaps instead of a drivers attr, perhaps we could make them have a driversFor function that takes a system and returns a drivers attr | 20:40:30 |
K900 | Doing that just for Nvidia though | 20:40:59 |
Atemu | OTOH we might have a hardware.drivers.mesa.package option too | 20:41:02 |
Atemu | Yeah | 20:41:03 |
K900 | hardware.drivers.mesa.package should just be a function the same way | 20:41:35 |
K900 | If we ever get one | 20:41:37 |
K900 | Because for Mesa we can just do that | 20:41:51 |
K900 | Because there's no coupling to the kernel | 20:41:57 |
K900 | Hmm | 20:42:08 |
K900 | I wonder if we can flip it around | 20:42:12 |