Skip to content

Add ToyOS support - #223

Closed
Japabu wants to merge 1 commit into
rust-windowing:masterfrom
ToyOSOrg:add-toyos-support
Closed

Japabu wants to merge 1 commit into
rust-windowing:masterfrom
ToyOSOrg:add-toyos-support

Conversation

@Japabu

@Japabu Japabu commented Jul 28, 2026

Copy link
Copy Markdown

ToyOS is an operating system written from scratch in Rust for x86-64. It has target_os = "toyos" support in a fork of rustc and std. Its display server is a userspace compositor daemon: clients create a window over IPC and draw into a shared-memory framebuffer.

What this adds

ToyOsWindowHandle and ToyOsDisplayHandle, in src/toyos.rs.

It follows the Haiku/Orbital pattern rather than inventing anything:

  • ToyOsWindowHandle holds a NonNull<c_void> pointing at the client-side window object, like OrbitalWindowHandle::window.
  • ToyOsDisplayHandle is empty — there is no global display connection to name, since each window carries its own connection to the compositor. Same situation as Haiku and Orbital, and it is kept Send + Sync for the same forward-compatibility reason.
  • Registered at every site those two platforms are registered at: mod, the re-export, both enums, both from_impl! groups, and the assert_impl_all! checks in tests.
  • Doc examples on each constructor, matching the surrounding modules.
  • A CHANGELOG.md entry under Unreleased.

Nothing outside those files changes, and no existing platform is touched.

Testing

Against upstream master (1b85948):

  • cargo fmt --all -- --check — clean
  • cargo test across the feature powerset (default, --no-default-features, alloc, std, --all-features) with RUSTFLAGS="--deny=warnings" — all green; the three new doctests run and pass
  • cargo doc --no-deps --document-private-items with RUSTDOCFLAGS="--deny=warnings" — clean
  • cargo check --target wasm32-unknown-unknown --all-features — clean

I could not run typos or cargo hack locally; the powerset above was run by hand instead.

The handles are already in use by ToyOS's winit and softbuffer backends, so this is not a speculative variant.

Happy to adjust naming, the doc wording, or the thread-safety rationale to whatever you prefer — and if you would rather not carry handles for out-of-tree platforms at all, just say so and I will close this.

ToyOS (https://github.com/Japabu/toyos) is an operating system written from
scratch in Rust for x86-64, with `target_os = "toyos"` supported by a fork of
rustc and std. Its display server is a userspace compositor daemon; clients
create windows over IPC and draw into a shared-memory framebuffer.

This adds `ToyOsWindowHandle` and `ToyOsDisplayHandle` following the same
pattern as the existing Haiku and Orbital handles: the window handle carries a
`NonNull<c_void>` pointer to the client-side window object, and the display
handle is empty because the compositor is reached through the per-window IPC
connection rather than a shared connection object. Both are registered at every
site those platforms are — module, re-export, both enums, both `from_impl!`
sets, and the `Send`/`Sync` assertions.

The handles are already used by ToyOS's winit and softbuffer backends.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@Japabu
Japabu force-pushed the add-toyos-support branch from 7521e80 to f61ac95 Compare July 28, 2026 07:15
Japabu added a commit to ToyOSOrg/raw-window-handle that referenced this pull request Jul 28, 2026
Adds the doc examples and thread-safety rationale the other platform modules
carry, plus a CHANGELOG entry, so `git log 1b85948..toyos` is exactly
rust-windowing#223.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Japabu added a commit to ToyOSOrg/winit that referenced this pull request Sep 3, 2026
The ToyOS window handle is in no published raw-window-handle
(rust-windowing/raw-window-handle#223 is open), so this patch stays until it
is. What it names moves from `Japabu/raw-window-handle` — the account name this
estate has left — to `ToyOSOrg/raw-window-handle`, and from the `toyos` branch,
which sits on upstream master, to `toyos-0.6.2`, which is the v0.6.2 release
plus the ToyOS handle and nothing else.

The branch is what makes the two agree: this crate resolves
raw-window-handle 0.6, and a patch to a master-based branch was quietly handing
every dependent the unreleased API that goes with it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Japabu added a commit to ToyOSOrg/softbuffer that referenced this pull request Sep 3, 2026
The ToyOS window handle is in no published raw-window-handle
(rust-windowing/raw-window-handle#223 is open), so this patch stays until it
is. What it names moves from `Japabu/raw-window-handle` — the account name this
estate has left — to `ToyOSOrg/raw-window-handle`, and from the `toyos` branch,
which sits on upstream master, to `toyos-0.6.2`, which is the v0.6.2 release
plus the ToyOS handle and nothing else.

The branch is what makes the two agree: this crate resolves
raw-window-handle 0.6, and a patch to a master-based branch was quietly handing
every dependent the unreleased API that goes with it.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@Japabu

Japabu commented Sep 26, 2026

Copy link
Copy Markdown
Author

Gentle ping: this is ready for review. It still merges cleanly on master and CI is green.

It is what lets ToyOS's winit and softbuffer backends name a window handle without patching this crate. If you'd prefer changes to naming or docs, or would rather not carry handles for out-of-tree platforms, just say so.

@kchibisov

Copy link
Copy Markdown
Member

Sorry don't see any interest in this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants