I wanted to play Sega Rally on the television in the living room, the arcade version. The first Sega Rally runs on Sega's Model 2 board, and that came first: MAME emulates it, RetroArch carries MAME, and OmaCRT already drives RetroArch. Its sequel, Sega Rally 2, runs on the Model 3 that followed in 1996, with a graphics board Sega built with Lockheed Martin's Real3D. MAME lists its Model 3 driver as preliminary, which in MAME's words means not playable. Supermodel is playable, and has been for years, but it is a program of its own, and nothing in OmaCRT had ever started one that was not RetroArch or mpv.

It does now, and the Model 3 games look sharper on the glass than the Model 2 games beside them.

01A board drawn for another monitor

Model 3 games draw 496 by 384 at 57.524 frames a second, for a medium resolution arcade monitor whose lines run at 24 kHz. A 15 kHz television draws 240 lines in a frame and cannot be talked into more without interlace, which the stock kernel cannot scan out. So 384 lines have to become 240 somewhere.

On Model 2 that happens after the drawing. MAME renders the board's 384 lines, and RetroArch fits them into the tube's 240. Fitting with nearest neighbour keeps five lines in every eight and throws the other three away, unevenly, and the rows of a timer's digits come and go. The launcher has filtered that reduction since 0.11.2, which brings the rows back as a softer picture.

Supermodel works the other way round: its renderer draws the 3D scene at whatever size it is asked for. The launcher hands it the whole frame the television is set to, 3520 by 240, and the polygons are drawn at 240 lines from the start: every line the set draws is a line the renderer drew, with nothing thrown away and nothing averaged. Only the 2D layers, the text and the gauges, are still scaled, with Supermodel's own filter. The tube runs at the board's own 57.524 Hz rather than 60.

Drawn at 240 lines, not reduced to them.

One frame of Sega Rally 2, three ways. The board draws 384 lines and the tube has 240: either the 384 are reduced, as Model 2 games are, or the renderer is asked for 240 in the first place.

Reduced, nearestReduced, filteredDrawn at 240

Supermodel asked for 240 lines and drew 240 lines: every line on the glass is a line the renderer drew. Only the text and gauges are still scaled. This is Model 3 on the tube.

The frame, at the 4:3 the set shows it at

The marked part, enlarged

The board lines each tube line is made of

The 3520 counts how finely the television's mode slices each line in time. It is the arcade world's "super resolution", width to spare, so that a console's 320 pixels land on exactly eleven of it each. The set shows it as 4:3, the way the cabinet's monitor did.

02One check between Supermodel and the tube

OmaCRT does not give the television to the desktop. It takes the connector for itself, and the programs on the tube are clients of flyback, a compositor for that one output that speaks Wayland and nothing else. There is no X server on the television.

The Supermodel package in the Arch User Repository starts and stops with "OpenGL initialization failed". Supermodel carries its own copy of GLEW, the library that looks up OpenGL's functions, and glewInit() does two things: it loads the functions, then it asks the X server for its GLX extensions. Under Wayland there is no X server to ask, so the call returns GLEW_ERROR_NO_GLX_DISPLAY with every function Supermodel uses already loaded, and Supermodel treats any answer but success as fatal.

The change lets that one answer through:

if (GLEW_OK != err && GLEW_ERROR_NO_GLX_DISPLAY != err)

It lives in packaging/supermodel-omacrt, which builds the same upstream release as the AUR package with that line changed and replaces it. The launcher then starts the binary directly, tells it where its list of games is, and gives it the television's frame, its rate and a name the compositor can raise it by.

03A cabinet waiting for its twin

Sega Rally 2 started. Scud Race did not.

Scud Race and Daytona USA 2 were built to run linked: two cabinets side by side, joined by a network board so two people could race each other. Out of the box each board is the master of a pair. With no network board it gives up at once. With Supermodel's simulated one it gets further and waits at "network checking" for a second cabinet that never answers.

An operator who installed one of them alone fixed this in the game's test menu, under game assignments, by setting LINK ID to single. The agent did the same: it ran the game in a virtual X display, built a thirty line program that presses keys through XTest, and stepped through the menus one key a second, with a screenshot after each press. Faster than that, presses were lost or doubled and the cursor landed in the wrong test.

That fixed one machine. To fix every machine, the agent compared what the test menu writes. Supermodel saves the board's EEPROM to a file beside the game when it exits, and a factory file set against one saved after the change differed in five words: the link and a flag beside it, each in two copies of the settings, and a checksum. The checksum was the part that had to be right, since a game that finds its settings corrupt goes back to the factory ones. The agent wrote a short C program that tried every 16 bit CRC polynomial, with every common starting value, bit order and byte order, over every range of words the sum could cover, and checked each against both files. In forty seconds there was one answer: CRC-16/XMODEM over the 29 words of the first copy, high byte first. Daytona USA 2 keeps the same layout one word further along and agreed with it.

The launcher now does this before every start of a twin set, and only to a file laid out exactly this way whose checksum already adds up. The very first time one of these games runs there is no file yet, so it shows its network error once. The file it saves on the way out is set right as it closes, the launcher says to start it again, and from then on it plays.

04The rest of the cabinet

A few smaller things make Supermodel behave like everything else on the tube.

Supermodel counts a pad's buttons from one, and the controls file it writes for itself on a first run puts Start and the coin on buttons nine and ten, which a pad does not have. The launcher writes one for a pad instead. Select is the coin, the left stick and the d-pad steer, the triggers are the pedals and the shoulders change gear. A trigger rests at the bottom of its axis rather than in the middle, so its rest point is moved there, or the first half of the pedal would do nothing. Select and Start together leave the game.

SDL opens the desktop's sound device by name whatever it is told, so the launcher moves Supermodel's stream once it opens: through the leveller that brings every game to one loudness, and on to the television.

libretro's thumbnail repository has no Model 3 games at all. An arcade game it does not know now takes its original flyer from the Arcade Database, the set's own or else its parent's, and its title screen as a last resort. A flyer is what an arcade game had in place of a box.

05Twelve games

There are twelve Model 3 games on my disk, one of each: where I had two versions of a game I kept the one that runs on its own and in English. Eleven of them play, all at the tube's line count; the twelfth is missing a file, as the last section explains. Here are eight more, as Supermodel drew them at the television's mode during each game's attract sequence.

06Trying it

Model 3 is in OmaCRT 0.14.0. Build and install the Supermodel package first:

cd packaging/supermodel-omacrt
makepkg -si

Then put your own sets in a folder called model3 or arcade_model3 under one of the library's roots, all in that one folder: a revision such as dayto2pe loads the files it shares with daytona2 from beside it. They appear as Arcade (Sega Model 3) after the next scan. The details are in docs/systems.md.

Star Wars Trilogy Arcade needs its set complete, including epr-21119.ic8, the program of the board behind the flight stick. Without it the game stops at boot because its stick has no force feedback. The light gun games, The Lost World and The Ocean Hunter, are listed but untested: OmaCRT has no gun yet.

This is where they ended. Press play, drag along the curves, or step one pose at a time; every figure in this entry runs on the launcher's own sprites and joint table.

0%

ContactInitial contact

The heel strikes with the toe up and the knee all but straight.

Play◀▶Quarter speed

SpriteSkeletonLast pose

Ground matchedGround too slow

1. 1 Contact
2. 2 Down
3. 3 Passing
4. 4 Up
5. 5 Contact
6. 6 Down
7. 7 Passing
8. 8 Up

Near foot

Far foot

Hip

30°

-20° to 40°

Knee

5°

0° to 80°

Ankle

0°

-20° to 20°

01Copying the classics

The first fix was the animator's one: eight key poses, the knee bent, the pelvis bobbing, the arms in counterphase, each pose held for four frames the way a sprite of the period would be.

I still did not like it, and asked for the LucasArts games as the model. The agent read the SCUMM engine's rules (the ground moves with the pose, the head is large, a walker stops in profile before turning) and then measured Guybrush from The Secret of Monkey Island's sprite sheet: six poses, knees never straight, the head a quarter of the height.

I called it clumsy and slow. It was slow by measurement too: 0.42 heights a second, about half an ordinary walk, which suits a cartoon pirate in a small room. A man crossing a hall walks twice as fast. Indy in Fate of Atlantis was closer, with realistic proportions, a long stride and an upright torso. Copied onto our man, it still did not work, and I said the character itself probably needed redrawing.

02A figure drawn again

The agent stopped posing capsules and drew the man as shapes four times larger than the sprite, lit from the upper left, then reduced each 4x4 block to its commonest colour. Studying Indy at eight times his size gave the rest. He has no black outline: the dark of each material sits on its shadow side only. Every material has four tones, and the shadows drift cool. The cloth breaks into small clusters of two tones, and the whole sprite uses a few dozen colours.

Faces did not survive the reduction. At nine pixels across a reduced face is noise, so the heads are drawn by hand, pixel by pixel, in grids of 12 by 13. The launcher still makes every sprite this way when it starts, and the figure below stops it at each step.

