Devices

A device profile is a named set of geometry and capability values. The framework compiles each one into a screen--<keyname> class, so a screen states its whole device in one class.

The class publishes the profile as CSS variables on the Screen element, and everything inside reads them.

--color-depth paints nothing. The mode class on the screen picks the paint rail, so a profile rated 24 renders in grayscale the moment it wears a grayscale class. See Rendering Modes .

Tokens lists these variables with their defaults, next to every other framework token.

<!-- TRMNL X: 1040x780 CSS pixels at a 1.8 pixel ratio, 16 grays -->
<div class="screen screen--v2 screen--lg screen--density-2x screen--4bit">
  <div class="view view--full">
    <div class="layout">...</div>
  </div>
</div>

Every profile names a size (sm, md, or lg) and a density tier (1x or 2x). The device class inherits both, so it needs no extra classes to get their variables.

The classes still travel on the screen, because they are what the variant prefixes and the runtime match. md:value--large matches screen--md, never the device class that extends it. Responsive covers the size grammar.

• screen--sm, screen--md, screen--lg: the breakpoint the device sits at, and the rich text measure that goes with it.
• screen--density-2x: high-DPI typography, which switches the pixel fonts for Inter Variable. See Font Family .
• Low density is the default, so it has no class. The registry stamps screen--density-1x as a marker, and no bundle defines rules for it.

Pick the size by the devices you want to hit rather than by a pixel count. A profile's own --device-ui-scale and --gap-scale handle the fine tuning inside a size.

A device lists every palette its panel and its delivery pipeline can print. The palette selected for a render decides the mode class; the geometry stays the device's either way.

The two samples below are the same panel at the same dimensions, density, and scale. Only the paint changes. Color Palettes lists the palettes and their classes.

<!-- The gray-16 palette: shades paint as solids -->
<div class="screen screen--amazon_kindle_2024 screen--sm screen--density-2x screen--4bit">...</div>

<!-- The bw palette, same device: shades paint as dither patterns -->
<div class="screen screen--amazon_kindle_2024 screen--sm screen--density-2x screen--1bit">...</div>

Rate a panel by what it drives, not by what the delivery pipeline encodes. These are the four hardware classes and the depth each one takes.

There is no 8-bit or 16-bit grayscale rating. Above 16 grays the axis is color, so a panel goes to 12 or 24 rather than to a deeper gray tier.

A pipeline that sends a smooth 8-bit image is a delivery format, not a rating. The panel behind it still prints 16 grays, and the screen still renders on screen--4bit.

A full-color rating does not lock a device into color. Rate the profile for the glass, then render it with whichever mode class the palette selects.

Every profile in the exported registry ships a class. Some devices reuse another profile's geometry, so they share its class: nine of them resolve to screen--og or screen--ogv2.

The TRMNL Platform exports its device registry, and the framework ships that map as generated SCSS. A released build therefore carries a class for every device the platform knows, and the framework cannot invent one of its own.

Bring your own panel in one of two ways. Apply screen--byod_custom, the generic profile every build ships, or compile the framework with your exact values in $custom-devices.

Custom Devices has the profile schema, the compile-time validation, and what a configured profile generates.

Each entry in the device map compiles into a screen--{name} class with its dimensions, density, and color depth baked in. Configure $custom-devices to produce the same classes for your own panels without touching framework source. See Custom Devices for the profile schema.