Shared Cockpit and Home Cockpit, Potential Bandaid Fix.

[Jacob Van Wie]

iniBuilds, and fellow A350 pilots,

I want to start by saying the iniBuilds A350 my favorite aircraft to take on long haul flights. And I am in the process of designing a "Airbus" home cockpit, of which, I want all Airbus types (except A300 & 310) to be compatible with.

I know in the iniBuilds A320, the HTML based OIS/EFB pops out and retains full interactivity, which is fantastic. However, for most of your target audience for the A350, the FMCs are the heart of your product, and not being able to control them on their dedicated monitors should be classified as a issue.

I do understand why this is the case. WASM gauges render differently than the HTML-based OIS. I recognize that asking to make these complex WASM-based bitmap displays fully mouse and touch-interactive in a pop-out window (like a Fenix-style web server) is likely a monumental, if not futile, development effort.

So, I’d like to propose a different, and hopefully much simpler, solution that completely bypasses the need for direct mouse interactivity.

Could the team expose a small set of new LVARS or events specifically for controlling the MFD's cursor/pointer? (This would actually be more realistic as the actual plane uses a ball mouse)

If we had access to these, the home cockpit community could build the "bridge" ourselves using external software. We don't necessarily need direct mouse-click injection; we just need a way to remotely tell the MFD what to do. (I already know variables not unlike exist in the WASM code: (ND::SetMouseCoords; SD::SetMouseCoords; FMSpage::MouseClicked; FMSpage::MouseScroll; FMSpage::MouseDrag))

Here are a few options for how this could be implemented:

Absolute Position Variables (Ideal): Expose two variables that accept a coordinate (e.g., INI_A350_MFD1_CAPT_CURSOR_X and INI_A350_MFD1_CAPT_CURSOR_Y). An external program could then read and update mouse position based on a controller or other HID and feed those coordinates to the Sim. (Another variable could be added to where when it's value is true, it takes position only from this LVAR, as building a function call whenever a variable changes externally could be unstable)

Relative "Nudge" Events (Simpler?): If absolute positioning is too complex, perhaps four simple events could be exposed: INI_A350_MFD1_CAPT_CURSOR_UP, ..._DOWN, ..._LEFT, ..._RIGHT. 

The "Click" Event: A single, crucial event: INI_A350_MFD1_CAPT_CLICK

Why This Is a "Game-Changer" for Everyone

Home Cockpit Builders: This would be the "holy grail." We could use simple scripts to map a dedicated ball mouse to these variables, creating a 100% functional external display.

Third-Party Hardware: This would open the door for hardware manufacturers to create physical MFD/FMC units that can interface directly with the A350, just by writing to these variables.

Shared Cockpit: This is the most exciting part for me. This exact functionality is the key missing piece for shared cockpit utilities like YourControls. By exposing these variables (absolute positions), it might finally be possible for a co-pilot's inputs to be synchronized. This would unlock the A350 for true, multi crew operations, which is the very essence of long hail flying.

I'm not asking for a total re-architecture of the pop-out system ASAP. But just a few "hooks" can band aid this apparent gap in functionality. Think of how many people already have a second display and second HID they could bind to the FMC. Entire markets of products, communities, and add-ons are built around it.