NixOS support - Detecting XR Hardware But Not Creating or Modifying Inputs

[xM8WVqaG]

This looked like an interesting project so I had a go at building it on NixOS. Seeing as SteamOS added a /nix directory in 3.5.5 NixPkg might be an interesting way of deploying this in the future! Because of how Nix works, your existing install and packaging scripts wouldn't work.

For this test, I was trying to get XRLinuxDriver running on my laptop using sway 1.8.1, Linux 6.1.69 and with xreal Air 1.

The Nix derivation (build script) is basically just checking out the repo & dependencies and running cmake - it looks like:

{ lib
  , stdenv
  , fetchgit
  , cmake
  , pkg-config

  , json_c
  , libevdev
  , libusb
}:

stdenv.mkDerivation rec {
  pname = "xr-linux-driver";
  version = "0.6.1-beta";

  src = (fetchgit {
    url = "https://github.com/wheaney/XRLinuxDriver";
    rev = "0f74025ccee6d9017f07e39db9bcdacfaac7e134";
    sha256 = "sha256-fpIxNiMW8IelrNMuHtOPePIxeI1sxUNigZq5f/CqjyA=";
    fetchSubmodules = true;
  }).overrideAttrs (_: {
    GIT_CONFIG_COUNT = 1;
    GIT_CONFIG_KEY_0 = "url.https://gitlab.com/.insteadOf";
    GIT_CONFIG_VALUE_0 = "[email protected]:";
  });

  buildInputs = [
    json_c
    libevdev
    libusb
  ];

  nativeBuildInputs = [
    pkg-config
    cmake
  ];

  outputs = [ "out" ];

  patches = [
    ./install.patch
  ];

  meta = with lib; {
    description = "Custom user-space Linux driver for XR devices";
    homepage = "https://github.com/wheaney/XRLinuxDriver";
    license = licenses.mit;
    platforms = platforms.linux;
    maintainers = [ "wheaney" ];
  };
}

The patch applied is to CMakeLists.txt to add install targets to the output:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9d55cec..073303b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -55,4 +55,8 @@ target_include_directories(xrealAirLinuxDriver
 
 target_link_libraries(xrealAirLinuxDriver
 		PRIVATE ${LIBEVDEV_LIBRARIES} nrealAirLibrary Threads::Threads m ${VITURE_LIB_NAME} ${LIBUSB_LIBRARY}
-)
\ No newline at end of file
+)
+
+install(TARGETS xrealAirLinuxDriver DESTINATION bin)
+
+install(TARGETS hidapi_hidraw DESTINATION lib)

This runs fine as far as I can tell, the compiled binary executes and creates .xreal_driver_{log,config,lock}, although it only ever logs:

Starting up XR driver
Waiting for glasses
Starting up XR driver
Waiting for glasses
Starting up XR driver
Waiting for glasses
...

modprobe was run elsewhere:

$ lsmod | grep uinput          
uinput                 20480  0

This is the slightly modified service to work around the hardcoded ~ and not actually having a writable home:

[Unit]
After=network.target
Description=xr-linux-driver
Type=simple

[Service]
Environment=HOME=/run/user/1000/xr-linux-driver
ExecStart=/nix/store/0kngb662m75hrxw88jsqb1mvdkxv0ixb-xr-linux-driver-0.6.1-beta/bin/xrealAirLinuxDriver
PrivateNetwork=true
Restart=on-failure

I can see that it's managing to create a device:

$ journalctl
Jan 02 19:18:34 hostname kernel: usb 1-1: new full-speed USB device number 5 using xhci_hcd
Jan 02 19:18:34 hostname kernel: usb 1-1: New USB device found, idVendor=3318, idProduct=0424, bcdDevice= 0.01
Jan 02 19:18:34 hostname kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 02 19:18:34 hostname kernel: usb 1-1: Product: Air
Jan 02 19:18:34 hostname kernel: usb 1-1: Manufacturer: Vendor
Jan 02 19:18:34 hostname kernel: usb 1-1: SerialNumber: A00020:14:32
Jan 02 19:18:34 hostname kernel: hid-generic 0003:3318:0424.002F: hiddev98,hidraw4: USB HID v1.10 Device [Vendor Air] on usb-0000:00:14.0-1/input3
Jan 02 19:18:34 hostname kernel: hid-generic 0003:3318:0424.0030: hiddev99,hidraw5: USB HID v1.10 Device [Vendor Air] on usb-0000:00:14.0-1/input4
Jan 02 19:18:34 hostname kernel: hid-generic 0003:3318:0424.0031: hiddev100,hidraw6: USB HID v1.10 Device [Vendor Air] on usb-0000:00:14.0-1/input5
Jan 02 19:18:34 hostname kernel: input: Vendor Air as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.6/0003:3318:0424.0032/input/input45
Jan 02 19:18:34 hostname kernel: hid-generic 0003:3318:0424.0032: input,hidraw7: USB HID v1.10 Device [Vendor Air] on usb-0000:00:14.0-1/input6

$ libinput list-devices
...
Device:           Vendor Air
Kernel:           /dev/input/event20
Group:            6
Seat:             seat0, default
Capabilities:     keyboard 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      n/a
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   n/a
Rotation:         0.0

$ swaymsg -t get_inputs
{
  {
    "identifier": "13080:1060:Vendor_Air",
    "name": "Vendor Air",
    "vendor": 13080,
    "product": 1060,
    "type": "keyboard",
    "repeat_delay": 600,
    "repeat_rate": 25,
    "xkb_layout_names": [
      "English (UK)"
    ],
    "xkb_active_layout_index": 0,
    "xkb_active_layout_name": "English (UK)",
    "libinput": {
      "send_events": "enabled"
    }
  },
  ...
}

But it identifies as a keyboard. I've done before and after lists of libinput and it can only see one new device being created.

I've tried changing the output_mode=mouse to output_mode=joystick and the driver can see the change, but that doesn't change the detected device.

$ journalctl
...
Jan 02 18:48:49 hostname systemd[1975]: Stopping xr-linux-driver...
Jan 02 18:48:49 hostname systemd[1975]: Stopped xr-linux-driver.
Jan 02 18:48:49 hostname systemd[1975]: Started xr-linux-driver.
Jan 02 18:48:49 hostname xrealAirLinuxDriver[120743]: Output mode has been changed to 'joystick'

Any ideas?

EDIT: I've just read this back and it's not super clear what I'm asking. The Vendor Air does appear to be from the glasses itself, rather than the user-mode driver. So I guess this is more of a question around the behaviour of XRLinuxDriver, and what the correct behaviour is supposed to be at this point. Presumably they should be called XR virtual {joystick,mouse} based on: outputs.c

[wheaney]

Wow, this is interesting. I'm not familiar with Nix so this isn't something I would tackle until I've achieved some of my longer term goals and had time to dig into it.

A couple things I see:

1. The USB device you're seeing is the glasses itself. My driver doesn't create a new USB device, so you'll never see it created there. It does create a new uinput device through libevdev when in joystick mode, but for mouse mode I believe it'll just modify the uinput fp for the existing mouse device.
2. Your log is indicating that it never sees the device connect (due to never leaving the Waiting for glasses state)

So your libinput observations are just a red herring, the more important piece is that it seems like the hidapi library that gets used by my driver under the hood isn't picking up the USB device at all, even though clearly the USB device is registered by your OS. I would recommend double-checking that the daemon isn't crashing by checking systemctl status xreal-air-driver (or I guess xr-linux-driver?). Otherwise, you'd need to debug the hidapi integration or even just create a simple test program that queries hidapi directly for easier debugging.

[xM8WVqaG]

Thanks for the rapid response! I appreciate this usecase isn't something you currently support so I'm grateful for the suggestions.

I had a little more time tonight to play with this but didn't solve it yet.

I would recommend double-checking that the daemon isn't crashing

I can confirm it's happily idle and not crashing. It seems to be oblivious to the world!

Based on your suggestion to poke around hidapi:

• I patched out the submodule'd hidapi to use the "system" one. It linked fine, but no dice. Turns out they were the same version.
• I wrote some new udev rules just in case it was a perms thing still, but that didn't seem to have an impact.
• I tried building the upstream nrealAirLinuxDriver project by itself using the same build script and noticed it was failing looking for udev and I had only provided evdev. I imported systemd for that and confirmed that did get linked to xrealAirLinuxDriver so something did want that.

After that, next time I started the service the logs were:

Starting up XR driver
Error calling shmat
Starting up XR driver
Error calling shmat
Starting up XR driver

But given this error is from ipc.c it seems to be another red herring.

I'll have another think about next steps for debugging hidapi locally. Thanks again!

[xM8WVqaG]

@wheaney I had a bit of time this morning to have another play with this. It still doesn't create a device for joystick or influence cursor movement. but I can confirm it's reading data from the glasses.

I changed the CMake build type from Release to Debug to run it via gdb and that started dumping loads more bits in the logs:

Starting up XR driver
Found device with product_id: 0x424
G: -0.47 -0.21 -0.22
A: -0.99 -0.05 -0.02
M: -1.00 -1.00 -1.00
ERROR: Not matching signature
Found device with product_id: 0x424
MCU: 07.1.02.313_20231027
DP: 112E
DSP: 07.1.00.001_1.0.1.7_1.1
Brightness: 7
Disp-Mode: 1
Error calling shmat
Starting up XR driver
...

At this point, if it's running under root via systemd it segfaults:

