nix: Add Nix Flake support

[shymega]

This commit consists of the following changes:

• default.nix/shell.nix
  This allows for legacy Nix tooling like nix-build/nix-shell to work.
• flake.nix
  This is for the (new) Nix Flake support.
• flake.lock
  As above, but for tracking Flake inputs.
• .envrc
  This allows for a fully self-contained developer environment to be
  setup with Nix.
• nix/default.nix
  This is the main package derivation. Both this repo & Nixpkgs are
  derived from the same codebase.

Closes: #38

[shymega]

I finally had delivery of a VITURE Pro today, after being lost, but I've tested my Flake with the glasses, and it does seem to work - about to test mouse control shortly.

[shymega]

The long-term steps would be to upstream the derivation (+ Breezy) to Nixpkgs, as well as a Nix module, and a CI workflow for this repo (+ Breezy).

[wheaney]

@shymega can you let me know if this is ready? Also can you have another Nix user test and sign off on it?

[deephack1982]

As for another Nix user I'm here. I actually already put together a Nix package for the driver but this one looks further along than mine so will test. Will post my findings here in the next few days.

[deephack1982]

Okay so it builds and I can install the driver but I seem to be having some issues connecting to my Viture Pro glasses. I get the following in the xrDriver log.

2025-04-28 22:02:40.853 Project version: 1.1.0
2025-04-28 22:02:40.854 Driver is disabled
2025-04-28 22:02:40.855 Using hardware id b50796e372423c376420886322d8fee0f49f3f28fb6c8a90a08dda81f1a0599f
2025-04-28 22:02:40.856 Feature sbs granted.
2025-04-28 22:02:40.856 Feature smooth_follow granted.
2025-04-28 22:02:40.856 Feature productivity_basic granted.
2025-04-28 22:02:40.856 Starting up XR driver
2025-04-28 22:02:40.857 Found device with vendor ID 0x35ca and product ID 0x101d
2025-04-28 22:02:40.857 Found device with vendor ID 0x35ca and product ID 0x101d
2025-04-28 22:03:07.988 Driver has been re-enabled
2025-04-28 22:03:09.991 Device driver connection attempt failed
2025-04-28 22:03:09.991 Retrying driver connection in 1 second
2025-04-28 22:03:12.992 Device driver connection attempt failed
2025-04-28 22:03:12.992 Retrying driver connection in 1 second
2025-04-28 22:03:15.994 Device driver connection attempt failed
2025-04-28 22:03:15.994 Retrying driver connection in 1 second
2025-04-28 22:03:16.395 Driver has been disabled

In kernel logs I have this when I plug in the glasses.

[ 187.344812] usb 2-1: new full-speed USB device number 7 using xhci_hcd
[ 187.470047] usb 2-1: New USB device found, idVendor=35ca, idProduct=101d, bcdDevice= 2.00
[ 187.470064] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 187.470070] usb 2-1: Product: VITURE Pro XR Glasses
[ 187.470076] usb 2-1: Manufacturer: VITURE Pro
[ 187.470080] usb 2-1: SerialNumber: 205A308E4742
[ 187.474054] hid-generic 0003:35CA:101D.0003: hiddev96,hidraw0: USB HID v1.11 Device [VITURE Pro VITURE Pro XR Glasses] on usb-0000:00:14.0-1/input0
[ 187.475272] hid-generic 0003:35CA:101D.0004: hiddev97,hidraw1: USB HID v1.11 Device [VITURE Pro VITURE Pro XR Glasses] on usb-0000:00:14.0-1/input1
[ 187.475951] cdc_acm 2-1:1.2: ttyACM0: USB ACM device

So the glasses are being recognised by the kernel. For refernce this is NixOS unstable running kernel 6.12.24.

[wheaney]

You might want to try rebasing this branch, as main is on 2.x and may include a fixing change for that. But first you could try to see if this persists after a restart. And try not having the glasses plugged in on boot.

[shymega]

Yes, this isn't a problem with my package. I did raise it with @wheaney over Discord, but the solution isn't clear yet.

Have you put the udev rules in your services.udev.extraRules? I could add that as an output to the package...

[shymega]