Then I looked at the legs and said they walked like two logs.

03The laboratory's numbers

Animation books teach a walk as a handful of poses. A gait laboratory records the angle of each joint through the stride, and David Winter published the normal curves for hip, knee and ankle. The agent sampled them every 5% and posed the legs from them with a spline.

LogsKickCrouchWinter

The laboratory's curve: 18 degrees as the heel takes the weight, nearly straight at mid stance, 63 in swing.

Knee bend

0° to 80°

Play◀▶Quarter speed

Winter's curves show what our straight legs lacked. The knee gives 15 to 20 degrees as the heel lands and takes the weight. It bends to about 63 in swing while the hip carries the thigh forward, which the crouching version got wrong by bending it everywhere and the kicking version by bending it too early. The foot stays on the ground for 60% of the stride, and the ankle pushes off before it leaves.

The arms came from published studies of arm swing. An arm is furthest back as the heel on its own side strikes, swings 18 degrees each way and runs 5% of the stride behind the leg, while the elbow opens and closes between 14 and 40 degrees.

With the curves in, the legs alone lift and lower the hip by 2.3% of the height, inside the 1.5 to 2.7% measured in people. The bounce added in the first round doubled that, so we took it out.

04Into the launcher

people.rs does in Rust what the prototype did in Python, and draws each person and pose once and keeps it. The pelvis turns a little with the swinging leg and the chest against it, and the front and back views use the same curves end on, with a pixel of sway over the loaded leg. The new people shipped in OmaCRT 0.11.1.

The sprites were first drawn at 50 pixels and enlarged by a third, so one pixel in three came out doubled. Drawn at 68, the height the hall stands them, they scale by less than a tenth.

The janitor was the last one. He first appeared with the mop already in his hands, turned to face the camera, and mopped in slow motion. Now he carries the mop in, rests it, and mops standing, with a half step every second and a half and a sweep that moves his shoulders.

05The cast and the plates

Everybody in the hall is on one sheet, and so is the joint table. Both are yours to use, as are the two plates below them, drawn from the same sprites and numbers in the launcher's 8x8 font. A link back is welcome.

Sources: David A. Winter, The Biomechanics and Motor Control of Human Gait (1991); Richard Williams, The Animator's Survival Kit; Pixelblog 50, human walk cycle by SLYNYRD; the sprite sheets of The Secret of Monkey Island and Fate of Atlantis on The Spriters Resource, which the agent measured; no frame of them appears here.

On Monday evening I typed this into Claude Code:

OK, now I want us to bring out Opus 5.5's artistic talents and improve OmaCRT's pixel art overall. I want it to be fantastic.

I wrote every prompt in Italian, and they are translated here. By Tuesday afternoon the launcher had an arcade hall for a home screen, twelve consoles built as 3D models, a new sky over Brussels and a small gallery of René Magritte's paintings that move.

01How a language model draws

OmaCRT's launcher draws every frame itself, into a buffer of 320 by 240 pixels that goes to the television as it is. There are no image files for the interface. A cabinet, a cloud or a console is a Rust function that decides the colour of each pixel, sixty times a second.

Opus 5.5 draws by writing code, and it can read an image back. Articles written since its release on 22 September describe the same method, code that places every pixel. In this project every proposal went through four steps:

1. A mockup in Python on a design canvas, drawn with the launcher's own font, icons and colour themes, which the agent exported from the code before it started.
2. My answer on the canvas, usually one line.
3. The same idea in Rust, inside the launcher.
4. A headless render of the launcher, frame by frame, which the agent read as an image and criticised before I saw it.

The agent cannot see my television, and the preview window on my desktop does not run at full speed. So it rendered the screen it was working on at the second it cared about, looked at the frame and fixed what it saw. Most of its corrections were made that way, before I had seen anything.

02Three directions and an honest answer

The first canvas put the same four screens side by side at real size: the launcher as it was, and three directions.

I liked B and asked whether we would really gain anything compared with the current version. The agent answered:

Honestly, not much. B is today's layout, refined. Someone on the sofa sees the same launcher, a bit more polished. They don't see "fantastic".

It argued that almost every pixel on those screens is text and icons, so a new frame around them changes little. The next board redrew the font glyph by glyph, in a thin cut with a drop shadow and a heavy one. It also redrew the icons so that each has one meaning: a floppy disk for saving, an hourglass for slow motion, a house for home.

03Still too timid

I thought we were still being timid, and I sent the agent a prompt somebody had published for a pixel art game made with the same model. The agent applied that prompt's rules: colour ramps whose shadows drift toward purple and whose highlights warm up, a rim of light on every edge, grain in the darks, and animation at ten frames a second.

The next board was a sunset over a bay, with a sun sliced into scanlines and mountains with a rim of light. I asked where the bay had come from.

Honestly, nothing of yours. It works as a demonstration of technique, but it's an arbitrary landscape. It says nothing about OmaCRT or about you.

Staying with retro games, it offered a Mode 7 flight after F-Zero and Pilotwings, or an Amiga demo with copper bars. I picked the flight. The curving track made me seasick, so it straightened the road and slowed it down. Then it looked like a car game, and the agent took the road away and kept only the floor. After that it wrote:

When an idea hasn't convinced you after three attempts, it's usually the wrong idea.

We went ahead with B. Before a line of it went into the launcher, I asked for a way back. The agent made a branch, a tag called pre-pixel-art and a copy of the installed binaries.

04The consoles, four times

The systems list shows the selected console on a lit stage. The first round was drawn from memory, and its Nintendo 64 looked like nothing Nintendo ever made. The second was traced from Evan Amos's photographs at three quarters, and at a hundred pixels wide a traced photograph comes out dirty and crooked. The third stood the consoles up straight over the reference photographs, and the Saturn and the Super Nintendo still did not look like themselves. Then I wrote:

The Saturn doesn't look faithful, nor the SNES. I liked the isometric attempt. Think for a moment about how to do them really well, maybe animate them a little when they change. Let's do something properly that nobody has done.

Twelve minutes later a Super Nintendo and a Saturn were on the canvas and on the television as voxel models. Instead of drawing the consoles, the agent had built them and written a renderer for them.

Each model is a grid of cells, one for every 3.5 millimetres of the real machine. The Super Nintendo is 200 by 242 by 72 millimetres. Boxes, rounded boxes, cylinders and slots are added to the grid or cut out of it. The renderer sends one ray per pixel through the grid and stops at the first full cell, which gives hard faces and the right occlusion at any angle. Each face takes a tone from its material's ramp according to the stage's spotlight, with a 4x4 ordered dither between the tones, a dark outline and a highlight along the top edges.

The landing lasts 0.7 seconds. The console drops onto the stage, bounces once and turns a full circle. The turn still to go shrinks with the cube of the time left, so the spin slows into the three-quarter view.

A model costs under a millisecond a frame while it moves. At rest the picture is kept and costs nothing. By Tuesday morning there were twelve machines, from the NES to a GameCube and a beige PC for ScummVM.

Starting a game plays the matching gesture. A cartridge goes into its slot, a coin drops into the arcade cabinet, and the disc goes into the PlayStation. When I said its lid did not open, the next build hinged the lid at the back, printed the game's cover on the disc and lit the power light as it locked in.

05An arcade hall

For the home screen I asked for an eighties arcade hall, sketched on the canvas first. The agent drew two ideas: the menu on the screen of one OmaCRT cabinet, and a corridor of cabinets in perspective with a neon sign at the end. I chose the corridor, because it reads as a place, and asked for it to be drawn better and joined to the power-on animation.

The next board replaced my boot sequence with a new one that ended in the hall. I wrote back that I had not wanted to lose the opening animation, with its floor, its laser and its logo.

You're right, I misunderstood: it shouldn't replace today's animation, it should connect to the hall.

The next board kept the boot whole and added a bridge after it. The laser that ends the boot climbs the screen and the hall stands up behind it. The wordmark flies to the far wall and becomes the sign, and the cabinets come on in pairs.

In the launcher the hall is a small 3D scene. Every wall, cabinet side, screen and sign is a flat patch in space, projected through a fixed camera. A depth buffer keeps the nearest patch for each pixel. The static layer is drawn once for each state of the lights and kept, and only the cabinets' attract modes and the marquees are drawn every frame. The whole bridge costs 3.8 milliseconds a frame, only while the hall is lighting up.

06People who come in to play

I asked for somebody to walk in after a while and start playing, and maybe a jukebox. The next board had three characters and a Wurlitzer by the wall. I said it was too much, and the jukebox went.

The people were first drawn as sprites that slid. The agent rebuilt them as skeletons of capsules with hips and knees, and drove the walk cycle by the distance covered, so a foot on the carpet stays where it was put. There are four scenes now, one at a time: somebody loses to a GAME OVER, two people play side by side, somebody makes a record and jumps, and a janitor mops the aisle and leaves a wet trail behind him. A day later they were redrawn as sprites and walked from a gait laboratory's numbers, which How people walk in the hall tells.

I told the agent that the people passed in front of and behind things in ways that made no sense. It found three causes. They appeared inside cabinets, they cut corners diagonally, and they walked between a player and his screen. The agent rebuilt the hall around them, with two doors at the far end and a lit corridor behind. The rows of cabinets moved forward to leave a gap, and everybody walks on paths laid over the open floor. Each figure is tested against the hall's depth, so a cabinet in front of somebody hides him.

07Small works of art

The clock and weather page already drew the real sky over a small town. I asked for it redrawn "as little works of art in pixels", now that the agent knew how.

Each hour of the day has its own palette of sky, sun and shadow, and the weather greys it. A cloud is a cluster of balls, and every pixel of a ball is shaded by that ball's own normal in five dithered tones, which gives it volume. A far city stands in the haze behind the near one. The digits of the clock have a bevel, lit on the top and left edges of each stroke.

The skyline has one local detail, because I live in Brussels: the Atomium stands on the horizon when the weather is for Brussels. I did not like the first one. My whole prompt was "Draw the Atomium properly, I don't like how you're doing it." The agent went back to the building. The Atomium is a cube standing on one corner, with spheres at the corners and the centre joined by tubes. So the agent rotated a real cube onto its corner, projected it, and tried four turns about the vertical before choosing the silhouette on the postcards. By day the spheres are chrome and reflect the sky.

08Three paintings that move

René Magritte lived and painted in Brussels, and I asked for a few moments after his work on the same page. There are ten. Each one comes up rarely, for twenty five seconds, and only when the weather suits it. It fades in and out through the same ordered dither, so the page never blends two pictures.

Then I asked for three of his paintings redrawn whole, as homages, and hung in a gallery. On the canvas Le fils de l'homme kept its tall format. I asked for 4:3, with artistic liberties, and for all three to move a little while staying in their mood.

The apple in front of the face slides aside to show another apple, and the eye behind it blinks. A bird crosses the daylight sky over the lamplit street, and one window goes dark. In Golconde the men bob in the air, and every so often one of them raises his hat.

09What the model did

Anthropic's page for Opus 5.5 quotes a tester who had several models build a game from one prompt, and Opus 5.5 "scored higher than any other model on the strength of its graphics and polish". Other people have had it write animated pixel art scenes in a single HTML file. Here the job was longer. It had to keep one look across an existing program for a day, on a screen of 76,800 pixels.

It worked in the vocabulary of the period, Super Famicom windows, Mode 7 floors, copper bars, colour ramps and ordered dither, and it could say why one suited a screen and another did not. It found its own references: the consoles' measurements, Evan Amos's photographs, the Atomium's geometry and the paintings. When drawing the consoles failed three times, it changed method and wrote a renderer. Its animation has easing, a bounce, feet that stay planted and a hat raised at the right moment. It checked its frames before I saw them, and it told me when one of its own ideas was weak.

It also got things wrong. It drew consoles from memory, reverted work I had wanted improved, replaced a boot sequence I wanted to keep and put more in the hall than it needed. Each time, one line from me put it right.

Some of the ideas were silly, like a Magritte gallery in a launcher for retro games, or a janitor mopping an empty aisle. I enjoyed asking for those most, and each of them was on the television the same day.

The work took two canvases and fourteen boards, 39 commits after the pre-pixel-art tag and about 9,800 lines of Rust. Nothing in this entry was made with an image generator. Each picture is either a mockup the agent drew with code on a canvas, or the launcher's own framebuffer, rendered offline and enlarged by whole pixels.

In 0.9.0 and 0.10.0, we changed how the launcher connects a pad, remembers it and hands it to RetroArch. The new pads screen brings those changes together on the television.

01Checking what Bluetooth actually did

Connecting a Bluetooth controller involves three commands: pair, trust and connect. The old code discarded the results of the first two and reported the result of the third. If pairing failed, the screen could give a misleading account of what had happened.

Each step now has its own deadline and its result is checked before the next step starts. A failure names the step and shows the reason Bluetooth returned. The player can retry or cancel from the controller already in hand.

The search also needed to keep running when the player left its screen. Previously, progress depended on that screen being drawn. Moving the work out of the drawing path lets the interface stay responsive while discovery or pairing continues.

A failed connection now leaves a specific step and an error to investigate.

02A model name does not identify an individual pad

The names devices report are awkward on a small screen. “8BitDo Ultimate 2C Wireless Controller” does not fit in a twelve-character label. Cutting it after twelve characters leaves “8BitDo Ultim”, which loses the part that identifies the model.

The short name now drops generic words first, then the maker where necessary. The television can show “Ultimate 2C” or “M30”, alongside the connection type. Battery charge appears only when the kernel supplies it.

Remembering the device requires more than a readable name. SDL gives us an identifier shared by controllers of the same model. To distinguish individual units, OmaCRT also reads a Bluetooth address or USB serial from sysfs, the kernel's device information.

Some controllers provide neither. Two identical pads without an individual identifier remain ambiguous, and the interface says so. Assigning them reassuring labels would not give us a reliable way to recognise them next time.

03The letter on the button

The launcher reads controllers through SDL. RetroArch has its own controller profiles. Their names for buttons do not always match, so a mapping that works in the launcher needs translation before a game can use it.

The Sega-style layout exposed another difference. SDL names face buttons by position. On a Mega Drive or Saturn-style controller, the button in the southern position can be marked B. Treating SDL's A as the printed A made the launcher confirm on B, while RetroArch used the expected letter inside the game.

OmaCRT now reads the button labels from the RetroArch profile for that controller. It swaps the pair when that profile establishes the mismatch. Without a matching profile, it keeps SDL's mapping instead of guessing from the device name.

The existing mapping wizard still handles unknown controllers. That path needed fixes too: a second unknown pad arriving at startup could cancel the first pad's mapping request, and unplugging a controller during mapping could leave the wizard waiting for input from a device that had gone.

04Giving the controllers somewhere to go

The television screen now has four visible sockets. Each shows the controller assigned to it, with different states for a connected pad, a remembered pad that is switched off, and an empty socket.

Switching a pad off should not erase the player's arrangement. A newly discovered controller goes at the end of the saved list. The shoulders move the selected controller through that order, and Identify makes it vibrate, where the controller supports rumble.

The order lives in pads.toml. When a game starts, the connected controllers receive player ports in that order; disconnected controllers are skipped. If the first controller is off and the second is on, the second becomes player one for that launch. The saved order remains intact.

RetroArch fixes those assignments when it starts, so rearranging the list affects the next launch. OmaCRT writes the requested player indices, then reads RetroArch's device enumeration from its log to check the result. If they disagree, the launcher reports the mismatch.

Testing the screen uncovered a more basic inconsistency: its header could count two connected controllers while the sockets showed one. Two copies of the list were overwriting each other. Fixing the display meant fixing how that state was held.

There were smaller input bugs along the way. Unplugging a controller with its stick held could leave the menu scrolling. Controllers present before startup followed a different discovery path and were not being saved. Discovery at startup now records controllers in the saved list too.

05Managing them with the television off

Once the television could show and rearrange its controllers, the desktop panel needed access to the same information. The Quickshell panel now lists the pads, their connection state and controls for moving or forgetting them. Its Pads button opens the four-port overlay.

The overlay has room for details that would crowd the television: the device identifier, RetroArch's index and information about the face-button mapping. It also provides Identify and the ordering controls.

The two interfaces must not overwrite each other's changes. While the launcher is running, desktop actions ask it to update the order and save the file. When it is stopped, the command-line tool edits the file directly. This keeps a single writer responsible for the saved order.

There was a deployment problem here too. Updating the plugin files did not replace the QML already loaded in the desktop shell. The installer now restarts the shell to load those changes, or reports that a restart is needed when the session is locked.

06What still needs testing

This work has been tested on one machine with its connected controllers. Other models may expose different mappings or omit the identifiers needed to tell identical units apart. Battery reporting and rumble also depend on what the device provides.

The pads chapter in the manual covers the controls and commands. The implementation changes are in 0.9.0 and 0.10.0. A useful next test is another person's controller, particularly one that behaves differently between the launcher and a game.

A CRT television’s horizontal deflection uses a tuned circuit, with a flyback transformer and an output transistor designed for a particular line frequency. On this set, the beam returns to the start of a line fifteen thousand seven hundred and thirty times a second. That return motion gave Flyback its name.

I built it to drive the television from my desktop PC. The measurements below cover the software path up to the start of scanout, not the full delay from a physical button press to light on the screen.

01What it is

Flyback is a Wayland compositor. One process, one thread, one event loop, 3616 lines across four files, built on smithay 0.7.¹ It is part of OmaCRT, a launcher for a television, the piece of that project that touches hardware.

shell/src/bin/flyback/ · the four files this study is about

A desktop compositor manages the system’s outputs and arranges windows on them. A kiosk compositor typically puts one window on an output. Flyback instead requests a connector that the desktop has been told to leave alone.