Jan 04 00:59:41 hostname systemd[1]: Started xr-linux-driver.
Jan 04 00:59:43 hostname kernel: xrealAirLinuxDr[79308]: segfault at c0 ip 00007f89b154d4d2 sp 00007f89aa7fb7f0 error 4 in libc.so.6[7f89b1514000+15a000] likely on CPU 5 (core 1, socket 0)
Jan 04 00:59:43 hostname kernel: Code: 41 55 41 89 cd 41 54 49 89 d4 55 48 89 f5 53 48 89 fb 48 81 ec f8 00 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 e8 00 00 00 <8b> 87 c0 00 00 00 85 c0 0f 85 a0 00 00 00 c7 87 c0 00 00 00 ff ff
Jan 04 00:59:43 hostname systemd[1]: Started Process Core Dump (PID 79310/UID 0).
Jan 04 00:59:43 hostname systemd-coredump[79311]: [🡕] Process 79301 (xrealAirLinuxDr) of user 0 dumped core.
                                              
                                              Module libcap.so.2 without build-id.
                                              Module libatomic.so.1 without build-id.
                                              Module libudev.so.1 without build-id.
                                              Module libjson-c.so.5 without build-id.
                                              Module libhidapi-hidraw.so.0 without build-id.
                                              Module libusb-1.0.so.0 without build-id.
                                              Module libevdev.so.2 without build-id.
                                              Module xrealAirLinuxDriver without build-id.
                                              Stack trace of thread 79308:
                                              #0  0x00007f89b154d4d2 __vfprintf_internal (libc.so.6 + 0x5f4d2)
                                              #1  0x00007f89b16098a3 __fprintf_chk (libc.so.6 + 0x11b8a3)
                                              #2  0x00000000004086a7 write_state (xrealAirLinuxDriver + 0x86a7)
                                              #3  0x00000000004055bf manage_state_thread_func (xrealAirLinuxDriver + 0x55bf)
                                              #4  0x00007f89b1579084 start_thread (libc.so.6 + 0x8b084)
                                              #5  0x00007f89b15fb60c __clone3 (libc.so.6 + 0x10d60c)
                                              
                                              Stack trace of thread 79304:
                                              #0  0x00007f89b15edd8f __poll (libc.so.6 + 0xffd8f)
                                              #1  0x00007f89b16ff238 usbi_wait_for_events (libusb-1.0.so.0 + 0xe238)
                                              #2  0x00007f89b16fc7b6 handle_events (libusb-1.0.so.0 + 0xb7b6)
                                              #3  0x00007f89b16fdd00 libusb_handle_events_timeout_completed (libusb-1.0.so.0 + 0xcd00)
                                              #4  0x00007f89b16fdd5a libusb_handle_events (libusb-1.0.so.0 + 0xcd5a)
                                              #5  0x000000000041225a read_thread (xrealAirLinuxDriver + 0x1225a)
                                              #6  0x00007f89b1579084 start_thread (libc.so.6 + 0x8b084)
                                              #7  0x00007f89b15fb60c __clone3 (libc.so.6 + 0x10d60c)

                                              Stack trace of thread 79306:
                                              #0  0x00007f89b15f7856 __mmap (libc.so.6 + 0x109856)
                                              #1  0x00007f89b1579b66 pthread_create@GLIBC_2.2.5 (libc.so.6 + 0x8bb66)
                                              #2  0x0000000000409aff xreal_block_on_device (xrealAirLinuxDriver + 0x9aff)
                                              #3  0x0000000000405a81 block_on_device_thread_func (xrealAirLinuxDriver + 0x5a81)
                                              #4  0x00007f89b1579084 start_thread (libc.so.6 + 0x8b084)
                                              #5  0x00007f89b15fb60c __clone3 (libc.so.6 + 0x10d60c)

                                              Stack trace of thread 79301:
                                              #0  0x00007f89b1575c96 __futex_abstimed_wait_common (libc.so.6 + 0x87c96)
                                              #1  0x00007f89b157ab23 __pthread_clockjoin_ex (libc.so.6 + 0x8cb23)
                                              #2  0x0000000000404cfc main (xrealAirLinuxDriver + 0x4cfc)
                                              #3  0x00007f89b1515fce __libc_start_call_main (libc.so.6 + 0x27fce)
                                              #4  0x00007f89b1516089 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x28089)
                                              #5  0x0000000000404d95 _start (xrealAirLinuxDriver + 0x4d95)

                                              Stack trace of thread 79309:
                                              #0  0x00007f89b15fb5fd __clone3 (libc.so.6 + 0x10d5fd)
                                              #1  0x00007f89a0000b80 n/a (n/a + 0x0)
                                              ELF object binary architecture: AMD x86-64
Jan 04 00:59:43 hostname systemd[1]: xr-linux-driver.service: Main process exited, code=dumped, status=11/SEGV
Jan 04 00:59:43 hostname systemd[1]: xr-linux-driver.service: Failed with result 'core-dump'.
Jan 04 00:59:43 hostname systemd[1]: [email protected]: Deactivated successfully.
Jan 04 00:59:43 hostname systemd[1]: xr-linux-driver.service: Scheduled restart job, restart counter is at 5.
Jan 04 00:59:43 hostname systemd[1]: xr-linux-driver.service: Start request repeated too quickly.
Jan 04 00:59:43 hostname systemd[1]: xr-linux-driver.service: Failed with result 'core-dump'.
Jan 04 00:59:43 hostname systemd[1]: Failed to start xr-linux-driver.

The segfault seems to be from write_state in state.c via manage_state_thread_func in driver.c.

I found if I first rm /dev/shm/xr_driver_state /tmp/shader_runtime_* ${FAKE_HOME}/.xreal* before execution it will connect without crashing:

If I start the driver before connecting hardware I get:

Starting up XR driver
ERROR: No handle
Waiting for glasses
ERROR: No handle
ERROR: No handle
ERROR: No handle
ERROR: No handle

If I start the driver after connecting hardware it will error and restart a few times with Error calling shmat but then will happily spew out gyro/accel/magne data in the logs:

Starting up XR driver
Found device with product_id: 0x424
G: -0.37 -0.28 -0.08
A: -0.98 0.03 0.16
M: -1.00 -1.00 -1.00
ERROR: Not matching signature
Found device with product_id: 0x424
MCU: 07.1.02.313_20231027
DP: 112E
DSP: 07.1.00.001_1.0.1.7_1.1
Brightness: 7
Disp-Mode: 1
Error calling shmat
Starting up XR driver
Found device with product_id: 0x424
G: -0.48 -0.29 -0.18
A: -0.98 0.04 0.16
M: -1.00 -1.00 -1.00
ERROR: Not matching signature
Found device with product_id: 0x424
MCU: 07.1.02.313_20231027
DP: 112E
DSP: 07.1.00.001_1.0.1.7_1.1
Brightness: 7
Disp-Mode: 1
G: -0.39 -0.29 -0.12
A: -0.98 0.03 0.16
M: -0.96 -0.96 -0.89
G: -0.45 -0.17 -0.24
A: -0.98 0.03 0.16
M: -0.96 -0.96 -0.89
G: -0.32 -0.22 -0.25
A: -0.98 0.03 0.16
M: -0.96 -0.96 -0.89

As far as I know, there isn't any human input and at this point it should Just Work? if you do have a moment to think about where this might be going wrong or what I might look at next that would be appreciated!

[canguy247]

I had a poke around today to get it running on NixOS and since it is set up for an immutable OS it should run on Nix. I would rather avoid doing a "proper" install the Nix way until this project is stable (and I learn more about that since I am a Nix newb)

The first issue I had was that the setup script for the shader uses chown and assumes the normal distro setup where a user is in a group named after their username. In Nix the group is called "users".

Once I fixed this the driver setup script failed when it checked for systemd using the command: "ps -p 1 -o comm=" which should work but does not with the following output:

ps: invalid option -- 'p'
BusyBox v1.36.1 () multi-call binary.

Usage: ps [-o COL1,COL2=HEADER] [-T]

Show list of processes

	-o COL1,COL2=HEADER	Select columns for display
	-T			Show threads

I will have another look tomorrow as I have some other things to do right now.

I had a few more minutes and tried to manually copy files and run as root but got:
bash: ./xrealAirLinuxDriver: cannot execute: required file not found

Edit: this method will not work as the binary is looking for libraries (glibc) in specific spots, and Nix is not a standard directory tree. Will have to do this properly I guess, lol

[xM8WVqaG]

This is the last version I was testing. The only thing this is missing is the new libusb resolver but I think @wheaney fixed that upstream already so better to build off a newer version.

default.nix

{ lib
  , stdenv
  , fetchgit
  , cmake
  , pkg-config

  # deps
  , systemd
  , json_c
  , libevdev
  , libusb
  , hidapi
}:

stdenv.mkDerivation rec {
  pname = "xr-linux-driver";
  version = "0.6.1-beta";

  src = (fetchgit {
    url = "https://github.com/wheaney/XRLinuxDriver";
    rev = "0f74025ccee6d9017f07e39db9bcdacfaac7e134";
    sha256 = "sha256-fpIxNiMW8IelrNMuHtOPePIxeI1sxUNigZq5f/CqjyA=";
    fetchSubmodules = true;
  }).overrideAttrs (_: {
    GIT_CONFIG_COUNT = 1;
    GIT_CONFIG_KEY_0 = "url.https://gitlab.com/.insteadOf";
    GIT_CONFIG_VALUE_0 = "[email protected]:";
  });

  buildInputs = [
    systemd
    json_c
    libevdev
    libusb
    hidapi
  ];

  nativeBuildInputs = [
    pkg-config
    cmake
  ];

  dontStrip = true;

  outputs = [ "out" ];

  patches = [
    ./install.patch
    ./unlink-hidapi.patch
  ];

  meta = with lib; {
    description = "Custom user-space Linux driver for XR devices";
    homepage = "https://github.com/wheaney/XRLinuxDriver";
    license = licenses.mit;
    platforms = platforms.linux;
    maintainers = [ "wheaney" ];
  };
}

