Hi! I’m testing the Linux build of vTuber Kit v0.2.2 on CachyOS/KDE and found what appears to be an OpenSeeFace/camera initialization issue.
**System:**
* OS: CachyOS (Arch Linux), KDE
* Laptop: HP ENVY x360 Convertible 15m-ed0xxx
* Camera: HP Wide Vision HD Camera
* Integrated GPU: Intel Iris Plus Graphics (ICL GT2)
* Mesa: 26.2.1
* Unity: 2021.3.45f2
The Linux build launches successfully after fixing one filename case-sensitivity issue:
`Custommouth2.png` was packaged, while the application expected `CustomMouth2.png`.
The webcam itself works correctly under Linux. `v4l2-ctl` reports:
`/dev/video0` — MJPEG up to 1280x720 @ 30 FPS and YUYV up to 640x480 @ 30 FPS.
I also successfully tested streaming directly from the camera with:
`v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video0`
and it captured at approximately 30 FPS.
However, selecting any of the camera options (Option A, B, or C) in vTuber Kit does not open `/dev/video0` or `/dev/video1`. Checking with `lsof /dev/video0 /dev/video1` returns nothing.
The Unity `Player.log` shows this error when attempting to list/start the camera:
`EntryPointNotFoundException: CreateJobObject`
with the relevant stack:
`OpenSee.Job.CreateJobObject`
`OpenSee.OpenSeeLauncher.CheckSetup`
`OpenSee.OpenSeeLauncher.ListCameras`
and when starting tracking:
`OpenSee.OpenSeeLauncher.StartTracker`
`OpenSee.OpenSeeLauncher.CameraToggle`
I also inspected the bundled OpenSeeFace directory. It contains Windows components such as:
* `facetracker.exe`
* `dshowcapture_x64.dll`
* `dshowcapture_x86.dll`
* `escapi_x64.dll`
* `escapi_x86.dll`
* `python37.dll`
* multiple `win_amd64.pyd` files
but there are no OpenSeeFace Linux `.so` or Linux executable files present. The only `.bin` found under OpenSeeFace is the model `models/benchmark.bin`.
This makes me suspect the Linux build is currently attempting to use the Windows OpenSeeFace backend, or that the Linux-specific OpenSeeFace component is missing/not being loaded correctly.
The webcam itself appears to be fully functional under Linux, so I don't think this is a V4L2/driver issue.
Hopefully this helps track down the Linux camera/tracking issue.