It receives a file descriptor granting control of that connector, programs the television’s timing and manages scanout. Hyprland continues to run the other screens.

Four clients use it, all local and all started by the same project: the launcher, RetroArch, mpv, and a measuring instrument that exists only to take the numbers in this study. They reach it through WAYLAND_DISPLAY=wayland-crt.

This is experimental. Before sending a timing to the kernel, Flyback checks its line rate against the band in crt.toml, 15 to 16.5 kHz as shipped. It also checks that the field rate is between 40 and 90 Hz and that the timing values are in order. The project had no such guard for its first several months.

shell/src/crt/output.rs · the guard, and what it refuses

The set is a BeoCenter 1 from 1998, running the launcher over a leased connector, and it is the hardware every number below was taken on.

02Why a desktop will not do it

A television at 15 kHz wants a modeline whose line frequency is about a quarter of the slowest thing any monitor has asked for since 1987. Three parts of desktop output management get in the way; only the first concerns the mode itself.

The compositor will not set the timing. No desktop compositor exposes an arbitrary modeline, and the ones that expose custom modes validate them against what a monitor plausibly wants.

The compositor will not stop managing the output. Even where a mode can be forced, the desktop keeps ownership: it will re-probe, re-arrange, apply its own scaling, and put its own idea of a cursor on the screen.

The compositor will not give away the scanout. Frame scheduling is the compositor's own business, and what the protocol gives it to work with is most of this study. A client cannot decide when its buffer latches.

DRM leasing provides a way to hand that control to another process.

03Taking the connector, and what a lease actually grants

wp_drm_lease_v1 exists because virtual reality headsets are displays that no desktop should ever try to use as a desktop. A connector marked non-desktop is offered for leasing instead, and a client that takes the lease gets a DRM file descriptor that is master for that connector and its CRTC.² The protocol's own wording is general (a compositor "will not use this output at all and will make it available for leasing"), and its established use is with headsets.³

The same mechanism can mark the television’s connector non-desktop. The flag comes from an EDID vendor block that Microsoft specified for head-mounted and specialised displays. The parser sets the flag for versions 1 and 2 unconditionally, and for version 3 when the block does not claim desktop usage.⁴ This project writes that block into a fabricated EDID and loads it as a connector override, so Hyprland stops configuring the connector and starts offering it.

A lease is a drm_master in its own right: a lessee holding only the objects named in the lease.⁵ Flyback can set a mode on that connector and flip its planes. It cannot touch the desktop's outputs, and the desktop cannot touch its. When the lease is revoked the connector goes back.

I found no prior report of a television being leased this way. That search does not establish that this is the first.

shell/src/bin/flyback/lease.rs · asking for the connector, and holding it

04The EDID we write ourselves

A connector’s classification comes from the display’s EDID. The identification supplied by this converter does not mark it non-desktop, so the project generates an override.

An EDID has a 128-byte base block, optionally followed by extension blocks. The driver reads it over the display data channel when probing the connector. The one that matters here is the CTA-861 extension, which carries a collection of data blocks and then a list of detailed timings. Each data block has a tag and a length in its first byte, and tag 3 is a vendor block: three bytes of registration identifier followed by whatever that vendor wants.

The first vendor block is Microsoft’s. The kernel parser uses its version byte to decide whether to mark the connector non-desktop. Versions 1 and 2 mark the connector non-desktop unconditionally; version 3 does unless the block explicitly claims desktop usage.^5b

So the block this project appends is tag 3, length 21, the Microsoft identifier 5C 12 CA, version 02, a flags byte, and a sixteen byte container identifier. That identifier is derived from a name, so that two televisions in one house cannot claim to be the same device.

The block changes how the kernel classifies a connector, and nothing about what is sent down it. Every other decision in this project (the modeline, the line rate, the guard that refuses a line rate outside the band) is unaffected by it.

The second vendor block is AMD's, and what makes a variable refresh rate possible at all. Nine bytes: 68 1a 00 00 01 01 <min> <max> 00. A tag and a length, the AMD registration identifier, a version, the two refresh rates in hertz, and a flags byte.

Those bytes were worked out by trying them, because no code in the kernel parses them. The CEA extension block is handed to the display microcontroller and the firmware hands back a version and two rates.⁶ There was nothing in the tree to read, and edid-decode reading the result back as "Vendor-Specific Data Block (AMD), Version 1.1" was the only confirmation available.

The flags byte must remain zero on this chain. A monitor that sets it is asking for a conversation over the monitor control command set. When a block declares such a control code, the driver goes on to require that the display really support FreeSync over MCCS, and revokes the capability when it does not.⁷ A television does not answer. The initial tests had settled on zero before the driver check was identified.

The declared refresh range must pass two checks. To be considered capable at all, the driver wants the declared range to be strictly greater than ten hertz.⁸ To reach the active variable state, the FreeSync module first caps the declared maximum at the mode's own nominal rate and then wants what is left to be ten or more.⁹

So a range of 55 to 66 declared against a 60.041 Hz mode becomes 55 to 60.041, a range of five, and is refused in silence.

The range this project ships is 48 to 62 for exactly that reason, and the generator refuses to emit anything narrower than eleven.

Then the whole block is rebuilt and the checksum recomputed, because an EDID whose bytes do not sum to zero is discarded, and the new one is handed to the kernel through edid_override in debugfs. That alone is not enough: the kernel read the real EDID when the connector was probed and is not going to read it again because a file changed.

So the script simulates an unplug and a plug through trigger_hotplug, and the connector comes back carrying the identity we wrote for it. Undoing it is the same two steps with reset written instead.

shell/src/crt/output.rs · the connector, the EDID and the modelines

The override takes 87 lines of Python and 104 of shell. The same approach may be useful for other displays that need a non-desktop connector classification.

05What the protocol gives a compositor to work with

The scheduler uses the following Wayland mechanisms.

A surface is double-buffered. A client accumulates pending state (a buffer, a damage region, a scale, a callback request), and wl_surface.commit applies all of it at once. So a commit is an event with a timestamp, and it is the only moment at which a compositor learns that a client has finished drawing. Every scheduling decision in Flyback starts in the commit handler.

A role decides what a surface is. Flyback implements xdg_shell and configures every toplevel fullscreen at the output's size, so a client is told 3520x240 and draws into it. It also implements wp_viewporter. That is how the launcher draws 320x240 and has it scaled to the output without knowing the output's real width. xdg_popup is configured so that a client making one is not broken, but popups are not mapped or drawn.

Frame callbacks pace the clients. A client requests a callback for each frame it intends to draw. The compositor answers done with a timestamp meaning _now_. This callback cannot specify "draw a frame intended for time T", and it gives the client no way to request 59.92 Hz. Flyback controls the pacing by choosing when to send done.

Flyback therefore accepts refresh-rate requests on a private control pipe. Newer protocols provide more timing control, but Flyback does not implement them yet. wp_commit_timing_v1 lets a client put a time constraint on a content update (present this as close as possible to, but not before, time T), and wp_fifo_v1 gives first-in-first-out semantics without the client having to guess.

Both landed in wayland-protocols 1.38, both are implemented by Mutter and KWin, and both are already in smithay: adding them here is a delegate and a handler.¹⁵ They are candidates for a future version, but none of the clients used on this television speaks them yet.

wp_presentation is the answer in the other direction. Without it a client cannot know when its frame reached the screen and has to guess. Flyback implements it on CLOCK_MONOTONIC, fed by the timestamp the kernel puts on the page flip event, and claims HwClock | HwCompletion in the feedback flags only when the driver's stamp really is on the monotonic clock.

mpv has used this for years; RetroArch gained it in July 2026.¹⁶ Getting it working was also the first piece of this whole study, because without it there is nothing to measure with.

Buffers reach the plane without a copy. zwp_linux_dmabuf_v1 with default feedback lets a client hand over a GPU buffer directly; a buffer that cannot be imported is refused through the protocol's own notifier instead of taken and dropped.

shell/src/bin/flyback/host.rs · the socket, the seat and the protocols

Input support is deliberately limited. There is no pointer and no touch on the seat (it has a keyboard and nothing else), and Flyback opens no input devices at all. The pad is read by the programs themselves through evdev. This arrangement avoids routing gamepad input through the compositor, but would not suit a general desktop.

06The scheduler, and why a variable rate has no deadline

Each frame, the compositor decides when to wake its clients, when to render and when to queue the result for scanout. The usual answer to all three is "at the vblank". It is safe and it costs most of a frame.

At a fixed refresh there is a deadline. A flip has to be queued before the vblank or the picture waits a whole frame.

So Flyback draws at the last safe moment: one frame, less a margin taken from what recent frames actually cost. And it tells the clients early enough that their commit arrives before that, which it works out as twice their own measured drawing time plus a slack.

Telling a client at the vblank instead, the way this compositor used to work, throws away almost a whole frame: the flip goes out before the client has committed, and the client's picture then waits for the frame after. This is the same idea GroovyMAME calls frame delay, done for every client at once instead of inside one emulator.