I'll rebase this now.

[deephack1982]

Tried a restart and adding the udev rules but still getting the same output for now.

[shymega]

@deephack1982 Try now :-)

I'm also working on a Guix package, if that's of interest to anyone following this thread.

[deephack1982]

New one gives me a build failure with the following make output.

[ 58%] Building C object CMakeFiles/xrDriver.dir/src/ipc.c.o
[ 60%] Building C object CMakeFiles/xrDriver.dir/src/multitap.c.o
[ 62%] Building C object CMakeFiles/xrDriver.dir/src/outputs.c.o
/build/xrlinuxdriver-src/src/ipc.c: In function 'setup_ipc_value':
/build/xrlinuxdriver-src/src/ipc.c:78:5: error: implicit declaration of function 'close'; did you mean 'pclose'? []
78 | close(fd);
| ^~~~~
| pclose
make[2]: *** [CMakeFiles/xrDriver.dir/build.make:261: CMakeFiles/xrDriver.dir/src/ipc.c.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:253: CMakeFiles/xrDriver.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

Tested and this is present on wheaneys main branch if I do a basic cmake and make so nothing up with the flake.

2.0.5 tag builds cleanly however.

[shymega]

Yeah, the Flake builds from the Git repo, but I didn't have any issues building.

[shymega]

How did you invoke the Flake?

[deephack1982]

I allow the direnv to load and then issue the nix-build command in the root.

[shymega]

Ah, I can reproduce it now. It was cached.

Try building from shymega/nix-flake-support-v2.0.5 on my fork, and then we can establish if the Nix package can fix the issues with the glasses - I experienced this too.

[deephack1982]

That branch builds fine but the driver output is still the same. Connection attempt fails and then it retries in a loop.

[deephack1982]

Quick note by the way as I was looking into the udev rules and how to package them. As per this thread it seems that any package containing $out/lib/udev/rules.d/ will be picked up by the system automatically. Actually not quite automatically, you need to specify sevices.udev.package = [ mypackage ]; but anyway.

https://discourse.nixos.org/t/how-to-create-files-in-the-etc-udev-rules-d-directory/11929/13

[shymega]

That branch builds fine but the driver output is still the same. Connection attempt fails and then it retries in a loop.

I found this happened for me too, but not on the first connection cycle of my VITURE Pros.

[shymega]

Quick note by the way as I was looking into the udev rules and how to package them. As per this thread it seems that any package containing $out/lib/udev/rules.d/ will be picked up by the system automatically. Actually not quite automatically, you need to specify sevices.udev.package = [ mypackage ]; but anyway.

discourse.nixos.org/t/how-to-create-files-in-the-etc-udev-rules-d-directory/11929/13

Ah, that's good to hear. So the way I've packaged it makes this seamless.

[deephack1982]

Somewhat related, I'm working on a Breezy-Desktop package also. I have the following attached which builds but shows an error on run.

breezy-desktop.nix.txt

[wheaney]

For that you'll just need to disable the verification that the UI app does. See how the AUR setup does it by injecting --skip-verification into the desktop file: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=breezy-desktop-gnome-git

[deephack1982]

That worked immediately. Fantastic, now I'll spend some time tidying all of this up. Eventually it would be good to have the overlay load the needed files directly from Github. Then it could be just a couple of lines of config in configuration.nix to get everything working. For now though it can be manually installed and run.

[shymega]

I may have some fundamental misunderstanding when it's coming to the systemd unit and udev rules here. I'm not convinced that for me either are being applied. I manually run xrDriver you see to do my tests. This is my workflow, let me know if I'm doing something stupid.

I cd into the repo, give the direnv time to load and then run nix-build to make the package and have it put into /nix/store. I then run nix-env --install <nix store location> to install it into my system and at least the bin and libs seem to get added. However the systemd unit is not present if I run sudo systemctl list-units and sudo systemctl status xr-driver returns could not be found.

The derivation explains it - the systemd service is a user service, and you're executing the system systemctl manager.

Try systemctl --user $cmd $args.

[shymega]

@deephack1982 Try now :-)
I'm also working on a Guix package, if that's of interest to anyone following this thread.

