Project Ceylon Development Log — October 1, 2026: The Mouse Moved, Asteroids Is Real, and the Hardware Stopped Sitting Still
Today was one of those days where several things that had been "almost there" finally became a lot more concrete.
The short version:
the real keyboard and pointer path passed, the Asteroids demo turned out to be a real application core instead of a future placeholder, and Clarise proved the same Ceylon image can cope with different PCI resource layouts without rebuilding the operating system around them.
That is a fairly satisfying day.
Especially because all three of those things point at the same larger goal:
Ceylon needs to stop behaving like a carefully staged demonstration and start behaving like a computer.
The mouse problem was not a mouse problem
The first win was NuGUI input.
Keyboard input has been working for a while, and the pointer path has been under qualification for several development tranches.
Today the remaining QEMU tablet issue finally got pinned down.
The parser was rejecting the virtual tablet because it reported itself as:
class 3, subclass 0, protocol 0
That was enough to send the existing HID logic down the wrong path.
Nothing particularly dramatic was wrong with the mouse.
The machine was simply looking at a perfectly valid HID device and deciding:
"Nope. I don't know what that is."
Which, in retrospect, is a wonderfully accurate description of quite a bit of operating-system development.
The parser was corrected.
Then we went back through the actual path instead of declaring victory because one pointer event appeared.
The input path is now real
The path being qualified is the one I actually care about:
QEMU virtual USB device → xHCI controller → Ceylon HID provider → semantic input service → bounded transport → NuGUI
No shortcut that writes fake mouse movement directly into the GUI.
No host-side test pretending to be the target.
No "we proved the parser works, therefore the desktop works."
The complete keyboard and pointer transport passed.
Then it stayed up under an 11-minute soak.
The broader workspace test run completed:
480 tests, 0 failures.
And the existing Nu-Iris R2 through R8 regression sets stayed green.
That last part matters because input work should not quietly damage the display path while everybody is celebrating that the mouse moved.
So this is a genuine milestone.
Not "pointer code exists."
Not "a cursor twitched."
The underlying interactive path is now behaving like something we can build on.
Next comes focus, which sounds easier than it is
The next NuGUI step is focus routing and static application activation.
That sounds almost trivial.
Click a window.
That window gets input.
Launch an application.
It becomes active.
Done.
Except operating systems have a way of turning every sentence containing the word "just" into a week of work.
Focus has to answer questions like:
Which application owns keyboard input right now?
What happens when a window disappears?
What happens when an application crashes?
Can stale input reach a replacement instance?
What happens when pointer focus and keyboard focus differ?
What does activation mean if the application has restarted?
Those are not glamorous questions.
But they are the difference between a desktop that usually works and one that occasionally types your command into the wrong application.
The important part is that we have reached that layer now.
We are no longer debugging whether QEMU can produce a pointer packet.
We are deciding what the operating system should do with it.
That is progress.
Then I went looking for Asteroids
A1 Alpha is supposed to include a simple Asteroids-style demo as a lightweight native proof-of-life application.
The idea is deliberately modest.
Juggernaut is the heavier game workload.
Asteroids is supposed to answer a much simpler question:
Can Ceylon run a small, responsive native arcade application cleanly?
Input.
Timing.
Rendering.
Collisions.
Score.
Sound.
Nothing fancy.
Today I went looking for the actual state of that work.
And found something better than I expected.
There is already a packaged source drop:
CeylonAsteroids-0.1.0-drawer-package.zip
And it is not just a README and a future plan.
There is a real game core.
A CPU renderer.
Tests.
A host development demo.
And integration documentation explaining how the application is supposed to connect to Ceylon.
That was a pleasant surprise.
Asteroids exists. It just does not live in Ceylon yet.
The distinction is important.
The game itself is substantially there.
The missing part is the Ceylon target adapter.
That means we still need to connect the portable game core to the operating-system services around it.
Specifically, it still needs:
- a Ceylon target binary / protection domain;
- a NuGUI window;
- an application activation endpoint;
- semantic input mapped into the game's InputState;
- the Ceylon timer path driving Game::step();
- a pixel buffer connected to the game's renderer.
In other words, the game logic is not the blocker.
The operating-system integration is.
That is actually exactly where I hoped we would be at this stage.
I want application developers to be able to build most of their logic without having to run the entire operating system every time they change one line.
Then the Ceylon adapter should connect that logic to the native platform.
Asteroids is turning into a nice test of whether that application model is actually practical.
This may become the first really obvious desktop proof
There is something appealing about using Asteroids as the first simple application activation target.
A text editor can prove a lot.
A settings window can prove a lot.
A terminal can prove a lot.
But an arcade game makes failures obvious.
If input is delayed, you know.
If timing is wrong, you know.
If rendering tears or stalls, you know.
If focus gets confused, your spaceship starts doing something stupid immediately.
And, perhaps most importantly for a project page, it is a lot easier to show somebody a moving ship and flying rocks than it is to show them a correctly bounded IPC queue.
Both matter.
Only one of them makes a decent GIF.
Clarise also had a good day
The other major result today came from Clarise, Ceylon's Plug-and-Play/device-management work.
One of the problems we have been steadily trying to eliminate is the idea that Ceylon should only work when PCI devices appear at the exact addresses we happened to see during one QEMU run.
That is not Plug-and-Play.
That is a very elaborate static configuration file.
Clarise Stage 2 pushed against that assumption.
The current model uses runtime PCI discovery and generation-qualified device bindings rather than treating one set of BAR addresses as universal truth.
Today the same Ceylon system image was exercised against two different BAR layouts.
It passed both.
No rebuilding the image around the new addresses.
No editing one magic constant until the device appeared.
The device resources were discovered and bound dynamically.
That is exactly what I want.
Same image, different machine layout
This may be one of those milestones that sounds less important than it is.
Virtual hardware moves around.
Physical hardware definitely moves around.
Firmware changes resource allocation.
A different device topology can shift PCI BARs.
Add an audio device and suddenly something else may land somewhere different.
We have already been bitten by this more than once.
So the test today was intentionally simple:
Can the same Ceylon image deal with two legitimate resource layouts?
Yes.
The current bounded aperture covered the expected range, and the runtime binding model correctly handled the devices in both configurations.
The qualification also included a little over 20 minutes of soak time.
That does not mean Plug-and-Play is finished.
It means another hard-coded assumption is disappearing.
And every one of those we remove makes the future bare-metal work a little less terrifying.
The three stories are actually the same story
At first glance, today looks like three unrelated development threads.
Input.
Asteroids.
PCI discovery.
But they all point in the same direction.
The first version of Ceylon was necessarily full of fixed assumptions.
One display.
One known machine.
One expected resource layout.
One manually controlled application path.
That is normal when you are trying to prove anything works at all.
But a real operating system cannot stay there.
A pointer device has to be discovered and interpreted rather than faked.
An application has to be activated and connected to services rather than hand-wired into a demo.
Hardware has to be bound based on what actually exists rather than where it existed last Tuesday.
That is the transition we are making now.
From:
"Can I make this path work?"
to:
"Can the operating system make this path work without me standing next to it?"
That second question is much closer to a product.
What is next
For NuGUI, the immediate work is focus routing and static application activation.
For Asteroids, that means building the actual Ceylon adapter and making it one of the first applications launched through the real desktop path.
For Clarise, the dynamic binding work continues toward broader Plug-and-Play authority and lifecycle handling.
And importantly, none of today's work required changing Nu-Iris.
The display regressions stayed green while the input path moved forward.
I am increasingly fond of days where one subsystem improves without requiring emergency surgery on three others.
That feels suspiciously like maturity.
I don't want to get carried away.
Where we ended the night
The keyboard works through the real path.
The pointer works through the real path.
The input stack survived its soak and regression suite.
The Asteroids demo is no longer an idea on the Alpha checklist; there is a real portable game core waiting for its Ceylon adapter.
And the device-management work proved that one system image can survive more than one PCI BAR layout without being rebuilt around the hardware.
None of those things, individually, is the dramatic "Ceylon is alive" screenshot I am chasing.
Together, though, they are exactly how we get there.
A machine that can discover its hardware.
Accept real input.
Activate a native application.
Give that application a window.
Feed it time and controls.
And let the user shoot rocks until something breaks.
Honestly, that sounds like a pretty good next milestone.
Project Ceylon is an independent retro-futurist operating-system project exploring what a modern creative workstation might look like if some of the best ideas of earlier personal computers had continued evolving instead of being discarded.
Project site: ceylonprojectng.com