hardware · xteink x4 pro
Xteink X4 Pro, the reader we now build against
ExplorInk runs on the X4 Pro as of 9 September 2026, and there is a firmware download for it. It is a different chip from the X4, so it is a second binary and a second install. We made it the reference device for one reason: it has a frontlight and the plain X4 does not, and a map you cannot read after dusk is a map you stop carrying. This page is what the device is, what we measured on our own unit, and the four things the first hardware pass did not answer.
What the device is
The X4 Pro is Xteink’s 4.3″ e-ink reader on an ESP32-S3. It keeps the page turn button on each side, adds a capacitive home button in the middle of the front face, a touch layer over the panel, and a frontlight with separate warm and cool channels. It loses the plain X4’s bottom button row and its USB-C socket.
- Panel
- 800×480 native, which the renderer drives as 480×800 portrait
- Controller
- UC8279 on our unit, read off the bus at boot. Not fixed across the batch, see below
- Frontlight
- two channels, warm and cool, PWM brightness
- Touch
- GT911 digitizer, plus a capacitive home key
- SoC
- ESP32-S3 rev v0.2, dual core at 240 MHz, WiFi and Bluetooth 5 LE
- Memory
- 8 MB embedded PSRAM, 16 MB flash
- Storage
- microSD on the top edge, for map tiles
- USB
- no socket. Data comes out on the pogo pins, through the dongle in the box
Chip, memory, flash and USB were read off our own unit over the cable. Panel geometry comes from the stock firmware image on the device. Battery capacity, weight and price are the vendor’s and a reviewer’s numbers, and we have measured none of them.
The panel controller is not the same on every unit
The board identifier baked into Xteink’s own firmware names an SSD1677. Our unit is a UC8279. The e-ink SDK we build on notes that every X4 Pro benched before ours carried a UC8179. That is three answers for one product name, so the firmware does not pick one: at boot it talks to the panel, asks what it is, and loads the matching driver. All three are compiled into the image.
This mattered on the first flash. The probe used to run only on the C3 readers, so on this device the firmware wrote SSD1677 commands at a UC8279, which ignored them without complaining. The panel kept the last picture the stock firmware had left on it and everything in the log looked healthy. One line of code, and the same build drew.
What we measured on it
All of this is off one unit on 9 September 2026, on the build that is now published.
| What | Number |
|---|---|
| Panel refresh | 488 ms fast, 1,344 ms clean whole-panel |
| Map render | 1,183 ms for a frame, 1,192 ms to a finished framebuffer |
| What that frame held | 2 tiles, 2,153 ways, 542,818 bytes off the card |
| Free heap with the map up | 172,216 bytes, largest single block 131,060 |
| Heap cost of loading the tiles | 96 bytes |
| Frontlight at brightness 50 | cool duty 162, warm duty 163, split by one call |
The heap number is the one worth pausing on. Every memory rule this project has was written for the ESP32-C3, where the map screen leaves about 58 kB free. Here it leaves 172 kB, and that is before anything uses the 8 MB of PSRAM. What the map is allowed to hold on this device is an open question with a lot of room in it.
Touch, on a firmware built for buttons
Our map screen was designed for gloves and physical buttons, and that premise does not change here. What touch adds on this device is a way to get it wrong: a reader riding in a tank bag taps itself. So the home key takes a double tap to lock the touch layer, and a second double tap to let it go. The physical page turn buttons keep working while it is locked, because the lock is a policy about touch and those buttons are wired straight to the chip.
Confirmed by hand on the device: the second double tap releases, the hint boxes give way to a lock glyph, a single tap does nothing while locked, and the zoom keys still step through the levels.
What the first pass did not answer
The device boots, draws and takes input. Four things were not settled, and none of them is written down anywhere else as finished.
- The frontlight at boot. Startup sets a brightness and then turns the light off, both inside the same millisecond. Whether that is a visible flash on a warm-plus-cool panel is not what anyone was watching.
- Turning touch off from the settings menu. The double tap lock is recoverable. The stored setting is a different path and it has no way back yet, so it is not safe to use.
- The frontlight PWM frequency. Our override is keyed to a different board, so this one runs the SDK default, and that default is on the SDK’s own pending list.
- Heap over a long session. One map frame is one sample.
Two more, from outside the pass: battery drain with the frontlight on, which early units had badly enough for reviewers to say so, and whether an X4 Pro can ship with flashing locked the way some marketplace X4 units do. Ours is not locked. That is one device.
Where it sits next to the others
The plain X4 is where every number on this site came from until now, and it was discontinued in August 2026. The X3 shares the X4’s chip and binary. The X4 Pro is the only reader we own with a light behind the glass, which is why it is the one we design against now. The hardware page has the comparison, the X4 findings have the older numbers, and the install page has the download and the cable you need for it.