Non-VC MHI2Q (Q7 4M, analog cluster with KVS_Most map band) — build inputs, platform data, and two source findings

[charles-low]

Non-VC MHI2Q (Q7 4M, analog cluster with KVS_Most map band) — build inputs, platform data, and two source findings

Unit: MHI2Q_US_AUG22_P5087, MU 1316, variant FMQ-P-TNSL-US-AU-MLE, diagnosis variant G2_PREMIUM_MMX_NAV_Phone_LTE_SI_NAR_AU. Car: 2019 Q7 4M, NO Virtual Cockpit. The analog cluster has the 7" centre display and shows the HU's native map in it (photo available on request), so it is a MOST video sink — I believe this is the KVS_Most 800x252 / DSI 1 style your komo-widget-video notes mention, not a plain FIS.

I have read the source and would like to run this on the car. Three questions, and two things I found that may be useful to you.

QUESTIONS

1. Build inputs — resolved

build/ ships empty and scripts/build_java.sh compiles against ../../Tools/jxe2jar/out/MU1316-combined-final.jar plus two OSGi jars, none of which are in or referenced by the repo. How is the stock jar produced from lsd.jxe? Which OSGi jars/versions? I am on MU1316 US, so I can build against my own image if I know the tooling.

Resolved via luka-dev/jxe2jar, which documents the lsd.jxe conversion/combine/uninline pipeline and includes the required OSGi dependencies and matching MHI2Q_US_AUG22_P5087_MU1316 JCL.

2. Cluster platform

Have you seen a kombiType / sysConst(541) fingerprint from any non-FPK cluster? I will post mine from the DisplayManager WARN line once the jar is on the car. Also: on an analog KVS_Most cluster, do you expect the stock map context on terminal 1 to still be 72/74 and the native map to be displayable 33, or are those FPK-specific?

3. Touchpad

In CarplayDSILifecycleController.startService() the stock DSI builds inputFeatures as a bitmask (1 knob, 2 touchscreen-low, 4 touchscreen-high, 8 touchpad) with touchpadX/YResolution, and getDSITouchInputId() maps stock type 2 → DSI id 1 and everything else → 0. Did you ever try declaring bit 8 and posting the pad on input id 0 instead of the DPAD bridge? If you tried and it failed, what did iOS do?

FINDINGS

A. BAP route-guidance path is gated by the cluster-video platform check

RgdModule.start() returns early when !ScreenModule.isPlatformSupported(fw), and BAPBridge.isPresentationReady() requires a renderer frame. That gates the BAP route-guidance publisher (HUD + cluster readout, display-independent) on the cluster-VIDEO platform check. On G24, and on any cluster that is not the tested FPK, CarPlay guidance is switched off entirely although the BAP path would work. ClusterService's distance-valid-alongside-bargraph fix keys off isConnected() and so also reverts on those clusters. I have a local branch that splits isConnected() (may write cluster contexts) from a new isSessionActive() (CarPlay is the guidance source), keeps isConnected() false where there is no switch worker so DisplayManagerMIB2High.switchContext() does not block stock writes, and makes startCustomRenderer() / forceGfxAvailable() no-ops on unsupported platforms. Happy to open a PR keyed on !isPlatformSupported() if you want it.

B. USB recovery target is hard-coded

carplay_processes.sh hard-codes the USB recovery target (PPS path usb-1.0.1, "reset port 3"). On a different USB topology it either never fires or resets the wrong port.

I will report back with the fingerprint line, komoviewstyle.conf DSI mapping, and whether an analog cluster consumes the FctIDs. Thanks for the RE notes — they are what made reading this possible.

[charles-low]

Update: I found your jxe2jar repository after opening this issue. It appears to answer question 1: it documents converting lsd.jxe, combining the firmware bundles/app jars, and producing MU1316-combined-final.jar; it also includes the exact OSGi 1.10.0/1.5.4 dependencies and an MHI2Q_US_AUG22_P5087_MU1316 JCL. Please consider question 1 resolved unless the RGI build uses any additional private inputs or unpublished steps.

[luka-dev]

Hi, sorry for the slow reply!

Good job resolving the build inputs with jxe2jar

Cluster platform. To be honest, I have never looked at the non-FPK variants. I don't know how the DisplayManager works with that cluster. I even suspect it gets its stream the VW way, directly as MPEG-TS. A dmdt gs / dmdt gc / dmdt gd dump from your unit would help a lot.

Touchpad. Stock MHI2Q already declares it EvoTMConfiguration.hasTouchpad() returns true, so the DSI inputFeatures is 9 (knob + touchpad). Stock posts pad events on input id 0 (the touchscreen is on 1), and dio_manager registers a real HID trackpad (HIDSingleTrackPadCreateDescriptor: Digitizer/TouchPad, absolute X/Y, one finger). On the car, though, the pad only ever highlighted the focused item and focus never moved. Thats why we route it through our own speed-adaptive DPAD bridge. That bridge is an early implementation, though. I'm now looking into fixing how the display advertises its input, so that CarPlay takes proper trackpad input natively. I will try it soon.

The platform gate. I have no way to test on a non-FPK car, so I don't know the best and safest place to move the gate, and I'm not planning to touch it right now. If you're willing to work it out on your side, a PR with what works for you is very welcome!!

USB target. Thanks for pointing that out, its only reason i spotted it and fixed in the latest updates.