nixos: opengl -> impure-drivers.opengl

[SomeoneSerge]

Description of changes

WIP. Following #275241 and #269475

The motivation is that it's extremely confusing for the new users when instructions for enabling something like CUDA involve setting hardware.opengl.enable and services.xserver.videoDrivers. The module's new name is meant to suggest that it's there to ensure integration with the addDriverRunpath, and it hopefully explains why/when the module has to be enabled (when we're forced to link drivers "impurely").

I think it'd also make sense to introduce an option like hardware.impure-drivers.cuda.enable, which would guide the user through the process of setting up the x11 or datacenter drivers (e.g. through assertions). I'd keep that for a separate PR

Thoughts? @jonringer @Kiskae @NixOS/cuda-maintainers @NixOS/rocm-maintainers

Things done

• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
  • nixosTests.quake3
  • nixosTests.tinywl
  • nixosTests.openarena
  • nixosTests.seatd
  • nixosTests.cagebreak
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[SomeoneSerge]

The target used to be a relative path ("opengl-driver"), now it's absolute ("/run/opengl-driver"). Shouldn't matter

[SomeoneSerge]

I think the most questionable decision is this. Maybe I shouldn't be introducing hardware.impure-drivers.opengl.enable at all?

[Kiskae]

Perhaps leave hardware.opengl.enable unchanged and make hardware.impure-drivers.opengl.enable depend on its value?

[SomeoneSerge]

H'm, how about I keep hardware.opengl.enable, drop hardware.impure-drivers.opengl, but add hardware.impure-drivers.enable = true to hardware.opengl's config?

[Tungsten842]

There is another attempt at this, not sure about the status: #158079.
I personally prefer hardware.drivers compared to hardware.impure-drivers.

[SomeoneSerge]

There is another attempt at this, not sure about the status: #158079.
I personally prefer hardware.drivers compared to hardware.impure-drivers.

Oooh right, I forgot about those. I'll close this for now, let's see where @jonringer and @Atemu are at?

[Atemu]

I haven't had much time to work on it and that likely won't change until April.

The main point I've been stuck on is that I wanted to build a better pattern to select packages that require multiple bitnesses. For example, right now we have this ugly package package32 pattern where you must set two options to change anything and it's possible to set those to different things (other than bitness) or forget to set one.

I've tried a few different things and for now the best I've come up with is building a "package selector" type which is a function from attrset -> drv that takes pkgs as an argument and returns a single package. In the implementation, you'd simply call it with the relevant package set.

Again, I haven't spent as much time on this as I had hoped.

[jonringer]

I've been hopign to do the refactor as well. But wanted to record it to demonstrate how to deprecate old options. just haven't had a single window to free time to do so.