Add PKGBUILD file

[hodasemi]

Hi,

here is the PKGBUILD file for the XR driver separated. I commited an update for the breezy-gnome file to depend on this.

[wheaney]

Needs to install bin scripts

[hodasemi]

Is there a reason why you build your own curl version? Why not use the version distributed on the system. With actual build files we can add it as system dependency.

[wheaney]

I only added the curl static link recently because someone had to install it manually, and since I don't have a great way to handle dependencies with the way I currently distribute it, it was easier just to build it in. So let's leave it as-is for now since it's doing no harm, and once I can switch my setup instructions to just package managers, then remove it.

[hodasemi]

Makes sense. My cmake-magic is quite limited. How much effort would it make to make that a compile time switch via a variable?

[wheaney]

How much effort would it make to make that a compile time switch via a variable?

Probably not much effort at all.

[wheaney]

So how does this get tested? What kind of testing have you done? The move-from-root piece has me the most nervous because of the wide range of devices to test, and the potential to break the steam deck integration. One thing we may need to fix before this can go out that you may not have noticed in your testing is whether the device_license integration is working. Specifically, we'll want to move the license file to a directory owned by the user since I think right now it'll be owned by root, at least it is on my system. This issue describes where I'm planning on moving all files to conform with XDG standards as this becomes a user-service.

[hodasemi]

About the points:

• Testing: This is where it actually hangs now. I don't know how 😓
• With this pkgfile everything about the current installation process can be in place as is (this is a big can). If we actually get this to run as a user service things can be changed. If the changes don't work for the steam deck, things can be in place as they are.
• Licensing: I need to put the licenses in place, as I haven't touched that at all. With the pkg file it is not possible to put them into a user directory, since we can have that case that packages can be installed by different user than the user that uses this driver. Also there is not really a way of knowing because the installation has to be done as root anyway.

[wheaney]

Just to clarify, the installer doesn't touch license files, they just get downloaded by the driver itself, but since the driver isn't running as root, it can no longer use its current location in /var/lib (I think).

[wheaney]

Testing would be as simple as:

1. Install the driver from clean slate, verify it runs and downloads/creates the license file
2. Enable and put in mouse mode, verify a supported device moves the mouse
3. Verify /dev/shm/xr_driver_state is created and modified with a live heartbeat and device info
4. Verify config and control flags are abided

To test the IPC sending of the IMU data to external apps (e.g. vulkan layer or gnome extension), easiest would be to install breezy-vulkan and then uninstall the driver (breezy installs a locked verison of the driver) and re-install with this one. Then we can put in virtual display mode and test that the vulkan shader gets this data.

[hodasemi]

Just to clarify, the installer doesn't touch license files, they just get downloaded by the driver itself, but since the driver isn't running as root, it can no longer use its current location in /var/lib (I think).

Ah, then we need to put the licenses somewhere in the home directory.

[wheaney]

Yeah, that's where this issue came in.

$XDG_STATE_HOME/xr_driver/license.json
~/.local/state/xr_driver/license.json (fallback if XDG env var not set)

[hodasemi]

Testing would be as simple as:

1. Install the driver from clean slate, verify it runs and downloads/creates the license file

2. Enable and put in mouse mode, verify a supported device moves the mouse

3. Verify /dev/shm/xr_driver_state is created and modified with a live heartbeat and device info

4. Verify config and control flags are abided

To test the IPC sending of the IMU data to external apps (e.g. vulkan layer or gnome extension), easiest would be to install breezy-vulkan and then uninstall the driver (breezy installs a locked verison of the driver) and re-install with this one. Then we can put in virtual display mode and test that the vulkan shader gets this data.

I can verify that it runs and the mouse mode does indeed work. The license file however could not be downloaded (as expected actually). /dev/shm/xr_driver_state is also created.
I would say, the first round of successes comes in. I need to figure out the rest now.

[hodasemi]

BreezyDesktop does indeed successfully communicate with the driver. It successfully downloaded the license file (after manually changing access rights of /var/lib/xr_driver) and I can see the ui now.
If I enable it I can see a calibrating watermark above the desktop on my glasses, but that never goes away. Am I missing something?

[kelvie]

Why is this a PR to this repo? shouldn't this be in the AUR?

[hodasemi]

There were a few more changes required to make it work. I think it is a good first step. Then the file can be submitted to the AUR.

[wheaney]

Just tried this today. I think we're missing a dependency:

Iconv is not found, make sure to provide it in your build environment

[wheaney]

I added libiconv to my depends and it still failed. One message I'm seeing at the end of the build:

Could NOT find Iconv (missing: Iconv_INCLUDE_DIR)

[hodasemi]

iconv is part of glibc on my system:

$ pacman -F iconv                                          
core/glibc 2.39+r52+gf8e4623421-1 [Installiert]
    usr/bin/iconv

[wheaney]

Dunno what the issue was but I probably shouldn't be trying this on Steam Deck anyway 😂.

So I switched to Manjaro on my laptop and the build and install worked. But now I hit a segfault, it seems like it's during device_license parsing.

[hodasemi]

Steam deck isn't really the target for this one, because the package needs to be reinstalled after every system update.

Strange but hard to debug. The local directory ~/.local/state/xr_driver is created and the device_license should be in there.

[wheaney]

Alright, so strangely I rebooted in Manjaro today to see if the license file had been put there, and got past that part, so... something we'll need to look into for fresh installs I guess. But I run into another issue:

Driver has been re-enabled
Using hardware id 611f47e3bc636ef477b0a2a958540143c7b5790175c1376f0bdd98e065f08ff4
Feature productivity_basic granted.
Starting up XR driver
Waiting for glasses
Found device with vendor ID 0x1bbb and product ID 0xaf50
Found device with vendor ID 0x1bbb and product ID 0xaf50
Feature productivity_basic granted.
Device connected, redirecting input to mouse...
libevdev.libevdev_uinput_create_from_device: Permission denied

With the uaccess flag in udev, I wouldn't expect there to be permission issues.

[hodasemi]

I just checked which pid and vid this device stands for. You are using the rayneo. If you compare the rayneo udev file with the viture one, you can see there are sub systems missing. This is kind of on purpose, because I could not find any resource on that information and I don't own such a device.
Thus indeed, that error is kind of expected.

[wheaney]

I got this with my XREALs too

[hodasemi]

For xreals I just used the file you linked: #61 (comment)

With the difference that the plugdev group is replaced by uaccess and corrects right. plugdev was an older approach with the downside that the user had manually be added to this group. As with the rayneos, I don't xreals too, thus there is no way for me to test it. I just assumed that this udev rule was tested by others. Nevertheless, it is probably a good base for someone to start testing which subsystems are used and fix it accordingly.

[wheaney]

I don't think the udev file needs all those subsystems. Here's the XREAL udev I used to use before I moved to a systemd service (root access meant I no longer needed udev), and this worked fine: https://github.com/wheaney/XRLinuxDriver/blob/1b1d644d1f2e97f1bcc3a7dd870ef1f90f6d721f/udev/60-xreal-air.rules

Note: the first line of that file is what allowed me to write mouse/controller movements, not necessary for reading from the device. But now that I think about it, I'll need something like that for VR-Lite mode.

I have a feeling there's something else going on here.

[hodasemi]

That would be your part, since I can't test the devices I don't have. I can confirm that the viture one works for me.

[wheaney]

Oh how dumb, I even noted in my previous comment:

the first line of that file is what allowed me to write mouse/controller movements, not necessary for reading from the device.

And now that I take a closer look at the error, I see that it's actually this very same thing I was talking about: in mouse mode it creates a uinput to write out the mouse movement. So the issue I'm seeing is writing, not reading. We should add one more udev file that adds a rule for writing uinput:

KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

[wheaney]

One other question I had during the setup:

systemctl --user enable --now xreal-air-driver

There's no way for the pacman install to do this, I'm assuming? Or would it automatically enable after a restart?

[hodasemi]

KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"

That would apply to xreal right?

---

There's no way for the pacman install to do this, I'm assuming? Or would it automatically enable after a restart?

No, that is also something I looked for, but it seems that is by design.

[wheaney]

That would apply to xreal right?

It should probably just be in its own generic xr-driver udev file, as it's needed for all glasses.

The udev rule alone didn't solve the issue I was seeing, though. It turns out we also need to make sure the uinput module is loaded, this normally requires a call like: sudo modprobe uinput, but that won't be doable from PKGBUILD. Instead, according to Claude, we can add this to the PKGBUILD:

install -Dm644 /dev/null "$pkgdir/usr/lib/modules-load.d/$pkgname.conf"
echo "uinput" > "$pkgdir/usr/lib/modules-load.d/$pkgname.conf"

With that module installed, I finally got mouse output working from the driver. We should add post_install messaging to the PKGBUILD that provides instructions for starting the systemd service, and also loading the udev rules using udevadm (e.g. sudo udevadm control --reload-rules && sudo udevadm trigger).

[hodasemi]

It should probably just be in its own generic xr-driver udev file, as it's needed for all glasses.

I still need to match product and vendor id, otherwise it would apply to everything else, not just xr glass related.

[hodasemi]

I added the hooks.install file which is linked in the PKGBUILD. There is defined that it modprobe uinput after package install und reloads udev rules whenever the package is installed or upgraded. I also added an echo that tells the user to enable the systemd service and how to do that.

[wheaney]

I still need to match product and vendor id, otherwise it would apply to everything else, not just xr glass related.

I don't think this makes sense. The uinput creation is not related to the glasses at all. It's a permission you're giving the user, so user processes can create and modify uinput files.

[wheaney]

I just tried out the latest and I didn't see this in the terminal:

start service after install: systemctl --user enable --now xreal-air-driver.service

So I'm not sure if any of the hook.install stuff happened. Is this just an issue with makepkg or should the hook be working for me?

[hodasemi]

It works for me. A note: it only shows the message on install not on update, that means if you have it already installed and install it once again it doesn't show up. You have to remove it first and install it anew.

$ makepkg
...
[100%] Linking C executable xrealAirLinuxDriver
[100%] Built target xrealAirLinuxDriver
==> Entering fakeroot environment...
==> Starting package()...
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> WARNING: Package contains reference to $srcdir
usr/bin/xrealAirLinuxDriver
==> Creating package "XRLinuxDriver-BreezyGNOME"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Adding install file...                                                               <-- Important line
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: XRLinuxDriver-BreezyGNOME 0.1-1 (Do 18 Jul 2024 05:33:50 CEST)

# pacman -U XRLinuxDriver-BreezyGNOME-0.1-1-x86_64.pkg.tar.zst
...
(1/1) checking for file conflicts                  [######################] 100%
(1/1) checking available disk space                [######################] 100%
:: Processing package changes...
(1/1) installing XRLinuxDriver-BreezyGNOME         [######################] 100%
start service after install: systemctl --user enable --now xreal-air-driver.service       <-- Important line
:: Running post-transaction hooks...
(1/3) Reloading user manager configuration...
(2/3) Reloading device manager configuration...
(3/3) Arming ConditionNeedsUpdate...