Multi-display cabins must tell who is using which screen

What it is

When cluster, center stack, passenger display, and rear displays are all on, the system has to know who is using which screen. Occupant identity is not a decorative account. It is routing for input and output: this touch, this utterance, this notification belongs to that person. A stack tapped by two hands in turn, while the passenger display mirrors the driver’s unfinished navigation, is a cabin that has not split people. The problem is identity across screens. It is not whether a speed lock collaterally hits a passenger—that is lockout logic.

Why it happens

Each display’s place in the cabin suggests a default owner: the cluster is almost only the driver’s, a passenger display defaults to the front passenger, rear displays default to the rear. The center stack sits in the middle, so its default owner is the vaguest and extra signals matter most: which side the touch entered from, who in which seat is looking, which microphone beam the voice came from. A wrong bind writes input into someone else’s task and paints output into someone else’s field of view. People also move: a passenger unbuckles to fetch something from the rear. Binds must break and rebind; a single calibration cannot last the trip. A cabin with no identity can only keep one vehicle-wide state, so everyone edits the same route and fights over the same media.

Studying it

In a multi-occupant cabin, give the driver, the front passenger, and a rear passenger each a task, and watch where input and notifications land. Report a confusion matrix of action source × assigned user. Contrast a stack-only cabin with independent passenger and rear displays.

Independent variables: number and placement of displays, lateral touch zoning, occupancy and gaze estimates, whether speech is beam-formed by seat. Dependent variables: inputs written into the wrong task, notifications on the wrong display, extra actions used to repair routing.

Lab occupants stay in assigned seats. On the road, children climb, people swap, a hand crosses the stack, and identity noise is higher. Measuring “can the passenger display light up” is not measuring “it lit for the right person.”

Where it stops holding

On a solo trip with only cluster and stack, identity collapses to the driver and the need to distinguish drops—but that default does not copy into a full cabin. In a ride-hail, the rear passengers are the clients; the driver should not be the account for rear media. A rear display that cannot be seen or reached from the front can be hard-coded to that seat; the center stack cannot. Camera schemes raise in-cabin privacy; occupants who refuse a camera need a split that does not use a face (seat, zoned touch).

Applying it

• Give each display a default owner. Switch the stack by touch direction or an explicit “who is using this,” and do not let every screen write the same unfinished input.
• Pick up voice by seat. A driver’s utterance should not become a rear search for a title; a rear utterance should not become the driver’s route.
• Verify with three people at once (driver on cruise, passenger typing a place, rear choosing a title). Any step written into someone else’s task, or a notification painted on someone else’s display, means users were not split.

Related

• Within the group: K6.07.2 Front-passenger actions should not inherit driving lockouts · K6.07.3 Rear-seat interaction must not leak into the driver’s task
• Adjacent: K6.06 Function Lockout While Driving · K6.11 Division of Labor among Cluster, Center Stack, and Secondary Displays
• Search terms: occupant-aware · multi-display cabin · input routing