install.patch

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9d55cec..dbd8c5b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -55,4 +55,6 @@ target_include_directories(xrealAirLinuxDriver
 
 target_link_libraries(xrealAirLinuxDriver
 		PRIVATE ${LIBEVDEV_LIBRARIES} nrealAirLibrary Threads::Threads m ${VITURE_LIB_NAME} ${LIBUSB_LIBRARY}
-)
\ No newline at end of file
+)
+
+install(TARGETS xrealAirLinuxDriver DESTINATION bin)

unlink-hidapi.patch

diff --git a/modules/xrealInterfaceLibrary/.gitmodules b/modules/xrealInterfaceLibrary/.gitmodules
index 8696ec6..2b8a1a0 100644
--- a/modules/xrealInterfaceLibrary/.gitmodules
+++ b/modules/xrealInterfaceLibrary/.gitmodules
@@ -1,6 +1,3 @@
 [submodule "interface_lib/modules/Fusion"]
 	path = interface_lib/modules/Fusion
 	url = https://github.com/xioTechnologies/Fusion.git
-[submodule "interface_lib/modules/hidapi"]
-	path = interface_lib/modules/hidapi
-	url = https://github.com/libusb/hidapi.git
diff --git a/modules/xrealInterfaceLibrary/interface_lib/CMakeLists.txt b/modules/xrealInterfaceLibrary/interface_lib/CMakeLists.txt
index 1fc3449..e57fdfb 100644
--- a/modules/xrealInterfaceLibrary/interface_lib/CMakeLists.txt
+++ b/modules/xrealInterfaceLibrary/interface_lib/CMakeLists.txt
@@ -5,7 +5,7 @@ set(CMAKE_C_STANDARD 17)
 
 find_package(json-c REQUIRED CONFIG)
 