At a variable refresh there is no deadline at all. A flip that arrives after the frame's minimum length simply makes that frame longer, and every frame is kept. So the compositor draws the moment a client commits, and tells the clients as late as it dares.

The one thing it must never do under a variable rate is draw at the vblank. Anything committed while the last flip was in flight is about to be superseded by the frame the client is drawing now, and flipping it puts a stale picture in the air that the fresh one then waits behind. That single mistake cost a frame and a half.

Here is the difference, measured on the compositor's own trace rather than drawn. The same client in both, drawing one millisecond, 200 frames each, microseconds as 5th / 50th / 95th percentile:

Under a variable rate the commit is drawn and queued in 75 microseconds, because there is nothing to wait for. Under a fixed one it sits for four milliseconds waiting for the deadline, and the tail says that on some frames it sat for nearly the whole frame.

shell/src/bin/flyback/comp.rs · the event loop, the frame clock and the queue

The scheduler maintains three estimates to account for client wake-up, rendering, queuing and the hardware latch. render_cost is what this compositor takes to draw and queue. client_cost is what a client takes between being told and committing. When a rate has been asked for by name, rate_trim is the measured error, a quarter of it corrected each frame.

What was wrong with that, and how it was found

client_cost was one number for the whole compositor. Frame callbacks all go out together, so a single estimate is really the slowest client on the tube, and with the launcher mapped underneath a game, that is the launcher, and it is not the one being watched.

Re-running the instrument with and without the launcher exposed the problem. A client that draws in a millisecond measured 18.70 ms from commit to scanout with the launcher mapped, and 3.56 ms with the launcher stopped. The only change was the hidden launcher window.

The estimate is per window now, kept in the window's own user data, and the callbacks are paced by the window on top, the one being looked at. A window underneath answering late costs nothing; the window on top answering late costs a frame.

Two more changes followed from chasing the tail. A commit from a window that is not on top marks the frame dirty but does not decide when the flip goes out: flipping for a window nobody can see takes the slot the top window's next commit needs. And a window's first measurement replaces the whole-frame assumption outright instead of losing to it for the fifty frames a decaying maximum takes to come down. Fifty frames is the half second anybody actually watches.

With the launcher mapped underneath, the fast client now measures 3.79 ms, against 3.56 with the tube to itself. The cost of a hidden window is 0.23 ms.

07A variable refresh rate, on a television from 1998

A set's horizontal rate must not move: the flyback transformer and the deflection circuit are tuned for one. The vertical rate is another matter, because the vertical oscillator re-triggers on sync. So every refresh an emulation asks for (59.92 for a Mega Drive, 60.0988 for a NES, 57.5 for one arcade board or another) is reachable by changing the vertical total alone and leaving the line rate at 15730.8 Hz.

That is exactly what adaptive sync does in hardware: it stretches the vertical blanking and touches nothing else. I tested whether this consumer television from 1998 would follow those changes. The one prior report of adaptive sync on a CRT is on multisync PC monitors rather than on televisions.¹⁰

The driver requires two settings. An earlier version of this project’s documentation incorrectly listed a third. To reach VRR_STATE_ACTIVE_VARIABLE the driver wants the connector to be freesync_capable with the mode's refresh inside the declared range, and the CRTC's VRR_ENABLED property set.¹¹ That is all.

This project published, for a week, that amdgpu.freesync_video=1 was also required. It is not. That parameter gates a different mechanism: a smooth change of the front porch that skips the modeset and produces VRR_STATE_ACTIVE_FIXED.¹²

It was tested directly on this chain, with the parameter set and a timing shaped exactly as the driver's own condition requires: same clock, same htotal, vertical total moved, vsync_start moved with it, sync width unchanged.¹³ The change still cost 222.8 and 229.1 ms. That path does not trigger here, and the parameter has not been shown to do anything.

With the range declared, the timing generator is programmed with room. amdgpu_dm_dtn_log reported vmin 261 vmax 327 for the tube's timing generator. Those registers hold the total minus one,¹⁴ so that is a vertical total of 262 to 328 lines: 60.041 Hz down to 47.96 Hz, at a line rate that never moves.

And the scanout follows. Asked for a rate by name and measured as the median of the last 300 vblank intervals, with fifteen seconds of settling: 60.041 asked gives 60.04, 59.92 gives 60.02, 57.5 gives 57.59, 55 gives 55.01. Ask for 50 and it is held at 55, and says so, which brings us to the part that is a property of the television, not of any software.

Where the set stops following

A television's vertical deflection follows a longer frame only so far, and past that the picture loses height and keeps it for as long as the rate does. Filmed on the BeoCenter 1, each step held for eight seconds, the height measured against the picture's own width so that the camera's drift cancels, which works because the width cannot change while the line rate does not:

The image compares two frames from the same film, at 55 Hz and 50 Hz, with the height measurements marked: 1237 pixels against 1069. This measures the visible picture, which the software timestamps cannot capture.

The last row is the control: it repeats the first, and its coming back to -0.1% is what says the -11.5% was the television, not the camera. So the useful range on this set is 60.04 Hz down to about 55, and the whole NTSC family sits four times inside it. PAL at 49.70 is outside it and does not need to be inside: a PAL frame is 288 active lines and wants its own modeline anyway.

Brightness was measured in the same frames. A phosphor's brightness depends on how long it is left between refreshes, so a television whose frame length keeps changing will pulse. Steady to within two parts in a hundred at every step is what that looks like when it is not happening.

Where a set gives up is a calibration, like the picture shift, and it lives in the configuration as output.vrr_min_hz. Nothing asks the tube for a slower rate than that, however slowly a program runs.

The rate has to be asked for, not discovered

Put an emulator on the tube whose content rate is not the compositor's cadence and the two beat. Half the frames end at the hardware's minimum vertical total and half run to its maximum, four milliseconds apart, and the picture flickers visibly. Pacing the frame callbacks to the client's own commit interval instead of to the mode's period removes it: on a Mega Drive core the step between one frame and the next fell from 4283 microseconds to 24.

What that does not do is let a program choose a rate. A client paced by frame callbacks runs at the cadence it is given, and the cadence is taken from the cadence it runs at, so wherever it settles is where it stays.

Taking the brake off lets the core set the rate, and on an NTSC title it does exactly that. On a PAL one RetroArch then had nothing holding it at all and ran at 80 Hz, faster than the hardware's shortest frame, and the pacing collapsed again.

So the rate is asked for: rate 59.92 on the control pipe. The launcher knows which system is running and what that system's refresh is, and telling the compositor is one line on a pipe it already has.

What the variable rate costs, found two days late

For two days I noticed an occasional shimmer, at one point describing it as a format change. Switching variable refresh off stopped it; switching it back on brought it back. I repeated this twice each way, judging the picture by eye.

The instrument could not see it, for a reason that took two days to find. The compositor timed the gap between two vblanks with its own clock, at the moment its handler ran, which is when the process woke up rather than when the hardware flipped. The driver's own timestamp for that vblank was in hand and was being handed to clients, and was not used here.

The two quantities are the same size, so a frame that was genuinely longer and a wakeup that was merely late read identically, and both states reported the same spread. Using that existing hardware timestamp made it possible to distinguish the two.

And the threshold is not a percentage. A television's vertical countdown, once it has locked, works inside a narrow window. A Philips jungle datasheet gives 261 to 264 lines a field at 60 Hz, and says that a sync pulse arriving outside that window starts the retrace at the end of the window instead of on the sync. This mode is 262 lines nominal, so there are two lines of room. 127 microseconds. Counted against that, on the driver's clock, three alternating windows of twelve hundred frames each:

With the rate fixed the set never loses its window. With it variable it loses it about once every twenty seconds. That interval was consistent with what I had noticed.

And 291 lines is the far side of this set's cliff. The rate walk filmed the day before, for an unrelated reason, puts that cliff between 286 lines and 291: at 286 the picture is 0.2% short, inside the noise of a hand-held film, and at 291 it is 15% short. The cliff is a range. The worst field this compositor produces lands on the far side of it, within five lines of where it begins, and that was measured a day earlier for another purpose.

There are two limits to this explanation. The datasheet is for a family of Philips jungle circuits, and the identification of this set's is an inference from its service menu. So the window is a documented design for sets of this kind, and not a measurement of this one. The link between stretched fields and the visible shimmer also remains an inference: the tube has not been filmed during one of those events.

Turning variable refresh off removes the shimmer but increases latency. The same client, commit to the start of scanout, three windows each way: 2.02 ms with the variable rate, 5.16 ms without it. Both effects come from the way variable refresh ends a frame. The frame ends when the flip lands, and that one fact lets a client draw at the last moment and stretches the field when the flip is late.

Every stretched field carries the same signature. The time from the client's commit to the flip being queued, 63 µs at the median, is one to three milliseconds on those fields, and the client's own drawing cost does not move. It is the compositor that is late.

The bursts line up with the desktop being used, on the same graphics card as the television. Idle, the rate falls to six fields in 3602 and then to none. With somebody working on the machine it was nine in half a second.

So the design target stops being "stretch it less" and becomes a deadline: no flip may be more than 127 microseconds late, which the knob that exists today cannot guarantee.

The slack a client is given on top of twice its own drawing time is 1500 µs while the refresh is variable, and the worst overrun seen was three milliseconds. Slack is paid on every frame whether it is needed or not: 3000 µs of it measures 3.52 ms of latency and 5000 µs measures 5.51, which is worse than giving the variable rate up. Widening it is a mitigation.

Three milliseconds is the worst that was seen, and the ceiling is unknown. The distribution of that overrun on a busy machine has not been established, which matters for choosing a number. The deadline holds either way: the 127 microseconds is measured, and so is what each setting of the slack costs.

What has not been isolated is which part of the compositor's own path spends those milliseconds, and what it is not has been measured. The flip call is ruled out: in fourteen thousand samples above the threshold the ioctl never took more than two milliseconds. The client is ruled out, since its drawing cost does not move on the fields that stretch.

It follows the desktop being used, on a card the desktop and the television share. The measurements do not isolate a cause within that shared path.

Two more things came out of the same afternoon. A still picture would be worse than any of this: with no flip at all the field runs to the declared maximum of 328 lines, 37 past the cliff. It does not happen here because the launcher draws every frame, and over 10 125 consecutive intervals the compositor missed a flip three times, each for two or three frames. A client that redraws only when its content changes would need explicit handling of this case.

Turning the variable rate on and off costs no modeset on this chain, despite the driver reporting RequiresModeset for the property. Fourteen toggles, the frames either side of every one of them 16 655 or 16 656 microseconds, not one gap above 20 ms.

No product change was made after these tests. Choosing between occasional shimmer and the latency increase needs a visual assessment as well as the timing measurements. The overruns come from the desktop competing for the same card, and an idle machine does not produce them. Only somebody watching the screen while the machine is in use can settle it.

docs/data/vrr-frame-length-2026-09-13.txt · the fields, the toggles, and the three fixes rejected on the mechanism

08How any of this is measured

The next section’s measurements come from one program. Its clock sources and scope determine how to interpret the results.

The problem is that the two ends of the measurement are usually on different clocks. A button press is timestamped by the kernel's input layer. A frame reaching the screen is timestamped by the display hardware's vblank. Comparing them means getting both onto the same clock, and then getting the second one out to the program doing the comparing.

shell/src/bin/latency.rs does that, in about 1400 lines, behind a feature flag so that it is absent from every build anybody installs.

The instrument creates a virtual pad. A virtual gamepad through uinput, so a press can be generated at a chosen instant instead of waited for. Then it opens the event node the kernel creates for that pad and sets EVIOCSCLOCKID to CLOCK_MONOTONIC, the clock DRM stamps a vblank with. Both ends of the measurement are then on one clock, and the difference is real rather than approximate.

There is a tenth of a second of waiting between creating the device and opening its node, because the kernel makes the node before udev hands it to the input group, and the first open is otherwise refused.

The other timestamp comes through Wayland. The vblank timestamp reaches it as wp_presentation feedback. That is why the protocol work came first: without it there is nothing to measure with. The instrument also checks the feedback's flags and reports how many of its samples carried HwClock | HwCompletion and not an estimate. In the runs published here that is 300 of 300.

The instrument generates presses at random points in the frame. A test that presses on the frame callback measures the same instant of the frame every time, and does not represent input arriving at arbitrary times.

So the default mode spreads its presses across the frame, and the distribution has the half-frame wait in it because a real one does too. The paced mode, which draws on the frame callback the way a program paces itself, is a different measurement and is labelled as one wherever it appears.

The report also identifies the costs outside the measured interval. The report ends with the measured cost of the instrument's own work, reading the pad and drawing: 0.01 ms. Then a line saying that a real pad adds its own polling in front of everything, one to eight milliseconds by its rate. That belongs to the pad, not to this. It also decomposes its own median against half a frame, so that the part nobody can remove is separated from the part this compositor is responsible for.

What is left outside even that: the converter and the phosphor. The converter has no frame store, and the evidence for that is behaviour and not a datasheet. Under the variable rate it tracks a vertical total that changes from one frame to the next without losing lock, and a frame store could not do that. Its own delay has not been measured here. The phosphor lights within microseconds of the beam arriving. On a set with no panel and no scaler, "the start of scanout" is very nearly "the picture on the glass", and that is the property that makes this chain measurable in software at all. On an LCD the same program would be measuring something else and a photodiode would be compulsory.

No number in this study is click to photon. Every timestamp is a kernel clock, at the press and at the start of scanout, and the step from the start of scanout to the glass is reasoning from what the hardware is. No instrument here has taken it.

The instrument also draws a test card. A separate mode puts a self-driving pattern on the tube for filming. A clapper synchronises the film with the log, the steps are counted in frames, and the word END is drawn from a bitmap font, so that a recording carries its own label. The table of height and brightness against refresh rate was measured from film shot that way.

shell/src/bin/latency.rs · the instrument, behind a feature flag

--dump writes every sample to a file in the order taken, one millisecond value per line. This produces the full set of three hundred samples behind what it costs.

09What it costs

Every figure here was taken on the chain in the conditions block at the top, with the launcher mapped underneath, because a program on this television is never the only client on it.

Commit to the start of scanout, for a client that draws on the frame callback the way a program paces itself:

The launcher end to end reports 2.0 ms, and 4.5 ms with every core on the machine busy.

The baseline can be reproduced by disabling three features. Turn the three switches off: FLYBACK_LATE_DRAW=off, FLYBACK_MARGIN_US=off, and the variable rate off. Together they reproduce this compositor’s earlier scheduling behaviour. The same client on the same machine then measures 33.36 ms, two frames exactly, with the launcher's own figure at 33.1. Anybody with this hardware can run both halves.

Press to the start of scanout, from the kernel's timestamp for a button press, 300 presses at random points of the frame: best 1.46, median 10.19 (0.61 of a frame), 95th 17.52, worst 18.21 ms. All three hundred samples are published alongside these summary statistics.

The decomposition matters more than the median. 8.33 ms of it is half a frame, which is what any commit at a random phase waits for, whoever is compositing. The compositor's own contribution is the 1.9 ms above that. The instrument measures its own overhead at 0.01 ms.

The pad is a virtual one, made with uinput and read back through evdev with the clock set to CLOCK_MONOTONIC, so both ends of the measurement are on the clock the vblank uses. A real pad adds its own polling in front, one to eight milliseconds by its rate, and that belongs to the pad.

A mode change, for comparison, from the request to the first vblank after it:

182 to 229 ms, and it does not matter how little of the timing moves. Those figures are the kernel's share of it, and the television is dark for longer. The converter has nothing to lock to for 280 ms, and filmed at 240 fps the glass shows nothing for about 400 ms, the tube adding its own 120 ms after the picture is back. That is the cost the variable refresh rate avoids, and the first row is what says the cost is the modeset itself.

docs/data/modeset-lock-2026-09-13.txt · the converter's lock read over i2c, and the tube filmed at 240 fps

Four of these numbers were wrong until the day before this was published

Nothing from this project had been published outside its repository when every claim in it was checked again. Four needed correction. The checks also found two defects that normal use had not exposed.

The cost of a mode change was published as 166 to 190 ms. It could not be reproduced from any log, because the clock meant to measure it was declared, zeroed and read, and never assigned a value: the line it feeds had never been printed in the life of the project. Armed, it gives the table above.

Press to picture was published as a median of 20.4 ms. That reading predates the scheduler's own fixes, which were made the same day.

The refresh rates the tube was given were published to three decimal places, 59.922, 57.499, 55.000 and 49.999 Hz, by an instrument that does not exist here. One of the four was below this project's own floor and would have been held at it.

And amdgpu.freesync_video=1 was published as required. It is not: tested on this chain, with the parameter set and the timing shaped the way the driver's condition wants, the change still cost 222.8 and 229.1 ms.

The second defect: the two explanations printed by the rate command were the wrong way round. They compare periods, not frequencies, so a longer period is a slower rate, and asking for a rate below the floor answered "the mode itself is no faster than that", the opposite of what had happened.

The full record, voice by voice with every kernel claim pinned to a file and a line, is in the repository.¹⁷

10What it does not do

Flyback has a narrow feature set. One unimplemented possibility is beam racing, which would use the control of scanout provided by the lease. I found no report of this being implemented through a leased connector on Linux.

No XWayland. No pointer, no touch, no input devices of any kind. No layer shell, no decorations, no window rules; the stacking order is the whole of the window management. No clipboard, no primary selection, no drag and drop. No multi-output: one leased connector, one CRTC, one mode, and two televisions would need most of this rewritten. No fractional scale, no HDR, no colour management, no explicit sync, and no commit timing or fifo yet. It is a compositor for one television and should not be used as a general-purpose one.

Three absences deserve more than a list.

Tearing. wp_tearing_control is the other road to low latency and it is not taken. On a 15 kHz set a torn frame is visible across a third of the picture, and the scheduler recovers most of the same time without it.

Interlace. A 480i modeline on this chain is _accepted_: the modeset returns without error, the converter keeps its lock, and the television shows a narrow strip. The timing is programmed as interlaced and scanned out progressively, at a rate no television locks to. Five separate things in the current upstream tree stand between that modeline and a picture on DCN 3.2.

1. The interlace flag is never copied out of the DRM mode into the timing the display core uses.¹⁸
2. The timing validator returns false for any interlaced timing, under the comment _"Temporarily blocking interlacing mode until it's supported"_.¹⁹
3. The register that enables interlacing is present in the DCN 1 register list and absent from DCN 3.2's. The code that would write it is generation-independent and already there, and AMD's own headers for this ASIC carry the register and its enable bit.²⁰
4. The mode validation library this generation uses doubles the vertical ratio for an interlaced timing when the ASIC does not claim progressive-to-interlace support, which this one does not.²¹
5. A line buffer field that exists for exactly this is never set from the timing.²²

This project decided not to require a patched kernel, so it does not have interlace.

Beam racing. Drawing the frame just ahead of the electron beam is the last real latency win available, and it exists in GroovyMAME and in WinUAE, on Windows. On Linux it never has: RetroArch has had a bounty standing for it since 2018,²³ and what landed in 2025 is the opposite thing, a shader that _simulates_ a CRT's rolling scan on a high-refresh LCD.²⁴

The reason nobody built it is that beam racing needs ownership of the scanout, which a desktop compositor denies, and a leased connector does not. So this is a setup where it could be built, and it has not been built here either. The lease provides the required control, but the implementation is still missing.

It was also decided against on evidence. Beam racing attacks the emulator's own frame production, not the compositor's scanout, which is why it lives inside MAME and inside WinUAE rather than in a window system. The measurement settled it: what remains between a commit and the glass is 0.23 of a frame, and half of what remains between a button and the glass is the wait for the next vblank that nobody can remove.

11Beside the others, and where that leaves it

There is a well-populated world of Linux retrogaming on CRTs, and most of it is older, more complete and better tested than this.

If you are willing to dedicate a machine, use GroovyArcade or Batocera. They are mature, they have communities, and they solve the problem completely.

If you want the most faithful hardware behaviour money can buy, use a MiSTer. Its own documentation puts its scaler at four display lines in its fastest mode, about a third of a millisecond, on top of a core that is the console's own timing.²⁵ A MiSTer is faster than this and always will be, because there is no operating system in it.

Flyback’s numbers were measured with the instrument in the repository. Figures for other systems come from their documentation; I have not measured those systems on this hardware.

Flyback is the only row that is a component: no frontend, no game database, no installer, no community. The last column describes the intended use of each setup. Every other row answers _"how do I build a machine for a CRT?"_; this one answers _"how does a machine I already have grow a CRT?"_

Where Switchres is better than what is here: it computes a modeline per game from a monitor preset, across 15, 25 and 31 kHz and dozens of documented arcade monitor types. This project ships five modelines and picks between them: years of accumulated work, and if per-game timings are ever needed the sensible path is to use Switchres rather than rewrite it.

Flyback is intended for a PC that remains in use as a desktop while driving a 15 kHz television. It controls one leased output and schedules the clients running on it.

It remains experimental and has only been tested on the setup listed above. The instrument and sample data are available for repeating the measurements on another set.

I asked Claude: _"un logo per Flyback compositor con /design dai un brief adeguato"_. I wanted a logo for the compositor and asked the agent to develop the brief. The repository already contained the project context and the geometry of OmaCRT’s mark, which the new logo needed to share.

01Starting from the existing mark

OmaCRT’s mark has four bars crossed by a dark cut representing the beam’s return between lines. Its geometry is defined by a struct, with the reasoning in the comment above it:

pub const RETRACE: Retrace = Retrace {
    grid: 44, bars: 4, thick: 8, gap: 4, cut: 12, minseg: 3, rest: -2,
};

The grid is forty four units square. The bars are eight units thick, with four units between them. A twelve-unit cut steps once per bar to form a 45-degree edge. The accompanying note explains why five bars become unreadable at 24 pixels; the shape needs to survive scaling without a separate small-size version.

The agent read those constraints first. They gave it a grid and a set of proportions for the new mark.

OmaCRT’s cut moves down and to the left. Flyback’s ramp steps down and to the right. Both use the same grid.

02Three directions, each with the case against it

The name suggested the subject. Flyback is what a television’s deflection does between two lines: the current ramps across the screen, then collapses back in almost no time. The transformer named after it is the part tuned for one line rate and no other.

The agent proposed three directions: a whole raster with a staircase cut through it; a raster caught mid scan, with the last bar stopping a third of the way across; and a deflection waveform, with four bars stepping out beside a full height return stroke.

Each proposal included a For and an Against. The drawback listed for the version I chose was:

the least literal of the three; someone who has never seen a deflection waveform reads it as an abstract monogram, not as a beam.

I chose C and replied: _"Ok per la C vai avanti"_.

03The refinement was a number

In the sketch the return stroke was six units wide. In the finished mark it is eight, the same weight as a bar.

The return stroke represents the same beam travelling about a hundred times faster. Giving it the same weight as the bars makes that relationship visible. At six units it introduced a second weight into the eight-thick, four-apart rhythm, which was especially noticeable at small sizes.

The construction uses these dimensions:

The same SVG rendered at 176, 64, 32, 24 and 16 pixels:

These dimensions also give future variations a consistent starting point.

04Drawing for a 240-line screen

The mark has to be drawable by an electron beam on 240 scan lines, because this project's marks appear on the television it drives. That is why there are no diagonals, no hairlines and no fractional units anywhere in the system.

The display constraint informed the grid and stroke weight.

05The first critique, and the seventeen pixels

When I looked at the logo and text together, the second line seemed misaligned and its contrast was too low. I asked the agent to address both.

In a monospaced font, each glyph occupies the same advance width, but the space before its visible ink can differ. That space is its left side bearing. A capital F at 230 px carries 18 px of bearing, and a capital W at 52 px carries 1. Set to the same x coordinate, the two lines are aligned on their origins and misaligned on their ink by seventeen pixels. The smaller line's ink hangs out to the left, exactly what the eye was seeing.

The agent aligned the visible ink, then cropped and trimmed both text bands to check the result. Both started at column 442. It also increased the contrast of the second line while keeping it less prominent than the wordmark.

The agent also found a third problem: the descender of the _y_ in Flyback ran into the second line’s cap height. It moved the word up 16 px and the second line down 16 px, keeping the block centred on the mark.

06The second critique, and a measurement that was wrong

In the next version, _Wayland compositor_ still did not line up with the mark. I suggested aligning it with the bottom bar.

The agent measured the wordmark’s ink at rows 92 to 301 and the second line at 317 to 356, both starting at column 442. It measured the bottom bar at rows 352 to 391 and reported a height of 39 px. Since it also reported the second line as 39 px tall, it proposed moving the line down 35 px to align the two bands.

The bar measurement was wrong. The agent had cropped across its full width, including columns occupied by the bars above it. Measuring only the part where the last bar is isolated gives rows 331 to 391, 61 px. The two reported heights of 39 px did not establish an alignment.

Moving the line still made sense. Its band, 317 to 356, crossed the bar’s band, 331 to 391, about a quarter of the way down, without aligning to either edge. The revision aligned the text baseline with the bar’s bottom edge: second line ink at 352 to 391, bar at 331 to 391.

The agent had predicted that moving the line down 35 px would leave a 51 px gap under the wordmark. The wordmark could now move back down the 16 px added earlier, since the second line was 35 px further away. The final file measures:

The second round exposed a limit of the process: a plausible alignment proposal had been supported by an incorrect measurement. Checking the crop changed the explanation and preserved the intended alignment.

07The rules, and four ways to get them wrong

The specification has three sheets: construction; colour, clear space and misuse; and the two marks with their wordmarks. The misuse sheet shows four changes to avoid: rotation, gradients, outlines and five bars instead of four.

Clear space is four units, the gap between the bars again.

The four colour combinations have these measured contrast ratios: Phosphor green on the near black the launcher uses, at 10.6 to one. The paper colour on the same ground, at 12.0. The dark ink on paper, at 16.2, the one print and a light theme get. And the mark knocked out of the green, the same 10.6 the other way round.

The green is a mark colour with one ground. On white it measures 1.8 to one, too little contrast for this use, so a light theme gets the dark ink. There is a second file for that, flyback-mark-mono.svg, which takes currentColor and lets the page decide.

08What it does not show

The agent wrote the SVG as rectangles on a 44 unit grid. No image generator was used.

I reviewed four versions on a canvas on my phone: the three directions, the refined mark and its rules, the first corrections, and the final alignment. The repository contains the working files, including the two unused directions.

