xreal-linux exécute les lunettes Xreal 1S comme casque 3DoF SteamVR sur un Steam Deck

L’article ne peut pas être activé avec JavaScript. Vous pouvez également activer JavaScript dans votre navigateur et sur la nouvelle page.

Un projet appelé xreal-linux a marqué sa première version le 8 octobre à 20h08 UTC, et il fait fonctionner une paire de lunettes d’affichage Xreal 1S en tant que casque 3DoF SteamVR sur un Steam Deck. La rotation de la tête provient des propres capteurs des lunettes, il n’y a pas de suivi de position et la balise est v0.1.0-rc1, une AppImage qui, selon la note de version, a été construite à partir du commit 75c5b7d dans le SDK Steam Runtime épinglé. Une deuxième pré-version, v0.1.0-rc2, a suivi à 21h20 UTC le même jour.

L’auteur est attentif à ce qui a été essayé. « Vérifié sur un Steam Deck (Bazzite, mode bureau, Plasma sur Wayland, GPU AMD) », indique le référentiel, tandis que « les GPU NVIDIA et Intel ne sont pas encore pris en charge (non testés), et la caméra Eye (6DoF) n’est pas utilisée ». Le mode de jeu du Deck, Flatpak Steam et tout GPU non AMD, se trouve sous la rubrique « Non promis ».

Les notes d’ingénierie constituent la moitié substantielle

À côté du programme d’installation se trouve un long fichier de mesures, lu à 21h25 UTC le 8 octobre, décrivant en détail à quoi ressemble un Xreal 1S pour un hôte Linux. Tout ce qu’il contient a été « observé sur un XREAL 1S (firmware bcdDevice 4.09) plus un XREAL Eye », et les notes conservent une étiquette distincte pour tout ce qui est extrait d’autres projets plutôt que mesuré.

Les lunettes sont répertoriées comme un seul périphérique USB 2.0, 3318:043eavec neuf interfaces : un canal de contrôle HID resté silencieux, deux paires Ethernet virtuelles, trois interfaces audio USB et un deuxième HID pour les boutons physiques. Aucune caméra UVC ni aucun nœud vidéo n’apparaissent pour l’Œil.

Les deux liaisons Ethernet virtuelles exécutent un serveur DHCP sur les lunettes, transmettant à l’hôte 169.254.2.10 et 169.254.1.10 et répondant sur 169.254.2.1 et 169.254.1.1, avec des temps de ping d’environ 0,4 ms sur l’une et de 2 à 3 ms sur l’autre. Les ports TCP 52990 à 52999 sont ouverts sur les deux adresses. Les flux du port 52998 corrigent les enregistrements de 134 octets à environ 1 400 par seconde, que les notes identifient comme le flux du capteur inertiel, et les ports 52990 à 52995 acceptent une connexion et n’envoient ensuite rien du tout.

Un flux a deux lectures et aucune n’est réglée

Le port 52996 envoie des enregistrements d’horodatage de 38 octets, dont 2 997 dans une capture de 25 secondes, que les notes lisent d’abord comme exactement deux par image de caméra. Ils enregistrent plus tard que le débit du flux suit plutôt l’état d’affichage, diminuant lorsque la liaison d’affichage est en panne, et que cela « contredit l’hypothèse antérieure selon laquelle il s’agit de métadonnées de cadre de caméra »: à la deuxième lecture, cela ressemble à un timing d’affichage par rafraîchissement effectué sur la même horloge que le capteur inertiel. Les notes ne sélectionnent ni l’un ni l’autre et appellent la lecture ultérieure « non vérifié enregistrement par enregistrement ».

Deux paramètres différents rapportent tous deux 3840×1080

Les lunettes peuvent se présenter comme un moniteur 16:9, un moniteur 16:10 ou un ultra-large, et l’EDID change avec le réglage. Dans le paramètre ultra-large, un seul mode apparaît, 3840×1080, et les notes corrigent une version antérieure d’elles-mêmes sur ce qu’il est : « un moniteur ultra-large 32:9, pas une image stéréo côte à côte (une version antérieure de ces notes s’est trompée) ».

Le mode côte à côte complet est un paramètre distinct qui signale également un mode 3840×1080, sous un EDID différent, et là, le porteur a vérifié le résultat : le motif de test « montrait la moitié gauche à l’œil gauche et la moitié droite à l’œil droit, avec le décalage de profondeur attendu », tandis qu’en mode 2D normal, les deux moitiés atteignent les deux yeux. C’est le paramètre sur lequel le pilote bascule les lunettes au démarrage de SteamVR et les remet à la fin de la session. Dans les paramètres 16:10 et 16:9, l’EDID décodé, fabricant MRG, produit 0x4102, nom XREAL 1S, comporte six timings : 1920×1200 et 1920×1080, chacun à 60, 90 et 120 Hz.

Trois mises en garde, toutes propres à l’auteur

Le lacet dérive, car le magnétomètre n’est pas utilisable. Une lecture du magnétomètre apparaît à l’intérieur du flux du capteur, mais un ajustement d’étalonnage sur le Deck n’a pas convergé et ce code est ressorti le 8 octobre. Le chemin de la caméra Eye est stationné après qu’un flux démarré par l’hôte n’ait produit que quatre images. Et les deux balises sont des versions candidates sans 1.0 derrière elles, sur un référentiel assis à zéro étoile à 21h24 UTC le 8 octobre. Xreal n’a rien à voir avec tout cela, et Valve non plus, dont SteamVR est simplement l’application sur laquelle le pilote s’inscrit.

L’attention de Xreal est ailleurs. Sa page de magasin Aura répertorie désormais quatre versions qui, selon la FAQ de l’entreprise, ne sont pas annoncées. Le 1S est vendu sous forme d’écran, et sous Linux, c’est toujours ce que l’hôte voit jusqu’à ce que quelque chose comme celui-ci lise lui-même les capteurs.