Runtime for viewports defined with use Emerge.

Application mount arguments remain keyword lists. The configuration returned by mount/1 is an Emerge.Config struct, not renderer keywords:

def mount(opts) do
  output = %Emerge.Config.Window{title: Keyword.get(opts, :title, "My App")}
  {:ok, %Emerge.Config{output: output, input: [events: [:key]]}}
end

Implement neither or exactly one of config/1 and config/2. They receive the previous normalized desired config; config/2 also receives application state. The first call receives mount config, before renderer creation. Later calls run during coalesced rerenders, even if the tree has not changed. Callback/validation failures retain the previous valid config. Operational renderer failures retain the new desired config for the next callback and recovery; the complete live snapshot is retried on the next rerender. Accepted config is not proof of hardware application or presentation completion.

def config(%Emerge.Config{output: %Emerge.Config.Window{} = output} = previous, state) do
  output = %Emerge.Config.Window{output | title: state.title}
  %Emerge.Config{previous | output: output}
end

Nested keyword shorthand expands from record defaults, not previous values. Use typed struct updates to preserve untouched fields. See Emerge.Config for groups, output variants, defaults and current implementation limits.

Raw input observation is opt-in through Emerge.Config.Input.events. Emerge.Input documents every callback payload. This filter does not disable element interactions or window-close notifications.

Adapter selection and liveness policy live in Emerge.Config.Runtime. Native ownership is managed internally, not configured by applications. See the viewport configuration documentation, input guide and 0.5 migration guide.

Initially-off DRM viewports still acquire and bind output ownership without rendering/uploading. Off preserves application messages, config reconciliation, latest tree/intent and ownership, while suspending native UI input and destroying the presenter. On recreates resources; no GPU state is restored. Power/brightness controls require explicit OpenGL, Vulkan or raster (CPU or GPU-upload presentation). GPU upload requires an OpenGL-enabled DRM build; automatic API power controls remain unsupported. Invalid live/startup controls report errors. Software support does not qualify physical panel behavior.