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.
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.
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.
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.
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.
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.
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.
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.
Actually I think line 86 in your package (default.nix) needs to become
cp ../udev/* $out/lib/udev/rules.d/
I'm testing it now though to see if it will work with sevices.udev.package
It shouldn't matter. usr/lib translates to lib in Nix, and indeed FHS-compliant distros.
As it works for usr/lib/systemd and usr/lib/${arch}, not sure it's worth changing.
I also had the udev rules set manually on my NixOS config, and aside from the amdgpu DRM crashes when plugging in the VITURE's, I don't think the udev rules are the problem - maybe?
Yeah I have no idea if it's the udev rules or not. Something interesting though, if you used the extraRules option then based on this error report they may not be getting applied because we are applying uaccess.
This is a good point. I wonder if this gets affected by the rules in $out/usr/lib/udev/rules.d. Maybe @wheaney needs to rename the rules to be in line with the udev implementation?
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.
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.
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
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.
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.
wheaney
