Setup bridge
Créer le bridge
Copie-colle ce bloc entier :
cat >/tmp/vtc-telemetry-bridge.c /tmp/vtc-...
SETUP BRIDGE
Setup bridge
Créer le bridge
Copie-colle ce bloc entier :
cat >/tmp/vtc-telemetry-bridge.c <<'EOF'
#define WIN32_LEAN_AND_MEAN
#include
#include
#include
#define TELEMETRY_SIZE 32768
static const wchar_t *SOURCE =
L"Z:\\dev\\shm\\SCSTelemetry";
static const wchar_t *MAPPING =
L"Local\\SCSTelemetry";
int wmain(void)
{
HANDLE mapping;
HANDLE source;
void *view;
BYTE buffer[TELEMETRY_SIZE];
DWORD read_bytes;
DWORD err;
printf("=== VTC TELEMETRY BRIDGE ===\n");
fflush(stdout);
printf("Creation de Local\\\\SCSTelemetry...\n");
fflush(stdout);
mapping = CreateFileMappingW(
INVALID_HANDLE_VALUE,
NULL,
PAGE_READWRITE,
0,
TELEMETRY_SIZE,
MAPPING
);
if (mapping == NULL) {
err = GetLastError();
fprintf(stderr,
"ERREUR CreateFileMappingW: %lu\n",
(unsigned long)err);
return 1;
}
err = GetLastError();
if (err == ERROR_ALREADY_EXISTS) {
printf("Mapping deja existant.\n");
} else {
printf("Mapping cree.\n");
}
fflush(stdout);
view = MapViewOfFile(
mapping,
FILE_MAP_READ | FILE_MAP_WRITE,
0,
0,
TELEMETRY_SIZE
);
if (view == NULL) {
err = GetLastError();
fprintf(stderr,
"ERREUR MapViewOfFile: %lu\n",
(unsigned long)err);
CloseHandle(mapping);
return 2;
}
printf("MapViewOfFile OK.\n");
fflush(stdout);
source = INVALID_HANDLE_VALUE;
for (;;) {
if (source == INVALID_HANDLE_VALUE) {
source = CreateFileW(
SOURCE,
GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL
);
if (source == INVALID_HANDLE_VALUE) {
static int warned = 0;
if (!warned) {
err = GetLastError();
fprintf(stderr,
"Attente de %ls (erreur %lu)...\n",
SOURCE,
(unsigned long)err);
fflush(stderr);
warned = 1;
}
Sleep(500);
continue;
}
printf("Source /dev/shm/SCSTelemetry ouverte.\n");
fflush(stdout);
}
if (!SetFilePointer(source, 0, NULL, FILE_BEGIN)) {
/* On tente simplement de relire au prochain cycle. */
}
read_bytes = 0;
if (!ReadFile(
source,
buffer,
TELEMETRY_SIZE,
&read_bytes,
NULL
) || read_bytes != TELEMETRY_SIZE) {
CloseHandle(source);
source = INVALID_HANDLE_VALUE;
Sleep(100);
continue;
}
CopyMemory(view, buffer, TELEMETRY_SIZE);
Sleep(20);
}
return 0;
}
EOF
WINEPREFIX="$HOME/.wine-vtcmanager" \
winegcc -m64 -mwindows \
-o /tmp/vtc-telemetry-bridge.exe \
/tmp/vtc-telemetry-bridge.c
ls -lh /tmp/vtc-telemetry-bridge*
2. Puis lance-le
Une fois la compilation terminée, lance :
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/wine \
/tmp/vtc-telemetry-bridge.exe
Laisse cette fenêtre tourner.
Le résultat intéressant est quelque chose comme :
=== VTC TELEMETRY BRIDGE ===
Creation de Local\SCSTelemetry...
Mapping cree.
MapViewOfFile OK.
Source /dev/shm/SCSTelemetry ouverte.
Si tu obtiens ces quatre lignes, on aura enfin créé le chaînon qui manque entre ETS2 Linux et LiveTelemetry.
Oui, on a identifié le problème exact : le bridge n'a même pas été compilé. winegcc est installé, mais les headers de développement Wine (windows.h) ne le sont pas.
Donc l'erreur :
fatal error: windows.h : Aucun fichier ou dossier de ce nom
est côté environnement de compilation, pas côté ETS2/Wine.
Et le second message :
wine: failed to open "/tmp/vtc-telemetry-bridge.exe"
est simplement la conséquence : le .exe n'a jamais été créé.
On ne réinstalle rien au hasard. Fais juste cette vérification :
echo '=== HEADERS WINE ==='
find /opt/wine-staging /usr/include /usr/local/include \
-type f -name 'windows.h' 2>/dev/null | head -20
echo
echo '=== WINE DEVELOPMENT ==='
ls -ld /opt/wine-staging/include 2>/dev/null || true
ls -ld /usr/include/wine* 2>/dev/null || true
echo
echo '=== DISTRIBUTION ==='
cat /etc/os-release | grep -E '^(ID|VERSION_ID)='
Voilà, on a maintenant la cause précise : ton installation Wine-Staging contient winegcc, mais pas les headers de développement. C'est pour ça que windows.h manque.
Comme tu es sur Nobara 44, je te propose d'installer uniquement le nécessaire, pas de toucher à Wine lui-même. Nobara 44 est basé sur les dépôts Fedora, avec des snapshots de paquets Fedora.
Le plus simple est d'installer les outils MinGW 64 bits : Fedora fournit bien le sous-paquet mingw64-gcc pour compiler des programmes Windows 64 bits.
Fais ceci
sudo dnf install mingw64-gcc mingw64-gcc-c++
Quand dnf te demande confirmation, réponds :
y
Puis vérifie :
command -v x86_64-w64-mingw32-gcc
x86_64-w64-mingw32-gcc --version
Si tu obtiens bien /usr/bin/x86_64-w64-mingw32-gcc, arrête-toi là et envoie-moi la sortie.
Je corrigerai ensuite la commande de compilation précédente : avec MinGW, on n'aura plus besoin de dépendre des headers absents de winegcc.
Et je corrige aussi un détail de ma commande précédente : le chemin source Z:\dev\shm\SCSTelemetry sera écrit proprement dans le C. Le contenu que ton terminal a reçu contient des échappements supplémentaires (\<, \#, etc.), donc même avec les headers il aurait fallu le corriger.
Parfait. Le compilateur Windows 64 bits est maintenant installé et fonctionnel. On peut passer au vrai bridge.
Je corrige au passage le problème de la commande précédente : ton terminal avait transformé certains caractères (\#, \<, etc.), donc on repart d'un fichier propre.
1. Remplacer le fichier par une version propre
Copie-colle exactement ce bloc :
cat >/tmp/vtc-telemetry-bridge.c <<'EOF'
#define WIN32_LEAN_AND_MEAN
#include
#include
#define TELEMETRY_SIZE 32768
static const wchar_t *SOURCE =
L"Z:\\dev\\shm\\SCSTelemetry";
static const wchar_t *MAPPING =
L"Local\\SCSTelemetry";
int main(void)
{
HANDLE mapping;
HANDLE source;
void *view;
unsigned char buffer[TELEMETRY_SIZE];
DWORD read_bytes;
DWORD err;
printf("=== VTC TELEMETRY BRIDGE ===\n");
fflush(stdout);
printf("Creation de Local\\\\SCSTelemetry...\n");
fflush(stdout);
mapping = CreateFileMappingW(
INVALID_HANDLE_VALUE,
NULL,
PAGE_READWRITE,
0,
TELEMETRY_SIZE,
MAPPING
);
if (mapping == NULL) {
err = GetLastError();
fprintf(stderr,
"ERREUR CreateFileMappingW: %lu\n",
(unsigned long)err);
return 1;
}
err = GetLastError();
if (err == ERROR_ALREADY_EXISTS) {
printf("Mapping deja existant.\n");
} else {
printf("Mapping cree.\n");
}
fflush(stdout);
view = MapViewOfFile(
mapping,
FILE_MAP_READ | FILE_MAP_WRITE,
0,
0,
TELEMETRY_SIZE
);
if (view == NULL) {
err = GetLastError();
fprintf(stderr,
"ERREUR MapViewOfFile: %lu\n",
(unsigned long)err);
CloseHandle(mapping);
return 2;
}
printf("MapViewOfFile OK.\n");
fflush(stdout);
source = INVALID_HANDLE_VALUE;
for (;;) {
if (source == INVALID_HANDLE_VALUE) {
source = CreateFileW(
SOURCE,
GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL
);
if (source == INVALID_HANDLE_VALUE) {
Sleep(500);
continue;
}
printf("Source /dev/shm/SCSTelemetry ouverte.\n");
fflush(stdout);
}
SetFilePointer(source, 0, NULL, FILE_BEGIN);
read_bytes = 0;
if (!ReadFile(
source,
buffer,
TELEMETRY_SIZE,
&read_bytes,
NULL
) || read_bytes != TELEMETRY_SIZE) {
CloseHandle(source);
source = INVALID_HANDLE_VALUE;
Sleep(100);
continue;
}
CopyMemory(view, buffer, TELEMETRY_SIZE);
Sleep(20);
}
return 0;
}
EOF
2. Compiler
x86_64-w64-mingw32-gcc \
-O2 \
-static \
-static-libgcc \
-o /tmp/vtc-telemetry-bridge.exe \
/tmp/vtc-telemetry-bridge.c
file /tmp/vtc-telemetry-bridge.exe
ls -lh /tmp/vtc-telemetry-bridge.exe
Tu devrais obtenir quelque chose ressemblant à :
PE32+ executable x86-64
3. Lancer le bridge
Ne redémarre pas VTC Manager pour le moment.
Lance simplement :
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/wine \
/tmp/vtc-telemetry-bridge.exe
On cherche surtout ces lignes :
=== VTC TELEMETRY BRIDGE ===
Creation de Local\\SCSTelemetry...
Mapping cree.
MapViewOfFile OK.
Source /dev/shm/SCSTelemetry ouverte.
Si tu obtiens Mapping cree + MapViewOfFile OK + Source ... ouverte, c'est le test clé : le bridge aura réussi à créer le même type de mapping Windows que celui que LiveTelemetry cherche avec OpenFileMapping.
Laisse le programme tourner et envoie-moi sa sortie. Ne ferme pas le terminal avant que je te dise quoi faire ensuite.
Excellent : le point le plus important est réussi.
On a maintenant :
Mapping cree.
MapViewOfFile OK.
Donc Wine sait bien créer Local\SCSTelemetry dans le préfixe VTCManager. C'était le gros verrou.
Il manque juste la dernière partie : le bridge n'affiche pas encore Source /dev/shm/SCSTelemetry ouverte.. Il faut donc corriger l'accès au fichier Linux.
1. Arrête le bridge
Dans le terminal où il tourne :
Ctrl+C
2. Test direct de l'accès à /dev/shm
Puis copie-colle :
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/wine \
cmd /c 'dir Z:\dev\shm\SCSTelemetry'
Envoie-moi la sortie exacte.
Le résultat attendu serait quelque chose comme :
SCSTelemetry
avec une taille de 32768.
Si ce test fonctionne, je te donne immédiatement la version corrigée du bridge avec :
ouverture de /dev/shm/SCSTelemetry ;
copie continue des 32 KiB ;
maintien permanent de Local\SCSTelemetry ;
puis on fera un seul redémarrage de LiveTelemetry, car son init() ouvre le mapping au démarrage et ne le crée pas lui-même.
On est vraiment sur la dernière étape maintenant.
D'accord. Cette sortie ne montre aucune erreur d'accès, mais surtout aucun résultat dir. Donc le test cmd n'est pas suffisamment fiable ici.
On sait déjà que Local\SCSTelemetry est créé correctement. Je vais éviter de te faire refaire des tests inutiles.
On va tester directement le chemin Z: utilisé par le bridge, avec winepath, qui est beaucoup plus propre :
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/winepath -w /dev/shm/SCSTelemetry
echo '---'
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/winepath -u 'Z:\dev\shm\SCSTelemetry'
Puis, juste après :
ls -lh /dev/shm/SCSTelemetry
Le résultat attendu serait quelque chose comme :
SCSTelemetry
avec une taille de 32768.
Si ce test fonctionne, je te donne immédiatement la version corrigée du bridge avec :
ouverture de /dev/shm/SCSTelemetry ;
copie continue des 32 KiB ;
maintien permanent de Local\SCSTelemetry ;
puis on fera un seul redémarrage de LiveTelemetry, car son init() ouvre le mapping au démarrage et ne le crée pas lui-même.
On est vraiment sur la dernière étape maintenant.
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/winepath -w /dev/shm/SCSTelemetry
echo '---'
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/winepath -u 'Z:\dev\shm\SCSTelemetry'
ls -lh /dev/shm/SCSTelemetry
Le seul élément qui bloque maintenant est :
/dev/shm/SCSTelemetry
↓
CreateFileW(...)
↓
lecture par le programme Windows sous Wine
Le chemin Wine est parfaitement correct.
Mais actuellement :
ls: impossible d'accéder à '/dev/shm/SCSTelemetry': Aucun fichier ou dossier de ce nom
Donc ETS2 n'est actuellement plus en train de créer le fichier /dev/shm/SCSTelemetry. Le bridge était bien capable de créer Local\SCSTelemetry, mais il attendait une source qui n'existe plus.
Fais maintenant ceci
1. Lance ETS2 normalement et arrive jusqu'au jeu, avec ta partie chargée.
2. Une fois dans le jeu, ouvre un deuxième terminal et vérifie :
ls -lh /dev/shm/SCSTelemetry
Si le fichier est bien là, lance immédiatement le bridge :
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/wine \
/tmp/vtc-telemetry-bridge.exe
Cette fois, on devrait obtenir :
=== VTC TELEMETRY BRIDGE ===
Creation de Local\\SCSTelemetry...
Mapping cree.
MapViewOfFile OK.
Source /dev/shm/SCSTelemetry ouverte.
Ensuite
Si Source /dev/shm/SCSTelemetry ouverte. apparaît, ne redémarre encore rien. À ce moment-là, le bridge fera réellement :
ETS2
↓
/dev/shm/SCSTelemetry
↓
bridge
↓
Local\SCSTelemetry
↓
LiveTelemetry
C'est exactement le chaînon qui manquait dans notre diagnostic.
Envoie-moi simplement la sortie du bridge après avoir relancé ETS2.
Oui. Là, le bridge fonctionne réellement. 🎯
On a maintenant les trois maillons validés :
ETS2 Linux
│
├── /dev/shm/SCSTelemetry ← 32 KiB, présent
│
▼
VTC Telemetry Bridge
│
├── Local\SCSTelemetry ← créé
├── MapViewOfFile OK ← ouvert
└── source ouverte ← lecture OK
Il reste maintenant une seule chose à vérifier : LiveTelemetry doit réussir à ouvrir ce mapping existant.
Étape suivante
Ne ferme PAS le terminal du bridge. Il doit rester ouvert.
Ouvre un nouveau terminal et exécute :
systemctl --user restart 'app-Live\x20Telemetry VTCManager@bbee77aeb74245408b148df0eecb2d57.service'
Puis attends environ 5 secondes et fais :
systemctl --user --no-pager status 'app-Live\x20Telemetry VTCManager@bbee77aeb74245408b148df0eecb2d57.service'
Et enfin :
journalctl --user -u 'app-Live\x20Telemetry VTCManager@bbee77aeb74245408b148df0eecb2d57.service' -n 30 --no-pager
Ce qu'on cherche
Avant, le service finissait avec :
status=3/NOTIMPLEMENTED
Maintenant, si notre hypothèse est correcte, LiveTelemetry devrait pouvoir faire :
OpenFileMapping("Local\\SCSTelemetry")
↓
MapViewOfFile
↓
lecture des données ETS2
Et surtout, nous avons déjà prouvé que le mapping est créé dans le même WINEPREFIX et le même wineserver que LiveTelemetry.
Envoie-moi les sorties des deux dernières commandes. Si LiveTelemetry démarre correctement, on passera ensuite à la dernière étape : rendre le bridge automatique au démarrage, plutôt que de devoir garder le terminal ouvert.
Oui 👍 laisse ETS2 ouvert et en jeu, surtout ne le ferme pas pour l’instant.
Et laisse aussi le terminal du bridge ouvert avec :
Mapping cree.
MapViewOfFile OK.
Source /dev/shm/SCSTelemetry ouverte.
Ensuite, fais simplement le redémarrage de LiveTelemetry que je t’ai indiqué.
OK. Le bridge fonctionne, mais LiveTelemetry retourne toujours status=3/NOTIMPLEMENTED. Ce n’est donc pas encore gagné.
Point important : les deux processus LiveTelemetry.exe sont toujours présents (91662 et 91664), donc le status=3 concerne le lanceur/service, pas forcément le processus LiveTelemetry lui-même.
On va vérifier directement si LiveTelemetry est toujours vivant et depuis quand.
Copie-colle uniquement ceci :
ps -o pid,ppid,stat,etime,cmd -p 91662,91664
Ne ferme ni ETS2 ni le terminal du bridge.
Parfait. C’est une information importante : LiveTelemetry tourne réellement depuis plus d’une minute. Le status=3/NOTIMPLEMENTED est donc probablement le code de sortie du lanceur .lnk, pas un crash de LiveTelemetry.
Maintenant on vérifie le point essentiel : est-ce que LiveTelemetry a bien ouvert Local\SCSTelemetry et reçoit les données du bridge ?
Ne ferme rien. Lance :
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/wine \
/tmp/vtc-telemetry-bridge.exe
⚠️ Non, attends : ne lance surtout pas une deuxième instance du bridge. Celle qui tourne déjà suffit.
À la place, exécute simplement :
pgrep -af 'vtc-telemetry-bridge|LiveTelemetry.exe'
Oui, c’est le même résultat — et c’est bon signe : les deux LiveTelemetry sont toujours actifs.
On va maintenant vérifier qu’il n’y a bien qu’un seul bridge en cours.
Copie-colle :
pgrep -af 'vtc-telemetry-bridge|LiveTelemetry.exe'
Puis envoie-moi exactement le résultat.
Parfait. On a exactement ce qu'il faut :
91154 → un seul bridge actif ✅
91662 + 91664 → LiveTelemetry actif ✅
ETS2 est ouvert et /dev/shm/SCSTelemetry contient les données ✅
Donc la chaîne est maintenant en place.
Dernière vérification
On va voir si LiveTelemetry a effectivement une erreur concernant la télémétrie. Ne ferme rien et exécute :
journalctl --user -u 'app-Live\x20Telemetry\x20VTCManager\@bbee77aeb74245408b148df0eecb2d57.service' --since '5 minutes ago' --no-pager | grep -Ei 'error|exception|telemetry|shared|memory|SCSTelemetry|failed|notimplemented'
Envoie-moi le résultat.
Si cette commande ne retourne rien de pertinent, on passera directement à la vérification dans VTC Manager plutôt que de continuer à tourner en rond avec Wine.
Très bien. Aucune erreur télémétrie/mémoire n'est remontée par le service.
On a donc maintenant :
ETS2 → /dev/shm/SCSTelemetry ✅
Bridge → Local\SCSTelemetry ✅
LiveTelemetry → processus actifs ✅
Journal → aucune erreur pertinente ✅
👉 On arrête les diagnostics système pour l'instant.
Regarde maintenant dans VTC Manager si les données de conduite apparaissent : vitesse, camion, position, etc.
Dis-moi simplement ce que tu vois dans VTC Manager :
les données apparaissent ;
VTC Manager indique Live Telemetry connecté mais pas de données ;
ou rien du tout.
À partir de ça, je te donne directement la prochaine étape.
Ne ferme ni ETS2 ni le bridge.
Exécute :
sha256sum /dev/shm/SCSTelemetry
Le fichier ETS2 est bien présent et contient des données. 👍
Mais ce hash ne nous permet pas encore de vérifier le contenu du mapping Windows Local\SCSTelemetry. C'est justement ce qu'il faut contrôler maintenant.
On va faire un petit test qui ouvre le mapping déjà créé par notre bridge sans rien modifier.
Copie-colle cette commande :
cat > /tmp/check-vtc-map.c <<'EOF'
#include
#include
int main(void) {
const wchar_t *name = L"Local\\SCSTelemetry";
HANDLE h = OpenFileMappingW(FILE_MAP_READ, FALSE, name);
if (!h) {
printf("OpenFileMapping ECHEC : %lu\n", GetLastError());
return 1;
}
printf("OpenFileMapping OK\n");
unsigned char *p = (unsigned char *)MapViewOfFile(h, FILE_MAP_READ, 0, 0, 32768);
if (!p) {
printf("MapViewOfFile ECHEC : %lu\n", GetLastError());
CloseHandle(h);
return 2;
}
unsigned long long sum = 1469598103934665603ULL;
for (int i = 0; i < 32768; i++) {
sum ^= p[i];
sum *= 1099511628211ULL;
}
printf("FNV64 mapping : %016llx\n", sum);
printf("Premiers octets :");
for (int i = 0; i < 32; i++)
printf(" %02x", p[i]);
printf("\n");
UnmapViewOfFile(p);
CloseHandle(h);
return 0;
}
EOF
x86_64-w64-mingw32-gcc -O2 -o /tmp/check-vtc-map.exe /tmp/check-vtc-map.c
WINEPREFIX="$HOME/.wine-vtcmanager" /opt/wine-staging/bin/wine /tmp/check-vtc-map.exe
Ne ferme toujours ni ETS2 ni le bridge.
Excellent. C’est une avancée importante.
OpenFileMapping OK prouve que LiveTelemetry et notre bridge voient bien le même objet Windows Local\SCSTelemetry. Donc le problème n’est plus la création du mapping.
Les premiers octets du mapping sont également présents :
00 00 00 00 01 00 00 00 ...
Maintenant il faut vérifier que le mapping contient exactement les données actuellement produites par ETS2.
Ne ferme rien. Exécute simplement :
python3 -c 'import hashlib; d=open("/dev/shm/SCSTelemetry","rb").read(); print("SHA256 source :", hashlib.sha256(d).hexdigest()); print("Premiers octets :", " ".join(f"{x:02x}" for x in d[:32]))'
/dev/shm/SCSTelemetry commence par 01 00 00 00 01 00...
Local\SCSTelemetry commence par 00 00 00 00 01 00...
Donc le bridge a bien créé le mapping, mais il ne le met pas correctement à jour. C'est exactement ce qui explique pourquoi VTC Manager reste sur « en attente du jeu ».
On va corriger le bridge. Ne ferme pas ETS2.
1. Arrêter uniquement l'ancien bridge
kill 91154
Puis vérifie :
pgrep -af 'vtc-telemetry-bridge'
Tu ne devrais plus avoir de ligne.
C'est bon : le bridge 91154 n'est plus lancé. 👍
Et je corrige un point important de mon message précédent : le décalage que nous avons vu ne suffit pas à conclure que la copie est cassée, car le bridge venait justement de s'arrêter entre les deux tests. On va repartir proprement avec une version corrigée qui vérifie elle-même que le mapping reçoit bien les données.
Ne ferme pas ETS2 ni VTC Manager.
Lance d'abord :
pgrep -af 'vtc-telemetry-bridge|LiveTelemetry.exe'
Parfait. LiveTelemetry tourne toujours, mais le bridge est arrêté.
On va maintenant relancer le bridge avec une version qui vérifie elle-même la copie entre /dev/shm/SCSTelemetry et Local\SCSTelemetry.
Copie-colle tout ce bloc :
cat > /tmp/vtc-telemetry-bridge.c <<'EOF'
#include
#include
#define TELEMETRY_SIZE 32768
#define SOURCE L"Z:\\dev\\shm\\SCSTelemetry"
#define MAPPING L"Local\\SCSTelemetry"
static unsigned long long fnv64(const unsigned char *p, size_t n)
{
unsigned long long h = 1469598103934665603ULL;
for (size_t i = 0; i < n; i++) {
h ^= p[i];
h *= 1099511628211ULL;
}
return h;
}
int main(void)
{
unsigned char buffer[TELEMETRY_SIZE];
printf("=== VTC TELEMETRY BRIDGE v2 ===\n");
HANDLE map = CreateFileMappingW(
INVALID_HANDLE_VALUE,
NULL,
PAGE_READWRITE,
0,
TELEMETRY_SIZE,
MAPPING
);
if (!map) {
printf("CreateFileMapping ECHEC : %lu\n", GetLastError());
return 1;
}
if (GetLastError() == ERROR_ALREADY_EXISTS)
printf("Mapping existait deja.\n");
else
printf("Mapping cree.\n");
unsigned char *view = (unsigned char *)MapViewOfFile(
map,
FILE_MAP_ALL_ACCESS,
0,
0,
TELEMETRY_SIZE
);
if (!view) {
printf("MapViewOfFile ECHEC : %lu\n", GetLastError());
CloseHandle(map);
return 2;
}
printf("MapViewOfFile OK.\n");
printf("Attente de /dev/shm/SCSTelemetry...\n");
unsigned long counter = 0;
for (;;) {
HANDLE src = CreateFileW(
SOURCE,
GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL
);
if (src == INVALID_HANDLE_VALUE) {
if ((counter++ % 25) == 0)
printf("Source absente, attente...\n");
Sleep(500);
continue;
}
DWORD read = 0;
SetFilePointer(src, 0, NULL, FILE_BEGIN);
BOOL ok = ReadFile(
src,
buffer,
TELEMETRY_SIZE,
&read,
NULL
);
CloseHandle(src);
if (!ok || read != TELEMETRY_SIZE) {
printf("ReadFile ECHEC/partiel : %lu octets=%lu\n",
GetLastError(), read);
Sleep(100);
continue;
}
CopyMemory(view, buffer, TELEMETRY_SIZE);
if ((counter++ % 50) == 0) {
printf(
"Copie OK | source FNV64=%016llx | mapping FNV64=%016llx | octets=%02x %02x %02x %02x\n",
fnv64(buffer, TELEMETRY_SIZE),
fnv64(view, TELEMETRY_SIZE),
view[0], view[1], view[2], view[3]
);
fflush(stdout);
}
Sleep(20);
}
return 0;
}
EOF
x86_64-w64-mingw32-gcc -O2 -o /tmp/vtc-telemetry-bridge.exe /tmp/vtc-telemetry-bridge.c
WINEPREFIX="$HOME/.wine-vtcmanager" \
/opt/wine-staging/bin/wine \
/tmp/vtc-telemetry-bridge.exe
Important
Quand tu vois :
Mapping cree.
MapViewOfFile OK.
Attente de /dev/shm/SCSTelemetry...
laisse ce terminal ouvert.
Puis attends quelques secondes et regarde s'il affiche une ligne du genre :
Copie OK | source FNV64=XXXXXXXX | mapping FNV64=XXXXXXXX | octets=01 00 00 00
👉 Les deux FNV64 doivent être identiques.
Excellent. Là, on a une preuve solide :
le bridge fonctionne parfaitement.
À chaque lecture, le contenu de /dev/shm/SCSTelemetry est copié à l'identique dans Local\SCSTelemetry.
Donc le problème restant est du côté de LiveTelemetry/VTC Manager, pas d'ETS2 ni du bridge.
Et surtout, il y a un détail très important : LiveTelemetry était déjà lancé avant que nous recréions le mapping. Il a donc probablement tenté create=False alors que le mapping n'existait pas encore, puis est resté dans son état d'attente.
On va faire une seule chose maintenant
Laisse le terminal du bridge ouvert.
Dans un deuxième terminal, exécute :
systemctl --user restart 'app-Live\x20Telemetry VTCManager@bbee77aeb74245408b148df0eecb2d57.service'
Attends 5 secondes, puis :
pgrep -af 'LiveTelemetry.exe'
Envoie-moi le résultat.
⚠️ Ne touche pas au terminal où défilent les Copie OK
Parfait. LiveTelemetry a bien été relancé avec le mapping déjà présent. ✅
Maintenant, regarde VTC Manager sans fermer ETS2 ni le bridge.
Dis-moi exactement ce qu'il affiche maintenant :
« connecté » / les données apparaissent ;
toujours « en attente du jeu » ;
ou un autre message.
C'est le test décisif.
YES ! C’est bon !
On a réussi à faire fonctionner toute la chaîne :
ETS2 Linux → /dev/shm/SCSTelemetry → notre bridge → Local\SCSTelemetry → LiveTelemetry → VTC Manager
Et surtout, les données apparaissent maintenant dans VTC Manager. ✅
⚠️ Pour l'instant, ne ferme pas le terminal du bridge
Il est indispensable actuellement. Si tu le fermes, le mapping Local\SCSTelemetry disparaîtra et VTC Manager repassera probablement en attente.
La prochaine étape sera de rendre le bridge automatique, pour que tu n'aies plus à lancer cette commande manuellement à chaque démarrage.
Mais puisque ça fonctionne enfin, on ne touche plus au fonctionnement actuel avant de sécuriser une copie du bridge.
Oui. 👍 On va maintenant automatiser le bridge, sans toucher à ETS2 ni aux fichiers u1000-Shm_*.
Le principe : le bridge démarrera avec ta session, attendra automatiquement ETS2 si nécessaire, et restera en fonctionnement pour VTC Manager.
1. Installer le bridge à un emplacement permanent
Dans un nouveau terminal, copie-colle :
mkdir -p "$HOME/.local/bin" "$HOME/.config/systemd/user"
cp /tmp/vtc-telemetry-bridge.exe "$HOME/.local/bin/vtc-telemetry-bridge.exe"
chmod 755 "$HOME/.local/bin/vtc-telemetry-bridge.exe"
2. Créer le service automatique
cat > "$HOME/.config/systemd/user/vtc-telemetry-bridge.service" <<'EOF'
[Unit]
Description=VTC Manager telemetry bridge ETS2 Linux -> Wine
After=graphical-session.target
[Service]
Type=simple
Environment=WINEPREFIX=%h/.wine-vtcmanager
ExecStart=/opt/wine-staging/bin/wine %h/.local/bin/vtc-telemetry-bridge.exe
Restart=always
RestartSec=2
[Install]
WantedBy=default.target
EOF
3. Activer le service
systemctl --user daemon-reload
systemctl --user enable vtc-telemetry-bridge.service
Ne démarre pas encore le nouveau service, car ton bridge manuel fonctionne toujours.
Envoie-moi simplement :
systemctl --user is-enabled vtc-telemetry-bridge.service
Si ça répond enabled, on fera le basculement proprement, sans interrompre VTC Manager plus longtemps que nécessaire.
Parfait ✅ Le service est bien activé pour les prochains démarrages de ta session.
Il reste à faire le basculement du bridge manuel vers le service automatique.
1. Arrête le bridge manuel
Dans le terminal où il défile encore :
Ctrl+C
2. Démarre le bridge via systemd
Dans l'autre terminal :
systemctl --user start vtc-telemetry-bridge.service
Puis vérifie :
systemctl --user --no-pager status vtc-telemetry-bridge.service
Tu dois voir :
Active: active (running)
3. Vérifie qu'il tourne bien
pgrep -af 'vtc-telemetry-bridge'
Envoie-moi le résultat du status et du pgrep.
👉 Ne redémarre pas ETS2 ni VTC Manager pour l'instant.
arfait ✅
Le bridge est maintenant lancé par systemd depuis son emplacement permanent :
/home/dodo/.local/bin/vtc-telemetry-bridge.exe
Donc on a réussi la partie automatique.
Dernière vérification
Exécute :
systemctl --user --no-pager status vtc-telemetry-bridge.service
🎉 Parfait, c'est validé.
Le service est :
enabled → il démarrera automatiquement à ta session ✅
active (running) → il tourne correctement ✅
les FNV64 source = mapping à chaque fois → les données ETS2 sont transmises correctement en continu ✅
aucune erreur de redémarrage → le bridge est stable ✅
Il reste seulement à automatiser l'ordre de démarrage pour éviter le problème initial après un redémarrage du PC : le bridge doit être lancé avant LiveTelemetry.
On peut le faire proprement avec une petite modification du service LiveTelemetry, mais comme tout fonctionne actuellement, je te conseille de ne pas modifier davantage tant que tu n'as pas besoin de redémarrer le PC.
Pour aujourd'hui
Tu peux laisser :
ETS2 → Bridge systemd → LiveTelemetry → VTC Manager
et VTC Manager reçoit bien les données. 🎯
Après un redémarrage du PC, si VTC Manager affiche de nouveau « en attente du jeu », ne panique pas et ne recommence pas les 6 heures de diagnostics : le bridge est maintenant installé et activé. On pourra simplement régler l'ordre de démarrage.
Le plus important : ne supprime surtout pas les fichiers u1000-Shm_*.