Repository navigation
Conversation
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
force-pushed
the
add-toyos-support
branch
from
July 28, 2026 07:15
7521e80 to
f61ac95
Compare
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>
Author
|
Gentle ping: this is ready for review. It still merges cleanly on 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. |
Member
|
Sorry don't see any interest in this. |
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
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.
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
ToyOsWindowHandleandToyOsDisplayHandle, insrc/toyos.rs.It follows the Haiku/Orbital pattern rather than inventing anything:
ToyOsWindowHandleholds aNonNull<c_void>pointing at the client-side window object, likeOrbitalWindowHandle::window.ToyOsDisplayHandleis 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 keptSend + Syncfor the same forward-compatibility reason.mod, the re-export, both enums, bothfrom_impl!groups, and theassert_impl_all!checks intests.CHANGELOG.mdentry under Unreleased.Nothing outside those files changes, and no existing platform is touched.
Testing
Against upstream
master(1b85948):cargo fmt --all -- --check— cleancargo testacross the feature powerset (default,--no-default-features,alloc,std,--all-features) withRUSTFLAGS="--deny=warnings"— all green; the three new doctests run and passcargo doc --no-deps --document-private-itemswithRUSTDOCFLAGS="--deny=warnings"— cleancargo check --target wasm32-unknown-unknown --all-features— cleanI could not run
typosorcargo hacklocally; 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.