-add_subdirectory(modules/hidapi)
+find_package(hidapi REQUIRED)
 add_subdirectory(modules/Fusion/Fusion)
 
 add_library(
@@ -25,7 +25,6 @@ target_include_directories(nrealAirLibrary
 
 target_include_directories(nrealAirLibrary
 		SYSTEM BEFORE PRIVATE 
-		${CMAKE_CURRENT_SOURCE_DIR}/modules/hidapi
 		${CMAKE_CURRENT_SOURCE_DIR}/modules/Fusion
 )

Build it with:

nix-build -E 'let pkgs = import <nixpkgs> { }; in pkgs.callPackage ./default.nix {}'

The binary will be available in ./results.

To create the systemd unit and enable the kernel module you'll want something like:

systemd.services.xr-linux-driver = {
  enable = true;
  description = "xr-linux-driver";
  after = [ "network.target" ];

  serviceConfig = {
    Type = "simple";
    Environment = "HOME=/tmp/xr-linux-driver";
    ExecStart = "/nix/store/j3rf49f3b06cni2ynyrz94alqmhp6z3d-xr-linux-driver-0.6.1-beta/bin/xrealAirLinuxDriver";
    Restart = "on-failure";
    PrivateNetwork = "true";
    # PrivateTmp = "true";
  };

  wantedBy = [ "multi-user.target" ];
};

boot.kernelModules = [ "uinput" ];

You can optionally change the build type to get more noise in logs:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9d55cec..305d468 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,14 +1,15 @@
 cmake_minimum_required(VERSION 3.16)
 project(xrealAirLinuxDriver C)
 
-set(CMAKE_BUILD_TYPE Release)
+#set(CMAKE_BUILD_TYPE Release)
+set(CMAKE_BUILD_TYPE Debug)
 set(CMAKE_C_STANDARD 17)
 set(THREADS_PREFER_PTHREAD_FLAG ON)
 find_package(Threads REQUIRED)
 
 list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")
 find_package(LIBEVDEV REQUIRED)
 find_package(LIBUSB REQUIRED)
 
 set(VITURE_LIB_NAME viture_sdk)

I am unable to get the original binary from releases to work on my SteamDeck since I updated the firmware of my glasses so I'm unable to confirm how well this actually works. My glasses are fine otherwise, and I can read data from them without issue, just this software never does anything after connecting to the glasses.

[canguy247]

First, thanks @xM8WVqaG for the above info and @wheaney for the great work here!. This has been an amazing learning process!

I compiled the driver (haven't touched the shader stuff yet) and it works!

The only issue I had is just like xM8WVqaG I have to restart the service after plugging in the glasses or it does not work and the logs continue to show:

ERROR: No handle

I will have a look at the shader next (maybe not tonight) and see how that goes

Here is a section of the log where things started up:

ERROR: No handle
ERROR: No handle
Starting up XR driver
Found device with product_id: 0x424
Found device with product_id: 0x424
MSG: 27672 = 6c18 (18)
01 00 00 00 00 00 00
MCU: 07.1.02.321_20240105
DP: 112E
DSP: 07.1.00.001_1.0.1.7_1.1
Brightness: 7
Disp-Mode: 1
Device connected, redirecting input to mouse...
G: -3.27 -5.42 -1.20
A: 0.16 -0.13 -0.96
M: -1.00 -1.00 -0.98
G: -3.12 -5.36 -1.39
A: 0.16 -0.13 -0.96
M: -1.00 -1.00 -0.98

[xM8WVqaG]

Interesting, can you confirm which window manager or desktop environment you're using? Was it X11 or Wayland?

I've never actually managed to get Device connected, redirecting input to mouse... to come up. I think there is some missing error handling around this part because it just hangs. You can see from my logs the device is discovered I do get the GAM output. The only error is ERROR: Not matching signature which comes from nrealAirLinuxDriver/interface_lib/src/device3.c but otherwise, no exceptions, just nothing. I haven't had time to try and add more handling to debug this.

[canguy247]

I am using Hyprland on Wayland

[JeremiahSecrist]

@xM8WVqaG In trying to replicate your work the install.patch seems to be malformed.
would you be willing to publish your work so far as a git repo for easy access and adjustments?

[xM8WVqaG]

it's not surprising the patches no longer cleanly apply, given they were written for 0.6.1-beta which was 95 commits ago. It was building and mostly running on the older version, as @canguy247 managed to reproduce. But it didn't seem to properly handle hardware disconnects or reconnects.

Right now I've no interest in picking this work back up as I went back to using Monado.

Given the project has matured since my first test and a bunch of the stuff I had to patch in this issue has already been upstreamed (the GitLab auth, the scuffed CMake, the hardcoded directories) you should start without any patches and only apply what's necessary. I intended to upstream those but ran out of time before I managed a complete e2e test.

[wheaney]

Not sure how much this helps the NixOS work, but this driver has recently been added to AUR, which involved cleaning up the install process, put everything into XDG dirs, making it possible to run as a user process (was always root before), etc...

Here's the PKGBUILD file that shows everything makepkg does to install the driver now: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=xr-driver-breezy-gnome-git

[only1thor]

I have a build that seems to start.
but trying the mouse option to test the driver does not work.
i have the work here if any one is interested.
Hopefully i can get something working, but all of my progress was at NixCon with loads of help from the community there, so not sure if i can get this working in the near future.

[shymega]

I've got it building based on @only1thor's branch.

If someone could test the build from my Nixpkgs fork, that would be useful:

nix run github:shymega/nixpkgs/add-xr-driver#xrlinuxdriver.

If it's OK with OP and others, I would like to submit the package to Nixpkgs. Then I can submit a package for Breezy too.

[wheaney]

Dang that would be amazing if someone else can confirm and help work out any last kinks. It would be helpful too if you could write up some maintenance details, how to get the latest updates out to Nix, etc...

[only1thor]

@shymega Awesome! 🤩
I'll try to take the time to test it this week.

[only1thor]

Dang that would be amazing if someone else can confirm and help work out any last kinks. It would be helpful too if you could write up some maintenance details, how to get the latest updates out to Nix, etc...

Regarding maintenence.
I'm not really familiar with Cmake, so take the following as an uninformed suggestion.
If the cmake file could be changed in such a way to avoid the need for a git patch to remove the submodules for hidapi, and others.
That would make the package a lot easier to maintain.
Not sure if there is a way to include it in a way that is easy to exclude with a cmake option or something.

[only1thor]

Tested your branch @shymega, and it has the same issue i had on mine.
The driver starts.
Finds headset when plugged in.
Then fails to connect, and loops reconnecting until unplugged.

I have an Xreal Air 1.

Here are the logs annotated what i was doing while things changed:

2024-11-13 18:05:35.071 Project version: 0.12.0.1
2024-11-13 18:05:35.071 Driver has been re-enabled
2024-11-13 18:05:35.072 Using hardware id 6ca9ebcb13307767c00adcacbf3c561aef8c11e40063f6d19dd5f8e535421936
2024-11-13 18:05:35.072 Feature smooth_follow granted.
2024-11-13 18:05:35.072 Feature sbs granted.
2024-11-13 18:05:35.072 Feature productivity_basic granted.
2024-11-13 18:05:35.072 Starting up XR driver
2024-11-13 18:05:35.073 Waiting for glasses
# Plugged in glasses
2024-11-13 18:05:54.825 Found device with vendor ID 0x3318 and product ID 0x0424
2024-11-13 18:06:09.295 Device driver connection attempt failed
2024-11-13 18:06:09.295 Retrying driver connection in 1 second
# goes on retrying ...
# unplugged glasses
2024-11-13 18:06:16.298 Waiting for glasses

the run above seemed stable but most attempts have crashed the driver with the following error in the logs:

2024-11-13 18:12:33.053 [ERROR] Segmentation fault occurred at address: 0x4c
xrDriver() [0x408865]
/nix/store/3bvxjkkmwlymr0fssczhgi39c3aj1l7i-glibc-2.40-36/lib/libc.so.6(+0x40620) [0x7f7352047620]
xrDriver() [0x407c42]
xrDriver() [0x4091f8]
/nix/store/3bvxjkkmwlymr0fssczhgi39c3aj1l7i-glibc-2.40-36/lib/libc.so.6(+0x90d02) [0x7f7352097d02]
/nix/store/3bvxjkkmwlymr0fssczhgi39c3aj1l7i-glibc-2.40-36/lib/libc.so.6(+0x1103ac) [0x7f73521173ac]

and running xr_driver_cli -m does absolutely nothing. not even anything in the logs.

[shymega]

@only1thor Can you try again, please? If it doesn't download the new version, try this one:

nix build github:shymega/XRLinuxDriver//shymega/nix-flake-support

If this also fails - I don't have a VITURE pair yet - then we may need some output from Valgrind/gdb. If you want to ping/DM me on Discord feel free - same username as here.

[shymega]

@only1thor In fact, can you try this:

nix build github:shymega/XRLinuxDriver//shymega/nix-flake-support --refresh && nix shell nixpkgs#gdb --command 'gdb -batch -ex "run" -ex "bt" ./result/bin/xrDriver 2>&1 | grep -v "^No stack.$"' 2>&1 |tee backtrace.txt

Then, run ./result/bin/xr_driver_cli -m, hit Ctrl-C on the above command, and attach the backtrace.txt to this issue.

Thanks :)

EDIT: Got the command wrong.

[shymega]

I received my VITUREs recently, and can confirm there are no longer any segfaults. I am going to test the user systemd service too, but I've opened a PR in the meantime - #80.