feature request: nixGL integration

michaelCTS commented 1 year ago

Description

https://github.com/NixOS/nixpkgs/issues/9415 which tracks the problem of libGL in nix on non NixOS systems has been open for about 8 years now. Luckily, nixGL exists which provides a wrapper around programs that require openGL (games, gpu accelerated terminals, browsers, etc.).

It would be great if there were an option to wrap all GUI applications or user-specified applications with nixGL. I'm assuming there's a generic way and bepoke method per application. Care should be taken for the desktop entries to call with nixGL

workarounds.opengl.packages

Is given a list of package names (or maybe packages themselves) that it has to wrap

lib.wrapWithLibGL

It could be a wrapper that takes a package and spits out another which is called by libGL.

Smona commented 1 year ago

I posted an implementation I've been using to wrap programs with nixGL, which i think could be general enough to be provided as a utility on lib, and wouldn't add a hard nixGL dependency to home manager. With a little more work (to null out the buildInputs on the wrapper derivation), it could be completely transparent, and it still allows home manager to further override packages like firefox and emacs. Hopefully that can provide some inspiration?

teto commented 1 year ago

a good first step would be to have nixGL in nixpkgs

stale[bot] commented 1 year ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

viraptor commented 1 year ago

hold on a moment stale-bot!

izelnakri commented 1 year ago

I've accomplished the (nixGL packageName) behavior after utilizing the hacks of @Smona @robhanlon22 here after researching this issue & trials for about a week. Seems absolutely necessary to have this feature as a lib.nixGL function @rycee for non-nixOS systems.

michaelCTS commented 1 year ago

Can you create a PR @izelnakri ?

rycee commented 1 year ago

Maybe something that would be good to have under the targets.genericLinux namespace?

stale[bot] commented 10 months ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

viraptor commented 10 months ago

This still needs solving.

diegodorado commented 9 months ago

would love to see this implemented in home manager itself

stale[bot] commented 6 months ago

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

michaelCTS commented 6 months ago

Still a valid issue

michaelCTS commented 6 months ago

For those following, I created a PR. You can test it by amending your home.nix

{ config, pkgs, ...}:
let
  michaelCtsHm = builtins.fetchTarball "https://github.com/michaelCTS/home-manager/archive/refs/heads/feat/add-nixgl-workaround.zip";
  nixGlModule = "${michaelCtsHm}/modules/misc/nixgl.nix";
in
{
  imports = [ nixGlModule ];
  workarounds.nixgl.packages = with pkgs; [
    # A package of your choice here. alacritty is just an example
    { pkg = alacritty; }
  ];
}

See the the nixgl module source (either in the nix store or the PR itself) for the objects to pass to workaround.nixgl.packages.

With that, you should be able to open the package in your desktop environment. I tested it in openbox, but it should work with KDE, Gnome and others as well.

joefiorini commented 6 months ago

@michaelCTS just tried this and ran into an issue. If I have programs.kitty.enable = true then I get a collision since it's trying to add the binary from both the main kitty package and the wrapped one. But if I don't use the enable flag then I don't get home-manager's configuration abilities, right? Is it possible to have this be part of the program configuration (like programs.kitty.enableNixgl = true or something?)

Smona commented 6 months ago

@michaelCTS thank you for creating that PR! you've inspired me to finally put together my own utilizing the wrapper I posted near the top of this issue. I hope there are no hard feelings for waiting until you posted yours :sweat_smile: I am not immune to Cunningham's Law, but ultimately I hope the implementation that gets merged is the one that works best for everyone.

@joefiorini if you want you can give #5355 a try. All you should need to do is set the nixGL.prefix option, since I've integrated kitty by default in the PR.

michaelCTS commented 6 months ago

@Smona I don't mind. It'll be up to the maintainers to decide which solution they prefer. It's just about time this issue is resolved. Whichever solution is chosen doesn't matter to me. It can always be iterated upon later and IMO there shouldn't be a focus on perfection, otherwise people will keep talking and never do anything.

I modified my PR to make the wrapper available as well. We have different approaches of wrapping the package, so I think that will be the major difference. The one you use from stackoverflow does double the disk-space usage of the package IINM whereas what I used from the nixos wiki simply links to the existing package and writes one new bin.

Smona commented 6 months ago

@michaelCTS (see edit below) ~~great point about disk usage. I had misremembered it using symlinks, but that's certainly a downside.~~

I only have strong opinions about the API for HM users (which is harder to iterate on), not the specific wrapper used. I originally tried using runCommand/makeWrapper, but I found that the result could not be integrated with HM modules because it did not include attributes from the original derivation. If your wrapper accomplishes that, such that wrapped packages can be used just like the original derivation, then it's certainly the better candidate :raised_hands:. If not, I think the approach in my PR could be made to work with symlinks (it's unlikely I'll have time to do that myself).

Feel free to rip any other ideas from that PR, glad it could be of some help! In particular, I think these ideas are worth consideration:

Not adding packages to home.packages via a package list settings, but instead letting users pass wrapped packages into home.packages or program modules themselves. This way package specifications are not duplicated.
Wrapping all binary outputs for wrapped derivations, since there is a decent chance a package which needs GPU for one binary may need it for other binaries. This would also simplify the interface of lib.nixGl.wrap. There doesn't seem to be any way in your current PR to wrap multiple binaries in a single package.
Making the wrapper return the original derivation (no-op) if targets.genericLinux.nixgl.src is not set. This would allow modules to wrap their packages by default (but this one will be easy to iterate on later)

Thanks again for pushing this forward!

EDIT: I looked into it again and the wrapper in my PR does actually symlink the non-bin outputs, because -s is passed to cp, which makes it use symlinks. From man cp:

       -s, --symbolic-link
              make symbolic links instead of copying

So there is no disk usage downside to that wrapper.

michaelCTS commented 6 months ago

Your right @Smona! I didn't see the -s. Maybe using ln -s would be better as a -s can be easily missed but ln is very commonly used for linking.

I'll close my PR in favor of yours. You'll probably be a more active maintainer. Hopefully it can be merged quickly.

Cheers

Smona commented 6 months ago

@michaelCTS I agree that ln -s would be clearer, since even I got a bit turned around by the cp -rs call! I think I remember the cp -rs being important for some reason, either resetting the mode with --no-preserve mode and/or because it links differently: rather than creating links to the top-level directory like ln -s does, it actually creates the directory tree in the destination, and individually softlinks each file (which actually does introduce a very small disk usage disadvantage due to the increased number of inodes). I wish I had left a comment, because it could be totally unnecessary and just a copy/paste that I assumed to be useful.

In the interest of getting the initial implementation merged I might hold off on further refactoring on that branch if the current strategy looks good to maintainers, but changing the linking strategy is absolutely something we can iterate on in the future without breaking changes :)

giggio commented 5 months ago

For anyone who wants to test #5355, I couldn't find an extensive way to do this, and I wanted to use Kitty, so this is what I did. I am using home-manager with flakes. I am new to all of this, so it might be obvious to many of the ones reading this, but it was not obvious to me. You can see the working sample at my dotfiles repo: https://github.com/giggio/dotfiles/blob/main/config/home-manager/home.nix https://github.com/giggio/dotfiles/blob/main/config/home-manager/flake.nix And this is is the commit with the diffs: https://github.com/giggio/dotfiles/commit/c5e690191523ea19615855547499d35c4ebbf7b1

I added NixGL to my input on flake.nix:

    nixGL = {
      url = "github:nix-community/nixGL/310f8e49a149e4c9ea52f1adf70cdc768ec53f8a";
      inputs.nixpkgs.follows = "nixpkgs";
    };

In home.nix:

I added @Smona's patch to my imports:

  imports = [
    (builtins.fetchurl {
      url = "https://raw.githubusercontent.com/Smona/home-manager/nixgl-compat/modules/misc/nixgl.nix";
      sha256 = "74f9fb98f22581eaca2e3c518a0a3d6198249fb1490ab4a08f33ec47827e85db";
    })
  ];

I added an alias for nixGL, like so:

let
  nixGLIntel = inputs.nixGL.packages."${pkgs.system}".nixGLIntel;
#...

I installed it by adding nixGLIntel to packages. And, in packages, kitty was changed to (config.lib.nixGL.wrap kitty).

And I added the option:

  nixGL.prefix = "${nixGLIntel}/bin/nixGLIntel";

This changed my kitty executable, which now looks like so:

$ cat `which kitty`
#!/nix/store/306znyj77fv49kwnkpxmb0j2znqpa8bj-bash-5.2p26/bin/bash
exec -a "$0" /nix/store/vbhv6ijhy65ma7z8i67dkci7ddiwzvrf-nixGLIntel/bin/nixGLIntel /nix/store/cmkk0l1qs0hph06nlp0ji1arkpxp44xs-kitty-0.34.1/bin/kitty "$@"

I hope this helps someone.

@Smona I hope your PR is merged soon so I can remove the customizations. Thanks for that!

o-dasher commented 5 months ago

@giggio thank you so much for this little tutorial, everything works as expected!

timoleistner commented 3 months ago

Somehow @giggio's approach gives me this error

error: hash mismatch in file downloaded from 'https://raw.githubusercontent.com/Smona/home-manager/nixgl-compat/modules/misc/nixgl.nix':
         specified: sha256:1nw5gs14gv1kiyhb82j9n6gj96317l58ll9w5v5fm095yacgpybl
         got:       sha256:0g5yk54766vrmxz26l3j9qnkjifjis3z2izgpsfnczhw243dmxz9

any ideas?

Edit: Alright fixed it by obtaining the new sha256 sum by doing curl https://raw.githubusercontent.com/Smona/home-manager/nixgl-compat/modules/misc/nixgl.nix | sha256sum

(its e9f7da06111c7e669dbeef47f1878ed245392d4e7250237eaf791b734899be3c)

Now I get :

error: attribute 'currentTime' missing
       at /nix/store/wnf3rly6jbw4ywqhzgn0vl6lk8hwgkg3-source/nixGL.nix:223:18:
          222|           # Add an impure parameter to force the rebuild on each access.
          223|           time = builtins.currentTime;
             |                  ^
          224|           preferLocalBuild = true;

