Repository navigation
Bump RemoteOS-SDL for host-chosen desktop size - #2
Merged
Merged
Conversation
jordanhubbard
force-pushed
the
remoteos-sdl-display-size
branch
from
September 21, 2026 23:58
b8cf8d0 to
5d2c294
Compare
Picks up jordanhubbard/RemoteOS-SDL#1, released as v0.3.0, which lets the host override the size a guest asks for via REMOTEOS_SDL_SIZE and makes display.open's reply always describe the framebuffer that was actually created. No PythonOS change is needed to benefit: _open_bridge_window already adopts the reported size into _bridge_w/_bridge_h rather than assuming it got what it requested, and those feed layout throughout the compositor. The override is skipped in headless mode, so captures and visual goldens keep the dimensions their callers chose. Also fixes a latent bug on the window-surface fallback, which PythonOS takes whenever renderer creation fails: SDL_GetWindowSurface returns a surface at the drawable size, so on a high-density display the guest was told a size smaller than the buffer it had been handed and would have painted into one corner of it. Pins the release tag rather than the commit that preceded it, so the service shipped here is exactly the one 0.3.0 published. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jordanhubbard
force-pushed
the
remoteos-sdl-display-size
branch
from
September 22, 2026 04:48
5d2c294 to
6b3003a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Picks up jordanhubbard/RemoteOS-SDL#1. Submodule pointer only — no PythonOS source changes.
What the bump brings
REMOTEOS_SDL_SIZE=WxHoverrides the size a guest requests. A bare-metal guest has no environment and no way to ask what the host's display can do, so it asks for a fixed size and is stuck with it. Nothing in PythonOS has to change to benefit:_open_bridge_windowalready adopts the reported size into_bridge_w/_bridge_hrather than assuming it got what it asked for.display.opennow always reports the framebuffer that was actually created. This fixes a latent bug on the window-surface fallback — the path PythonOS takes wheneverSDL_CreateRendererfails.SDL_GetWindowSurfacereturns a surface at the drawable size, so on a high-density display the guest was told a size smaller than the buffer it had been handed, and would paint into one corner of it.SDL_WINDOW_ALLOW_HIGHDPI+SDL_RenderSetLogicalSize, so the window takes the display's full pixel density while the guest keeps drawing in the coordinates it asked for.The size override is skipped in headless mode, so
test-guicaptures and visual goldens keep the dimensions their callers chose.Testing
The service's own suite passes against this commit, including the headless window-surface path this repo exercises:
Not run here: PythonOS's own
test-gui, which needs a full guest build. The guest source is untouched and headless behaviour is unchanged, but a maintainer may want to confirm before merging.The high-density path is also untested — the development display is 3840×1080 at a 1:1 backing scale, where
ALLOW_HIGHDPIis a measured no-op.🤖 Generated with Claude Code