[Vehicle] VW Passat B8 GTE 2018 – MHI2_ER_VWG13_K4525 / MU1367 – 12.3" AID Gen1 (3G1920794C): libairplay.so identical to MU1440

[arcidodo]

Area

New platform / vehicle

Topic

Vehicle / platform: VW Passat B8 GTE (PHEV) 2018 / MHI2 Harman, Discover Pro 9.2" 5NA035020A

Firmware / MU: MHI2_ER_VWG13_K4525 / MU1367 (Branch rel/CLU8_VW, HMI H29.319.75, RCC U8826)

Cluster: VW Active Info Display Gen1, 12.3", 3G1920794C, SW 3194 — stock Discover Pro map in the AID (MOST video) works

SSH access: USB-LAN/WLAN

What did you observe?

VW / 12.3" AID Gen1 data point for the untested targets in the README. Nothing from this project is installed; only compatibility-report.sh @ harman-f/mhi2_altscreen_carplay@c2f811f was run (report files only, no install.sh) → MIBR_COMPAT=PASS_READ_ONLY. Its hashes match an offline comparison of my own M.I.B. backup against MU1440_STOCK_REFERENCE.md:

Component	MU1367 size	MU1367 SHA-256	vs MU1440
/mnt/app/eso/lib/libairplay.so	703,688	193a4fd9101ec2aa05e7159cfa307b96500810d379ca74a194f172adc13a46b5	identical
/mnt/app/eso/lib/factories/libdsicarplayproxy.so	73,384	9ccb46c1c185f9be507d74d1e46433cabde2833fc77ac478744ea95629f9be96	identical
/mnt/app/armle/usr/sbin/mm-ipod	40,297	de99a7f4dd941589c6d5173b7601856275c4ea615229058ec84b8e3efa748d27	identical
/mnt/app/armle/usr/lib/libiap2client.so.1	18,613	c33021b21c5656886e64964efcf806fddb4259027c3c1ed396522e7a44adfdea	identical
/mnt/app/eso/bin/apps/smartphone_integrator	806,540	a566f3bebfd76b87ef8ffb83ddcfb3d97201e05a2a0ac5693f6dc1bf827a6623	differs (ref 806,539)
/mnt/app/eso/bin/apps/dio_manager	684,305	ead570d45071bb4dafe4a4667003bb9f82a72f58178f30dc86a08f11ce62a3ae	differs (ref 686,552)
/mnt/system/etc/eso/production/smartphone_integrator.json	7,360	bfcf8cefcf28107e7c6465914b4f94652e81f9ec8a385664cf93a6543bd5b837	same size, differs (ref dd925b8a…) → patch_carplay.sh would refuse (exit 3)
/mnt/system/etc/eso/production/dio_manager.json	13,090	39422da914d2eee9cc11accc8c04decc167f0ab236dfecd83c593a8081426078	differs (ref 13,129)
/mnt/system/etc/boot/startup.sh	33,908	a6d520f1d57e8ae5f9f66ca8bd7d2978fb1a42555f543b3c36975870731c35c0	same size, differs (ref 869a64ef…); contains the exact STOCK_LINE from install_preload.sh (line 679)
/ifs/lsd.jxe	55,840,541	09167f1d0ae5340e992821bf92a56bcc5d45965b1dc24af3e4cc9d096a07507a	differs (VW HMI, expected)
displaymanager.json	5,983	0374c1f236a947a4d728085034e2c96d21f6f0dc4a727bcc379468612bb1ded0	most_encoder.device=/dev/mlb/isoTX2 (H.264/MOST)

Same pattern in other community JARs: NavActiveIgnore.jar CarPlayModeHandling writes property 963062784 = reversed 2910009 (ASLCarPlayICListenerConstants.ROUTE_GUIDANCE_ACTIVE); adi961/mib2-android-auto-vc uses 1109328000 = reversed -2147475646 (CarPlayServiceListener.CAR_PLAY_SERVICE__ROUTE_GUIDANCE_ACTIVATION) and 895953920 = reversed 2910005.

Interpretation: the luka-dev values are decimal-structured ASL IDs (2910009, 2910010, 2110011, 1490005), so the reversed values look like an older JXE→JAR converter byte-order bug carried into recompiled classes. If so, MIBR-Most20FPS.jar registers its DisplayManagement listener on a non-existent service ID and reports a wrong sequence identifier. The vehicle-tested n==1 → 2 data-rate change may still work because it is in the constructor. Not verified on MU1440 stock — please cross-check with your MU1440 lsd.jxe baseline.

Source / provenance

• artifacts/mu1440/most20fps/vehicle-tested-2026-09-29/MIBR-Most20FPS.jar @ c2f811f, decompiled with CFR 0.152.
• VW MHI2_ER_VWG13_K4525 lsd.jxe (09167f1d…) → luka-dev/jxe2jar → CFR 0.152 / javap -constants.