The existing geometry gave the agent a useful constraint. It could propose related marks, render them at different sizes and document their construction in the same repository.

That does not make the choice of mark an arithmetic result. All three proposals used the deflection waveform as their subject; a different designer could have explored other ideas. I chose which direction to develop and judged the revisions visually.

The brief, proposals, specification, assets and two feedback rounds took an afternoon. The measurements helped refine the result, but they also needed checking.

Driving it requires a signal timed to the movement of that spot.

01The beam

At the back of the neck is a cathode, heated to about 800 degrees, with a coating that gives up electrons easily when it is hot. Around it sit a stack of metal grids at different voltages. The first one is the important one: make it more negative and fewer electrons get past it, make it less negative and more do. That grid is where the picture signal goes. A line of video is a voltage on it, changing a few million times a second. What this set resolves is nearer four to six megahertz, measured on the chain rather than assumed.

The rest of the grids focus what gets through into a beam a fraction of a millimetre across. The coating on the inside of the funnel, held at twenty odd kilovolts, then accelerates it the length of the tube. The electrons leave the gun slowly and arrive fast. That is why the glass at the front has to be thick, and why a tube of any size is heavy.

02Bending it

The beam would land in the middle of the screen and stay there. What moves it is the yoke: two pairs of coils clamped around the neck, one pair bending it left and right, the other pulling it down the screen.

The horizontal pair determines the line rate this project must respect. To draw a line, the current through those coils ramps from one end to the other and then collapses back. That has to happen 15,731 times a second on this set. A coil resists a change in the current through it, so what drives it is a tuned circuit instead of a plain amplifier, built to resonate at one frequency with the coil's own inductance as part of the tuning.

This tuned circuit limits the frequencies a television can accept. Sending a different timing asks the deflection hardware to operate outside the conditions it was built for.

03The flyback

At the end of every line the current in the horizontal coils is at one extreme and has to get back to the other. It is not eased back. The drive is cut, the circuit is allowed to swing, and the beam is flung back across the screen in 4.7 microseconds, against the 48.9 it spent crossing. About a tenth of the time, going the other way.

Blanking and retrace are not the same thing. A line on this project's television is 63.6 microseconds long and only 48.9 of them carry picture. The other 14.7 are blanking, and the beam is not flying back for all of it. A front porch of 2.4 microseconds holds the beam off and still at the right. Then the sync pulse of 4.7, where it actually flies back. Then a back porch of 7.6, where it is off, at the left, and waiting.

The retrace is the sync pulse. The porches are the set being given time to settle and to clamp its black level, and a signal that skips them is one a television will not lock to.

That swing is a large, fast change of current in a coil, producing a large voltage across it. The transformer wound around the same core steps up that voltage, which is then rectified to supply the anode’s twenty odd kilovolts. One component draws the picture sideways and supplies the accelerating voltage, out of the same collapse, once a line.

That return motion gives the flyback transformer its name. I used the same name for this project’s compositor.

Switch the model on above and slow it to one line a second. The sweep is the part where the picture is, the flick back to the left is the flyback, and the two pauses either side of it are the porches. The same thing happens at the bottom of the frame, more slowly: 22 blanked lines, 1.4 milliseconds, to get the beam back to the top.

04The screen

The inside of the faceplate is coated in a phosphor. An electron lands, gives up its energy, and the coating emits light for a few milliseconds and then stops.

The tube has no frame buffer, scaler or panel timing controller. At any instant, the viewer sees the bright spot and the fading glow of the lines it has just drawn. The picture is an artefact of persistence, partly in the phosphor and partly in the eye.

This matters to the Flyback study, which measures latency up to the start of scanout. A flat panel can buffer the frame after that point. The CRT draws from the incoming signal; the study discusses the remaining unmeasured delay through the converter and phosphor.

05Why 15 kHz and not 31

A computer monitor of the same era runs its line rate at 31.5 kHz or higher, and draws 480 or more lines progressively. A television runs at 15.7 and draws 240 lines in a field.

The number is what a broadcast standard settled on in the 1940s with the parts available then, and everything downstream inherited it: the yoke's inductance, the transformer's core, the capacitor tuned with it.

Send a set built for 15.7 kHz a signal at 31.5, and the horizontal output transistor is switched twice as often as it was designed for, into a circuit that is no longer resonant at the driving frequency. The transistor dissipates what it cannot pass on.

Flyback checks timings before passing them to the kernel, to avoid driving that circuit outside the configured frequency range.

The response depends on the set. Some lose sync, blank or shut down; others have little protection. This project has not tested out-of-range signals on a television.

06What the model above does not have

The model simplifies or omits four components.

The shadow mask or aperture grille sits just behind the phosphor on a colour set. It makes sure the beam for one colour can only land on that colour's phosphor. A colour tube is dim next to a monochrome one for that reason. Drawing it needs three guns.

Convergence is the business of making three beams land in the same place at the corners as well as in the middle, the fiddliest thing about a colour tube. One beam has no convergence problem.

The degauss coil is the loop around the front of the tube that fires for a second at switch-on to demagnetise the mask, and it does nothing a model can show.

And the high voltage supply is drawn as one component here. On a real chassis it is a multiplier, a regulator and a focus divider, all of it hanging off the flyback.

07The imperfections were the medium

For about twenty five years, game artists and programmers worked with these display characteristics. Some effects depended on the tube; others depended on the composite signal used to reach it.

There is no grid of pixels. The spot is a fuzzy round thing with a brightness that falls off from the middle, and it does not aim at a particular phosphor: whatever timing arrives is native, and there is nothing to resample onto anything.¹ A modern panel has a fixed number of cells and a scaler in front of them, so a 240 line picture is 240 lines interpolated onto a thousand and something. Here it is 240 lines.

It is an impulse and not a hold. A panel lights a frame and keeps it lit until the next one. A tube flashes a line and lets it die. The blur you see when something moves across a flat panel comes from that holding rather than from the refresh rate. It is why panels sold for games strobe their backlight or insert black frames, which imitates a tube.²

The tube emits light as the signal is scanned out. The Flyback study uses this relationship to interpret its software measurements, while distinguishing them from an optical latency measurement.

Bright spots spread into neighbouring areas, softening edges. Artists could account for that when drawing sprites and backgrounds.

What that was worth to somebody drawing | what it was worth

Colour, out of timing. The Apple II has no colour hardware. Wozniak clocked its black and white dot stream at a multiple of the television's colour subcarrier, so certain alternations of on and off arrive at the decoder as colour. Two pixels give purple or green depending on the phase, and the eighth bit of every byte delays the clock by half a cycle to give blue and orange as well.³

The IBM PC’s CGA uses the same effect on the same pixel clock.⁴ These colours arise when the television decodes the deliberately timed signal.

Transparency, out of a narrow channel. Composite video carries colour on a channel narrower than the one it carries brightness on, so two colours in alternating columns arrive averaged into one. The waterfalls in the first _Sonic the Hedgehog_ are a checkerboard of one blue over the rock behind it, and on the screen they were drawn for they are water.⁵ An RGB connection preserves that checkerboard, as does emulation without composite filtering.⁶

A program with no picture in it. The Atari 2600 has no frame buffer at all. There are 76 processor cycles in a line, and the program spends them changing the video chip's registers while the beam moves across the screen.⁷ Miss the timing and there is no picture at all. The beam is not where the program's output goes; the beam is the program's clock.⁸

The frame taken off. The Commodore 64's video chip decides to draw its border by comparing where it has got to against where the picture ends. Switch the machine to a shorter screen at exactly the right moment and it never starts, so the border is not there any more. On the sides it has to be done inside every line, to the cycle.⁹ Programmers used the timing of that comparison to keep the border open.

A gun that sees the beam. A light gun does not know where it is pointing. The console blanks the screen and flashes one target at a time while the gun reports whether it can see light, and the gun's filter is tuned to the fifteen kilohertz flicker of the beam itself.¹⁰ It works because the picture is being drawn rather than held, and it stopped working when screens stopped drawing: there is nothing at fifteen kilohertz on a panel to see.¹¹

These techniques used properties of the original display and video signal, which helps explain why the same image can look different on another screen.

08What this has to do with a compositor

These properties inform three parts of Flyback’s design.

The refusal guard. The tuned horizontal circuit needs a line rate within its supported band. Flyback checks the timing before sending it to the kernel: the line rate inside the band the configuration allows for that set, 15 to 16.5 kHz as shipped, the field rate between 40 and 90 Hz, and every timing in order.

The variable refresh rate. The horizontal rate must not move and the vertical one can. The vertical oscillator re-triggers on sync, so a longer frame is simply a longer wait before the beam is sent back to the top. The refresh rate can change without the mode changing, and it stops at about 55 Hz on this set, which is where the picture starts losing height.

The latency. The compositor controls when a frame starts scanning out. The study measures from a client’s commit to the start of scanout. It does not measure the converter’s delay or the time until light reaches the viewer.