Devices

The framework turns each profile into a screen--<keyname> class. The class sets the profile as CSS variables on the Screen element, and everything inside reads them.

On the TRMNL platform you never write this class: the platform renders your layout against each device's own profile. Add it yourself only when you render the screen in your own stack.

--color-depth paints nothing. What a screen prints is decided by its mode class, so a profile rated 24 still renders in grayscale the moment it carries 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 includes both, so their variables come with it.

Keep the size and density classes on the screen anyway: the responsive prefixes and the runtime match those classes. md:value--large matches screen--md, never the device class that includes it. Responsive covers the size grammar.

• screen--sm, screen--md, screen--lg: the breakpoint the device sits at, and the rich text width 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 and needs no class. screen--density-1x exists only as a marker; no CSS rule reads 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 it can print. The palette chosen for a render decides the mode class; the dimensions stay the device's either way.

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 the glass can show, not by the format the image arrives in. These are the four hardware classes and the depth each one takes.

Grayscale ratings stop at 4: past 16 grays the next step is color, so a panel rates 12 or 24 instead of a deeper gray.

A smooth 8-bit image on the wire is a delivery format, not a rating. The panel behind it still prints 16 grays, so 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 registry ships a class. Devices with identical dimensions share one: nine of them resolve to screen--og or screen--ogv2.

The framework ships the platform's device list as generated SCSS. A released build carries a class for every device the platform knows; the framework never invents one.

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.