28 lines
2.2 KiB
Markdown
28 lines
2.2 KiB
Markdown
## ADDED Requirements
|
|
|
|
### Requirement: P3D-033 requested and effective display mode
|
|
The client SHALL offer global and desktop/pool overrides for Automatic, detected/common preset, Custom, and Full Native width/height/FPS. A display-aware request SHALL be feature-gated; the Server SHALL validate, include it in idempotency identity, resolve immutable policy, proportionally clamp to even dimensions and maximum FPS, persist requested/effective values atomically, and disclose both without provider details.
|
|
|
|
#### Scenario: Oversized custom request
|
|
- **WHEN** a requested mode exceeds either policy dimension or FPS
|
|
- **THEN** the Server applies one proportional scale, floors both dimensions to even pixels, caps FPS, persists the result, and returns the requested and accepted modes
|
|
|
|
#### Scenario: Legacy request
|
|
- **WHEN** a client omits the feature and requested display object
|
|
- **THEN** the Server preserves the legacy response shape and provider work uses the existing exact policy mode
|
|
|
|
#### Scenario: Same idempotency key with different mode
|
|
- **WHEN** two requests reuse an idempotency key but contain different requested display modes
|
|
- **THEN** the Server rejects the mismatch rather than returning or mutating the earlier session
|
|
|
|
### Requirement: P3D-034 native detection and reconnect semantics
|
|
Automatic mode SHALL derive physical pixels and maximum FPS from the screen where the session window opens, prefer a defensible notch-safe built-in mode, otherwise disclose Full Native, and SHALL NOT mutate an active mode after a display move. Reconnect to match the new display SHALL end the prior session and use a new request/idempotency key. Owner E2E SHALL prove accepted values on Apollo/SudoMaker IDD through the gateway-only route.
|
|
|
|
#### Scenario: Move active session to another display
|
|
- **WHEN** an Automatic session window moves to a display with different native capability
|
|
- **THEN** the active mode remains unchanged and the user may explicitly reconnect with a newly detected request
|
|
|
|
#### Scenario: Exact owner virtual-display acceptance
|
|
- **WHEN** the owner runs the frozen client, Server, gateway, and Apollo candidate
|
|
- **THEN** retained evidence binds requested and accepted width/height/FPS to the actual SudoMaker virtual display without a direct client-provider route
|