Evidence

Table above; javap -p member lists of both ChangeDataRateSequence versions are identical apart from final modifiers.

Why it matters

A wrong listener/service ID compiles and loads silently. Re-deriving the patch from a luka-dev/jxe2jar baseline (which JAVA_J9_BUILD_NOTES.md already names as the comparison authority) would remove the ambiguity.

• I have not attached proprietary binaries/source that I do not have the right to redistribute.

Context / evidence

No response

Before posting

• I removed credentials, VINs, addresses and other private information.

[arcidodo]

Update: custom video over MOST isoTX2 reaches the 12.3" AID Gen1 (3G1920794C) ✅

Now with SSH (USB-LAN) on this unit, I ran a minimal cluster video test before touching anything CarPlay-related.

Result: the MQB map-video path works on this Passat B8 GTE / 12.3" AID Gen1. Custom EGL output rendered on the MHI2 appears in the AID map area. The 800x480 window fits.

How (nothing installed persistently, reboot = stock):

• Binary: OneB1t/VcMOSTRenderMqb opengl-render-qnx (unmodified repo build, SHA-256 8e9dc1d565d36999…)
• config.txt: windowWidth = 800, windowHeight = 480, backgroundColor = 1.0 0.0 0.0 1.0 (red), default vertices/texcoords
• VNC deliberately unreachable (./opengl-render-qnx 127.0.0.1 5999), so the renderer only draws its (empty, black) textured quad on the red background
• Run from /tmp with IPL_CONFIG_DIR=/etc/eso/production (the renderer does dmdt dc 70 3 / dmdt sc 4 70)

Observed in the AID (photo attached): the map area turns black with red strips left/right and a red line at the bottom. That is exactly the background outside the textured quad (x = ±0.8, bottom y = −0.63). So the frame geometry reaches the cluster 1:1.

Unit notes for anyone reproducing on VW MU1367:

• Stock pf.conf only allows SSH on $wlan_if = uap0 (car hotspot). For USB-LAN I added pass in quick on $dbg_if proto tcp from any to ($dbg_if) port 22 keep state allow-opts under # SSH Access. Telnet on en0 is open by default.
• On this train /tmp does not allow mkdir ("Function not implemented"), and /fs/sda0 needs mount -uw before writing.

Status of the pieces for the Type-111 path on this unit:

• libairplay.so identical to MU1440 (193a4fd9…) → GEN2 hook gate passes
• displaymanager launch line in startup.sh identical to your STOCK_LINE (file differs, same size)
• MOST isoTX2 video into the 12.3" AID works (this test), with a 800x480 window
• Remaining: hash gates (lsd.jxe, smartphone_integrator.json, startup.sh, NavIgnore) and the VW-specific dio_manager

I have SSH plus a full backup and can test a manual / VW-gated GEN2 + direct-ts-remux + isoTX2-gate setup with ALTSCREEN111_WIDTH/HEIGHT for this cluster. Which width/height and settings would you suggest for AID Gen1 (800x480 like OneB1t's old-cluster baseline, or something else)? Is there a preferred way to run the GEN2 path manually without the MU1440 hash gates?

[arcidodo]

Update: displaymanager state on VW MU1367 + 12.3" AID Gen1 (3G1920794C)

Read-only dmdt output from the Passat B8 GTE (MHI2_ER_VWG13_K4525, MU1367), stock unit (nothing modified), CarPlay active on the main screen. Run with IPL_CONFIG_DIR=/etc/eso/production from /eso/bin/apps (without it dmdt aborts on a missing ./config/framework.json).

dmdt gs: 2 displays

display	name / terminal	size	context	displayables
0	display0 / main	1280 x 640	71	16 HMI + 59 EXTERNAL_SMARTPHONE
1	/	0 x 0	70	33 KOMBI_MAP_VIEW

→ The native Kombi map window on VW MU1367 + AID Gen1 is 800 x 480, the same size that fit in my earlier red/black video test. That points to ALTSCREEN111_WIDTH=800, ALTSCREEN111_HEIGHT=480 for this cluster.

dmdt gc (relevant contexts): 32 contexts known. The Kombi-related ones:

• 70: 33 KOMBI_MAP_VIEW (active on display 1)
• 71: 16 HMI + 59 EXTERNAL_SMARTPHONE (CarPlay/AA on display 0)
• -3 (PERSISTENT | REDRAW): 51, 18, 59, 23, 22, 33, 19, 16 (buffered context holding all map-type displayables incl. 33 and 59)

Full gc output available on request.

Notes for anyone reproducing on VW:

• dmdt has no help/-h; the command list (gd, gc, gs, dc, sc, sb, dm, ts) is only in the binary's strings.
• Redirecting dmdt gs to a file on /fs/sda0 produced an empty file. Run it interactively.