Awesome. Happy to play the role of @deephack1982 to test it on Guix system when you need there.

Thanks!

[shymega]

Okay took a bit of a different approach to this but I now have it working perfectly. I think the issue was indeed the udev rules. See attached files strip the txt, below is my file structure.

/etc/nixos

* overlays

* * xrlinuxdriver-overlay.nix

* pkgs

* * xrlinuxdriver/  # Of course in once PR is merged we will just fetchgit this in xrlinuxdriver.nix

* * xrlinuxdriver.nix

I then added the following to my configuration.nix and ran rebuild.

nixpkgs.overlays = [
    (import ./overlays/xrlinuxdriver-overlay.nix)
  ];

environment.systemPackages = with pkgs; [
    xrlinuxdriver
  ];

  services.udev.packages = with pkgs; [
    xrlinuxdriver
  ];

The systemd unit still needs to be manually installed but now all the udev stuff just works.

xrlinuxdriver.nix.txt xrlinuxdriver-overlay.nix.txt

I'll edit the udev path, but if you can test the systemd unit as well, that would be great.

I use Home Manager for installing the CLI, which works for me. My overlay setup is slightly more complex, and I don't think you use Flakes, right?

[shymega]

Somewhat related, I'm working on a Breezy-Desktop package also. I have the following attached which builds but shows an error on run.

breezy-desktop.nix.txt

Interesting approach, but I think a better approach would be to build from source. One of Nix's central tenets is reproducibility after all. I have a prototype Breezy Desktop package, but I'm awaiting for the KDE stuff to be formally released before I release mine. I think it would be beneficial to use Flakes, too.

[shymega]

My personal opinion is that changing from $out/usr/lib/udev/rules.d is $out/lib/udev/rules.d will make no difference. I have made the change to see if it works, but for me, the issue I have under the systemd service is that upon hotplugging my VITURE Pros, on the second attempt of hotplugging, I get a error with device detection.

I think one improvement would be to use the correct filenaming for udev rules as mentioned in the Nixpkgs issue upstream.

However, further debugging will be required to fix the device detection under userspace.

[deephack1982]

Sure thing, I can re-test with your updated version. The udev thing I don't fully understand, I just know that it worked for me. I'm basing my pathing on the documentation of this option here https://search.nixos.org/options?channel=24.11&show=boot.initrd.services.udev.packages&from=0&size=50&sort=relevance&type=packages&query=services.udev

There may be other mechanisms for copying udev rules from an installed package however so I don't doubt your comment about the pathing.

Thanks for the tip on systemd, when I check the user scope though it's still not there on my package. I test again with yours.

[deephack1982]

One issue that I just noticed I am having is that I cannot seem to create virtual displays. I click the plus button and they appear in the list below but after a short delay they are removed from the list and never appear in the glasses. @wheaney any ideas?

[wheaney]

The virtual displays are kicked off by their own executable in the same directory as the UI executable. It logs to the same UI log, so I would check there first.

[deephack1982]

Thanks for the pointer. When I ran that directly it complained about a missing pipewire dependency. With that added and the package rebuilt I now have multiple virtual monitors working very nicely. Thanks!

[deephack1982]

@shymega Is this PR rebased off of 2.0.5 now or should I use the other branch before I test?

[shymega]

@deephack1982 This PR is still based off master, not a tagged release. However, using the branch based off v2.0.5 works perfectly for me. The XR CLI has no error messages, systemd works (as --user), and the udev rules are installed.

[shymega]

Thanks for the pointer. When I ran that directly it complained about a missing pipewire dependency. With that added and the package rebuilt I now have multiple virtual monitors working very nicely. Thanks!

Can you make a PR to Breezy for this derivation, and then I can build on that to build from source, along with Flake support? Thanks :)

[deephack1982]

@deephack1982 This PR is still based off master, not a tagged release. However, using the branch based off v2.0.5 works perfectly for me. The XR CLI has no error messages, systemd works (as --user), and the udev rules are installed.

Okay, just tried this one based on master. It does build for me but the systemctl unit doesn't appear and the udev rules don't get applied either. For reference I'm doing the following to build and install it.

nix-build && nix-env --install ./result

