A pad that was never there kept the console UI on, and the picture sat in the corner #359

2026-08-20T18:10:41Z

enricobuehler commented

2026-08-20 18:10:41 +00:00

Two field reports from one Android user, with one shape between them: a decision taken once, at a moment when the answer was still wrong, and never revisited.

The console UI could not be dismissed

"With a controller" asks whether a pad is attached, and the client answered that with isPad — does this device's source class include gamepad or joystick. That is the right question for routing an event and the wrong one for presence: devices publish inputs that claim the source class while being no such thing (OEM game-mode overlays, gaming-phone shoulder triggers), and one of them is enough to pin the console UI on forever, because a pad that was never there can never disconnect.

pads() now filters on looksLikeController: the source claim and hardware behind it — a stick, a HAT, or the A/B face buttons — on a device the platform did not synthesize itself. The claim is cheap; the hardware is not. isPad keeps its looser meaning for the event lane, where it is correct.

This is not a complete defence, and the code says so: an OEM device that declares BTN_GAMEPAD and a pair of axes is indistinguishable from a pad at this layer. The master switch stays the guaranteed way out — and #354, merged a few hours ago, is what put that switch inside the console where the trapped user can reach it. The two are complementary: #354 gives the escape hatch, this makes the mode row actually decide something. The Controllers screen still lists every real device in one column or the other, which is where someone looks when the client's idea of "a pad is attached" disagrees with the room.

The picture sat in the upper-left corner

A regression in the ASurfaceControl backend from #290. The layer composites into the SurfaceView's on-screen rectangle, read once at surfaceCreated — but StreamScreen hides the system bars and switches the window to LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS in a DisposableEffect that runs a frame or two after first layout, and each one grows the video view under a surface that is never recreated. Only surfaceChanged fires, so the layer went on painting at its start-up size, anchored at the origin. It passed on glass because a device whose bars are already hidden when the surface arrives never sees the gap; rotation and multi-window had the same hole.

The size is now live: a packed Arc<AtomicU64> on SessionHandle, seeded by nativeStartVideo, re-reported by the new nativeVideoSurfaceSize from every surfaceChanged, and read by Layer before each present. One atomic load per frame, and rotation and multi-window come along for free.

Verified

:kit:cargoNdkClippy — arm64-v8a + armeabi-v7a, deny warnings, after cargo clean -p punktfunk-client-android --target aarch64-linux-android so the crate was genuinely re-checked and not served from cache.
:kit:testDebugUnitTest and :app:testDebugUnitTest, plus the native crate's own 31 tests.
New PadPresenceTest (4 cases) covers the presence truth table at a pure seam, since an InputDevice cannot be built off-device. It lives in :kit:, which CI runs unfiltered — unlike the :app: allowlist, so it actually gates.
Java_io_unom_punktfunk_kit_NativeBridge_nativeVideoSurfaceSize confirmed exported in the built .so, so the new external fun links at runtime.