Ok thats what I get for trying something different and trying nixGLDefault works with nixGLIntel.

Edit 2: Now I have the same problem @joefiorini mentioned with having colliding packages when wayland.windowManager.hyprland.enable = true I have colliding packages. If setting this option to false the config for this package is not used.

Edit 3: Everything works now when adding the wrapped hyprland to wayland.windowManager.hyprland.package, instead of including it in home.packages. Thanks to @Smona.

diegoroccia commented 2 weeks ago

Thank you all for the great work! I have been following the various threads, patches and so on, but now I am a bit lost how to get rid of those since, as far as I read, home-manager supports nixGL natively. Where can I find a doc page with up to date info?

exzombie commented 2 weeks ago

As always, you can run the home-manager-help command to open the manual for the version of HM that you are currently using. The latest docs are also available online. Don't forget to take a look at the docs for individual configuration options as well 😄

moritayasuaki commented 1 week ago

@Smona @giggio Hi, I have always used @Smona 's nixgl.nix in my home-manager/home.nix, and now the nixgl wrapper is merged into home-manager, great! But now I have trouble with making it work in a new way because I've gotten too used to @giggio 's solution (if anyone has the same situation please let me know). Do you have any suggestions? Here are excerpts from my home.nix and flake.nix:

home-manager/flake.nix

{
  description = "Home Manager configuration of yasuaki";

  inputs = {
    # Specify the source of Home Manager and Nixpkgs.
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    home-manager.url = "github:nix-community/home-manager";
    home-manager.inputs.nixpkgs.follows = "nixpkgs";
    nixGL.url = "github:guibou/nixGL";
  };

  outputs = { nixpkgs, home-manager, nixGL, ...}: let
    system = "x86_64-linux";
    pkgs = import nixpkgs {
      inherit system;
      overlays = [
        nixGL.overlay
      ];
      config.allowUnfree = true;
      config.permittedInsecurePackages = [
      ];
    };
  in
  {
    homeConfigurations."yasuaki" = home-manager.lib.homeManagerConfiguration {
      inherit pkgs;
      # Specify your home configuration modules here, for example,
      # the path to your home.nix.
      modules = [
        ./home.nix
        ({ ... }: {
          nixGL.prefix = "${pkgs.lib.getExe pkgs.nixgl.nixGLIntel}";
        })
      ];
    };
  };
}

home-manager/home.nix

{ config, pkgs, lib, ... }:
{
  imports = [
    (builtins.fetchurl {
      url = "https://raw.githubusercontent.com/Smona/home-manager/nixgl-compat/modules/misc/nixgl.nix";
      sha256 = "01dkfr9wq3ib5hlyq9zq662mp0jl42fw3f6gd2qgdf8l8ia78j7i";
    })
  ];

  # Home Manager needs a bit of information about you and the paths it should
  # manage.
  home.username = "yasuaki";
  home.homeDirectory = "/home/yasuaki";

  # This value determines the Home Manager release that your configuration is
  # compatible with. This helps avoid breakage when a new Home Manager release
  # introduces backwards incompatible changes.
  #
  # You should not change this value, even if you update Home Manager. If you do
  # want to update the value, then make sure to first check the Home Manager
  # release notes.
  home.stateVersion = "23.05"; # Please read the comment before changing.

  # The home.packages option allows you to install Nix packages into your
  # environment.
  home.packages =
    let
      cui-apps = (with pkgs; [
        fd
        ripgrep
        elan
      ]);
      cui-apps-stable = (with pkgs; [
      ]);
      gui-apps = (with pkgs; [
        evince
        bitwarden
      ]);
    in
    cui-apps ++
    lib.lists.forEach gui-apps config.lib.nixGL.wrap;
}

moritayasuaki commented 1 week ago

It’s now working property. I just needed to name the flake input nixgl by using "github:nix-community/nixGL" in flake.nix and pass it to Home Manager via extraSpecialArgs (which is written in the description). I think it would be helpful to add an example of flake.nix in the description. For newbies, it's a bit difficult to identify what nixgl is, and to understand the role of nixGL in Home Manager versus nixgl from the "github:nix-community/nixGL" flake.

The above example assumes a flake-based setup where nixgl was passed from the flake.

I put a shortened version of my flake.nix

{
  description = "Home Manager configuration of yasuaki";

  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    home-manager.url = "github:nix-community/home-manager";
    home-manager.inputs.nixpkgs.follows = "nixpkgs";
    nixgl.url = "github:nix-community/nixGL";
    nixgl.inputs.nixpkgs.follows = "nixpkgs";
  };

  outputs = { nixpkgs, home-manager, nixgl, ...}: let
    system = "x86_64-linux";
    pkgs = import nixpkgs {
      inherit system;
      config.allowUnfree = true;
    };
  in
  {
    homeConfigurations."yasuaki" = home-manager.lib.homeManagerConfiguration {
      inherit pkgs;
      modules = [
        ./home.nix
      ];
      extraSpecialArgs = {
        inherit nixgl;
      };
    };
  };
}

nix-community / home-manager

feature request: nixGL integration #3968

Description