[deephack1982]

Thanks for the pointer. When I ran that directly it complained about a missing pipewire dependency. With that added and the package rebuilt I now have multiple virtual monitors working very nicely. Thanks!

Can you make a PR to Breezy for this derivation, and then I can build on that to build from source, along with Flake support? Thanks :)

I've just realised that my package isn't actually working correctly as while it works on my main machine it doesn't work from a fresh install on another computer. Turns out all the XDG_DATA_HOME stuff was already manually installed in my case from a previous run of the setup script. I need to add handling the following

~/.local/share/applications/com.xronlinux.BreezyDesktop.desktop
~/.local/share/breezydesktop/*
~/.local/share/breezy_gnome/manfest
~/.local/share/glib-2.0/schemas/*

Then glib-compile-schemas needs to be run and the extension installed. If you manually do all these things then my package works as it currently stands so still quite a bit to do. Current version of it is attached for now though.

breezy-desktop.nix.txt

In the meantime I'll work on cleaning it up a bit and making the xrlinuxdriver overlay source from a flake as that will make it cleaner for me.

[shymega]

Thanks for the pointer. When I ran that directly it complained about a missing pipewire dependency. With that added and the package rebuilt I now have multiple virtual monitors working very nicely. Thanks!

Can you make a PR to Breezy for this derivation, and then I can build on that to build from source, along with Flake support? Thanks :)

I've just realised that my package isn't actually working correctly as while it works on my main machine it doesn't work from a fresh install on another computer. Turns out all the XDG_DATA_HOME stuff was already manually installed in my case from a previous run of the setup script. I need to add handling the following

~/.local/share/applications/com.xronlinux.BreezyDesktop.desktop ~/.local/share/breezydesktop/* ~/.local/share/breezy_gnome/manfest ~/.local/share/glib-2.0/schemas/*

Then glib-compile-schemas needs to be run and the extension installed. If you manually do all these things then my package works as it currently stands so still quite a bit to do. Current version of it is attached for now though.

breezy-desktop.nix.txt

In the meantime I'll work on cleaning it up a bit and making the xrlinuxdriver overlay source from a flake as that will make it cleaner for me.

This is my initial draft, which handles glib schema compilation as well- wheaney/breezy-desktop#113.

I think ultimately what we want to aim for is from-source builds.

[shymega]

@deephack1982 This PR is still based off master, not a tagged release. However, using the branch based off v2.0.5 works perfectly for me. The XR CLI has no error messages, systemd works (as --user), and the udev rules are installed.

Okay, just tried this one based on master. It does build for me but the systemctl unit doesn't appear and the udev rules don't get applied either. For reference I'm doing the following to build and install it.

nix-build && nix-env --install ./result

I don't use nix-build or nix-env, so I can't help here. I use Flakes and the new CLI commands.

I haven't tried the one based on master, as I'm only using v2.0.5, but let me try from v2.0.6, and then I'll lock this PR to v2.0.6 for stability. from master, and we can see how it goes.

There is currently no way to lock a release from a tag in the derivation, as I build it directly from the root of the Flake.

[deephack1982]

@deephack1982 This PR is still based off master, not a tagged release. However, using the branch based off v2.0.5 works perfectly for me. The XR CLI has no error messages, systemd works (as --user), and the udev rules are installed.

Okay, just tried this one based on master. It does build for me but the systemctl unit doesn't appear and the udev rules don't get applied either. For reference I'm doing the following to build and install it.
nix-build && nix-env --install ./result

I don't use nix-build or nix-env, so I can't help here. I use Flakes and the new CLI commands.

I haven't tried the one based on master, as I'm only using v2.0.5, but let me try from v2.0.6, and then I'll lock this PR to v2.0.6 for stability. from master, and we can see how it goes.

There is currently no way to lock a release from a tag in the derivation, as I build it directly from the root of the Flake.

I'm fairly new to Nix so I'm mostly using the original nix commands. If you can list the commands you use to install then I'll test with the same ones you do.

[shymega]

I only use overlays as part of my overly complex NixOS config.

You could try sudo nix profile install github:shymega/XRLinuxDriver\?ref=shymega/nix-flake-support, but remove it from your env first.

[shymega]

I only use overlays as part of my overly complex NixOS config.

You could try sudo nix profile install github:shymega/XRLinuxDriver\?ref=shymega/nix-flake-support, but remove it from your env first.

@deephack1982 Did you try this?

[seanybaggins]

Okay took a bit of a different approach to this but I now have it working perfectly. I think the issue was indeed the udev rules. See attached files strip the txt, below is my file structure.
/etc/nixos

* overlays

* * xrlinuxdriver-overlay.nix

* pkgs

* * xrlinuxdriver/  # Of course in once PR is merged we will just fetchgit this in xrlinuxdriver.nix

* * xrlinuxdriver.nix

I then added the following to my configuration.nix and ran rebuild.

nixpkgs.overlays = [
    (import ./overlays/xrlinuxdriver-overlay.nix)
  ];

environment.systemPackages = with pkgs; [
    xrlinuxdriver
  ];

  services.udev.packages = with pkgs; [
    xrlinuxdriver
  ];

The systemd unit still needs to be manually installed but now all the udev stuff just works.
xrlinuxdriver.nix.txt xrlinuxdriver-overlay.nix.txt

I'll edit the udev path, but if you can test the systemd unit as well, that would be great.

I use Home Manager for installing the CLI, which works for me. My overlay setup is slightly more complex, and I don't think you use Flakes, right?

So I am testing this out and am using the config listed by @shymega. You can confirm looking here... https://github.com/seanybaggins/nix-home/commit/9e0ba8988d764cf1ea5f407d15d781d1f4fda4e1

I am not sure I am observing successful behavior. When wearing the glasses, the screen is always appearing directly in front of me.

xr_driver_cli -l

2025-05-31 13:49:51.310 Project version: 2.0.6
2025-05-31 13:49:51.310 Driver is disabled
2025-05-31 13:49:51.312 Using hardware id 9528df32eb00986ec8a14c7e50a5a9ece48763aa75bcc735d471f1e07ddb7254
2025-05-31 13:49:52.989 Feature sbs granted.
2025-05-31 13:49:52.990 Feature smooth_follow granted.
2025-05-31 13:49:52.990 Feature productivity_basic granted.
2025-05-31 13:49:52.990 Starting up XR driver
2025-05-31 13:49:52.993 Found device with vendor ID 0x35ca and product ID 0x101d
2025-05-31 13:49:52.993 Found device with vendor ID 0x35ca and product ID 0x101d

❯ xr_driver_verify
Verification failed

Looks like I dont have a manafest file at ~/.local/share

[shymega]

@seanybaggins This is expected behaviour. XRLinuxDriver doesn't implement multiple screens - Breezy does, but this is a separate issue.

What you're seeing is a functioning Flake for XRLinuxDriver, and therefore it can now be merged, I am happy to say.

You can test the state by running cat /dev/shm/xr_driver_state.

Breezy is more complex, as we'll need to build from source rather than using binaries, and this requires a few hacks. I am working on this separately.

If @wheaney is happy to merge this MR, I can then upstream my Nixpkgs branch to Nixpkgs, and it'll be backported to 25.05.

[wheaney]

Please update the README with instructions for Nix setup, also rebase and update any version numbers.

[wheaney]

We'll want to rebase and make sure the version matches the latest driver version (it's on 2.0.x now).

[wheaney]

Also we should probably drop "linux" from the naming since it's redundant based on the context (Nix being linux-specific). e.g. for AUR I called this just xr-driver-git

[shymega]

@wheaney Nix isn't always Linux specific. There is also support for Darwin (macOS). Also, generally, Nix derivation pnames follow the name of the source repository.

I can rebase and update the driver version, but I think the version should follow the Nix convention of 'unstable' or 'git', given we're building from the repo via Git.

The version tags inside the source code will follow how you've coded that aspect.

If we do upstream to Nixpkgs in future, we can set the version to the repo, but I think for the Flake inside the direct source repository, the version in the Nix code should not be locked to a certain version.

[wheaney]

Please also update the README with Nix instructions.

[wheaney]

This appears to be downgrading the submodule, d101fa is the latest commit