Rebased onto current main (which brought the Skia console and #357's pad HID work) and re-run green there, not just where it was written.

Neither fix has been on glass — no device here. The corner fix is the one worth a live look, and it is cheap: start a stream and watch the picture fill the panel from the first frame.

Two field reports from one Android user, with one shape between them: a decision taken once, at a moment when the answer was still wrong, and never revisited. ## The console UI could not be dismissed "With a controller" asks whether a pad is attached, and the client answered that with `isPad` — does this device's source class include gamepad or joystick. That is the right question for **routing** an event and the wrong one for presence: devices publish inputs that claim the source class while being no such thing (OEM game-mode overlays, gaming-phone shoulder triggers), and one of them is enough to pin the console UI on forever, because a pad that was never there can never disconnect. `pads()` now filters on `looksLikeController`: the source claim **and** hardware behind it — a stick, a HAT, or the A/B face buttons — on a device the platform did not synthesize itself. The claim is cheap; the hardware is not. `isPad` keeps its looser meaning for the event lane, where it is correct. This is **not** a complete defence, and the code says so: an OEM device that declares `BTN_GAMEPAD` and a pair of axes is indistinguishable from a pad at this layer. The master switch stays the guaranteed way out — and #354, merged a few hours ago, is what put that switch inside the console where the trapped user can reach it. The two are complementary: #354 gives the escape hatch, this makes the mode row actually decide something. The Controllers screen still lists every real device in one column or the other, which is where someone looks when the client's idea of "a pad is attached" disagrees with the room. ## The picture sat in the upper-left corner A regression in the ASurfaceControl backend from #290. The layer composites into the SurfaceView's on-screen rectangle, read **once** at `surfaceCreated` — but `StreamScreen` hides the system bars and switches the window to `LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS` in a `DisposableEffect` that runs a frame or two after first layout, and each one grows the video view under a surface that is never recreated. Only `surfaceChanged` fires, so the layer went on painting at its start-up size, anchored at the origin. It passed on glass because a device whose bars are already hidden when the surface arrives never sees the gap; rotation and multi-window had the same hole. The size is now live: a packed `Arc<AtomicU64>` on `SessionHandle`, seeded by `nativeStartVideo`, re-reported by the new `nativeVideoSurfaceSize` from every `surfaceChanged`, and read by `Layer` before each present. One atomic load per frame, and rotation and multi-window come along for free. ## Verified - `:kit:cargoNdkClippy` — arm64-v8a + armeabi-v7a, deny warnings, after `cargo clean -p punktfunk-client-android --target aarch64-linux-android` so the crate was genuinely re-checked and not served from cache. - `:kit:testDebugUnitTest` and `:app:testDebugUnitTest`, plus the native crate's own 31 tests. - New `PadPresenceTest` (4 cases) covers the presence truth table at a pure seam, since an `InputDevice` cannot be built off-device. It lives in `:kit:`, which CI runs unfiltered — unlike the `:app:` allowlist, so it actually gates. - `Java_io_unom_punktfunk_kit_NativeBridge_nativeVideoSurfaceSize` confirmed exported in the built `.so`, so the new `external fun` links at runtime. Rebased onto current main (which brought the Skia console and #357's pad HID work) and re-run green there, not just where it was written. **Neither fix has been on glass** — no device here. The corner fix is the one worth a live look, and it is cheap: start a stream and watch the picture fill the panel from the first frame.

enricobuehler added 1 commit 2026-08-20 18:10:42 +00:00

fix(clients/android): a pad that was never there, and a picture in the corner

ci / rust-arm64 (pull_request) Successful in 3m37s

Details

ci / web (pull_request) Successful in 1m55s

Details

android / android (pull_request) Successful in 8m52s

Details

ci / bun-nix (pull_request) Successful in 19s

Details

ci / docs-site (pull_request) Successful in 2m25s

Details

ci / docs-drift (pull_request) Successful in 23s

Details

ci / rust (pull_request) Successful in 11m0s

Details

0519b057d5

Two field reports from one Android user, with one shape between them: a
decision taken once, at a moment when the answer was still wrong, and never
revisited.

The console UI could not be dismissed. "With a controller" asks whether a pad
is attached, and the client answered that with `isPad` — does this device's
source class include gamepad or joystick. That is the right question for
ROUTING an event and the wrong one for presence: devices publish inputs that
claim the source class while being no such thing (OEM game-mode overlays, the
gaming-phone shoulder triggers), and one of them is enough to pin the console
UI on forever, because a pad that was never there can never disconnect.

`pads()` now filters on `looksLikeController`: the source claim AND hardware
behind it — a stick, a HAT, or the A/B face buttons — on a device the platform
did not synthesize itself. The claim is cheap; the hardware is not. `isPad`
keeps its looser meaning for the event lane, where it is correct. It is not a
complete defence (an OEM device that declares BTN_GAMEPAD and two axes is
indistinguishable from a pad at this layer), so the master switch stays the
guaranteed way out — and the Controllers screen still lists everything real in
one column or the other, which is where someone looks when the client's idea of
"a pad is attached" disagrees with the room.

The picture sat in the top-left corner. The ASurfaceControl layer composites
into the SurfaceView's on-screen rectangle, read once at `surfaceCreated` — but
the stream screen hides the system bars and switches the window to draw into
the display cutout a frame or two later, and each of those grows the view under
a surface that is never recreated. The layer went on painting at the size it
started with, anchored at the origin. It passed on glass because a device whose
bars were already hidden when the surface arrived never sees the gap.

The size is now live: a packed atomic on the session handle, seeded by
`nativeStartVideo`, re-reported by `nativeVideoSurfaceSize` from every
`surfaceChanged`, and read by the layer before each present. One atomic load per
frame, and rotation and multi-window come along for free.

Verified: `:kit:cargoNdkClippy` (arm64 + armv7, deny warnings), `:kit:` and
`:app:` unit tests, and the native crate's own suite. The new JNI symbol is
exported in the built `.so`.

enricobuehler merged commit 685c4bd99a into main

2026-08-20 18:22:38 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#359