Following up on my testing of the LattePanda Mu and IOTA, this time I’m looking at the Sigma, which (as is becoming the norm with my recent pieces) I actually got before summer break.

I wanted to have a look at it because it is something else again in the LattePanda universe: consider a laptop-class Intel motherboard with the case, keyboard, and display removed, but with more accessible I/O than most mini-PCs, and you’re close enough:

And it doesn’t stop at I/O: the Sigma I’ve been testing has a Core i5-1340P and 32 GB of soldered LPDDR5 (which is probably worth its price in gold right now), making it probably the most powerful “single board computer” I’ve ever used.

Disclaimer: DFRobot was, again, kind enough to send me a Sigma free of charge, and as usual, this article follows my review policy.

Even though I generally prefer ARM and AMD for that, there is a lot of Intel hardware in industrial manufacturing, and I see i5 factory floor machines starting to crop up as replacements for older generations already.

But besides summer break, one of the reasons this post is a tad long is that I took a, well… long look at how to use the Xe iGPU for inference, because I realized llama.cpp has an absurdly large range of techniques baked into it that are a cut above what I have on go-pherence–and why not learn from that?

At 146x102mm, the Sigma is quite a bit larger than the IOTA and the Mu Lite Carrier and feels much more like an industrial motherboard than a hobbyist SBC.

The board is built around Intel’s Core i5-1340P, which was originally meant as a mobile CPU (hence its 28W rating), but LattePanda designed the cooler for a sustained 44W configuration, and that is definitely the first thing you’ll notice when you pick it up:

I must say that having the whole thing bolted to an aluminium slab actually made it quite nice to test, since I didn’t have to worry about getting loose screws or other parts under it.

Removing the aluminium base reveals the mainboard and its components quite clearly, in a very neat layout:

And yet, there is a lot going on here that is not immediately obvious from the outside or underside:

• Core i5-1340P, with 4 P-cores, 8 E-cores, 16 threads and 12 MB cache
• 32 GB LPDDR5-6400, shared with the Iris Xe GPU–one of the things I really like about this board.
• two M.2 M-key slots, one PCIe 4.0 x4 and one PCIe 3.0 x4
• two 2.5GbE ports (based on Intel I226-V)
• two Thunderbolt 4 ports, as well as HDMI 2.1 and eDP 1.4b
• an M.2 E-key for Wi-Fi/Bluetooth and an additional B-key slot with SATA, PCIe, USB and SIM connectivity (you get some nice thermal pads in the box, too)
• SATA, internal USB, front-panel, audio and serial headers
• A barrel jack for 19V power input (the supplied PSU is rated for 90W, which is plenty of headroom, as we’ll see)
• and, finally, an onboard ATmega32U4-compatible LattePanda Leonardo for GPIO, PWM, analogue input, UART, I2C and SPI (which I didn’t test beyond the hello world check below)

This is also a slightly beefier i5 than I’ve seen before–as an example, compared with the i5-1235U in the TerraMaster F4-424 Max, the i5-1340P adds 2 extra P-cores and 4 threads, keeping the 80 execution units in the Xe graphics unit.

For my tests, I dug out a 1 TB WD Blue drive and an Intel AX210 Wi-Fi 6E/Bluetooth module.

The latter worked so well that I ended up freeing the Ethernet ports and just letting the Sigma work wirelessly (at a link rate of 1.2Gbps), but that is why you can see the Bluetooth device in what otherwise is a pretty sparse USB inventory:

# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 3343:803a Unknown LattePanda Leonardo
Bus 003 Device 003: ID 8087:0032 Intel Corp. AX210 Bluetooth
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

And yes, there’s a Leonardo in the USB inventory.

This mix of standard Intel devices and a small onboard microcontroller is still one of LattePanda’s better ideas, and makes it appealing for industrial devices: the host can run an ordinary operating system while the microcontroller handles timing-sensitive tasks and GPIO independently.

As to the PCI bus, I would call it… unashamedly Intel?

# lspci
00:02.0 VGA compatible controller: Intel Corporation Raptor Lake-P Iris Xe Graphics
01:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V
02:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V
03:00.0 Network controller: Intel Corporation Wi-Fi 6E AX210/AX1675 2x2
58:00.0 Non-Volatile memory controller: Sandisk Corp WD Blue SN580 NVMe SSD

I didn’t use the SATA interface for testing, and the WD Blue SN580 I used through the PCIe 4.0 M-key slot behaved as expected, but for the sake of thoroughness, I still wanted to document its performance here using fio benchmarks:

Nothing unexpected here. I didn’t do a test across more than one slot (NVMes are too precious to wear down on purpose these days), so these figures are for the PCIe 4.0 slot only.

Both I226-V interfaces use igc and advertise 10/100/1000/2500Mbit/s modes, and I had zero issues saturating the links during my tests. By now, 2.5GbE is just rock solid for most local network tasks, the Intel implementation is reliable, and I wouldn’t hesitate to rely on it for demanding workloads. The only reason I switched to my own Wi-Fi 6E card was because it was a bit more convenient and I could get possible fan noise further away from my desk while I tested thermals.

And speaking of that, as you may have seen from the box shot, the board is dominated by its large heatsink and cooling assembly, which covers the CPU and other critical components:

The only criticism I have of the design is that the slight slope on the heatsink (seen above on the left side of the photo) might make it a bit tricky to design a case that fits snugly (or connects the exhaust to the outside, like I did for the Mu) and has the potential to turn into a dust trap over time, but otherwise the cooling solution appears very effective indeed.

Neither sensors nor /sys/class/thermal worked as I expected at first, but turbostat could read the processor MSRs and supplied package/core temperatures, effective frequency, package power and hardware throttle counters. But after yelling at rpm-ostree for a bit, I got some very usable temperature data anyway:

# sensors
wlwifi_1-virtual-0
Adapter: Virtual device
temp1:        +39.0°C

lattepanda_sigma_ec-isa-0000
Adapter: ISA adapter
CPU Fan:     1497 RPM
Board Temp:   +36.0°C
CPU Temp:     +43.0°C

acpitz-acpi-0
Adapter: ACPI interface
temp1:        +27.8°C

coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +41.0°C  (high = +100.0°C, crit = +100.0°C)
Core 0:        +34.0°C  (high = +100.0°C, crit = +100.0°C)
Core 4:        +36.0°C  (high = +100.0°C, crit = +100.0°C)
Core 8:        +37.0°C  (high = +100.0°C, crit = +100.0°C)
Core 12:       +35.0°C  (high = +100.0°C, crit = +100.0°C)
Core 16:       +39.0°C  (high = +100.0°C, crit = +100.0°C)
Core 17:       +39.0°C  (high = +100.0°C, crit = +100.0°C)
Core 18:       +39.0°C  (high = +100.0°C, crit = +100.0°C)
Core 19:       +39.0°C  (high = +100.0°C, crit = +100.0°C)
Core 20:       +39.0°C  (high = +100.0°C, crit = +100.0°C)
Core 21:       +39.0°C  (high = +100.0°C, crit = +100.0°C)
Core 22:       +39.0°C  (high = +100.0°C, crit = +100.0°C)
Core 23:       +39.0°C  (high = +100.0°C, crit = +100.0°C)

nvme-pci-5800
Adapter: PCI adapter
Composite:    +34.9°C  (low  = -40.1°C, high = +83.8°C)
                       (crit = +87.8°C)
Sensor 1:     +45.9°C  (low  = -273.1°C, high = +65261.8°C)
Sensor 2:     +34.9°C  (low  = -273.1°C, high = +65261.8°C)

This was something I wanted to check because the fan was not inaudible (worst case was a persistent whooshing noise, with zero whine), but quiet enough at times for me to wonder if it was on. There’s no stall sensor, apparently, so you can’t directly detect if the fan is stuck or not spinning, but you can still monitor its RPM–and the reason I care about it is that fan monitoring is useful in industrial environments to detect fan failures.

Sustained Load

While doing benchmarks I left intel_pstate, the powersave governor and firmware power limits unchanged, and collected turbostat samples every two seconds through a set of CPU, memory, storage and media runs. And since I did everything in sequence with minimal (but realistic) cooldown periods between runs, the resulting data was so nice that I decided to keep it all in one chart:

Low-power operation is amazingly good–the system idles at 39.5C and 2.0W package power, jumping up to 54C and 19.1W (and back down) as needed. During sustained 7-Zip, package temperature averaged 81.3C and peaked at 89C, with power averaging 33.5W and peaking at 39.2W.

At the wall, I measured roughly 44.0W max consumption (including the rest of the system, of course, which the CPU telemetry doesn’t account for).

But (and another reason why I find newer Intel silicon so impressive, and am hoping to look at the Ultra series next), I was actually surprised there was no real throttling. On an i5, which typically would start throttling under sustained load at high temperatures.

Yes, there was a plateau (3.72GHz, give or take), but neither the core nor package hardware throttle counter changed during the entire sweep, and no kernel thermal warnings appeared.

Since the Sigma fits a rather broad range of applications between a personal workstation and a beefy low-power server, I started with the workstation part (by installing Fedora, where I did most of my testing) and, later on, popped in a second SSD with Proxmox to try it out both as a Debian box and as a server.

As you’d expect, both Fedora and Proxmox were completely uneventful to set up, but each is worth a few notes.

Back in June, I landed on Fedora Silverblue 44 with kernel 7.1.5, which had full support for everything: the Iris Xe uses i915, both I226-V Ethernet controllers use igc, and the CPU runs under intel_pstate. But, more importantly, I got a completely stable Vulkan stack for my compute experiments.

There were no vendor kernels, board-specific image builders or mystery boot partitions involved, so the contrast with the ARM boards I keep testing is almost comical.

And yes, Thunderbolt worked fine too, as did the Leonardo when I did a little hello world test–but I did not test them thoroughly yet.

This was by far the easiest installation, because, well, I cheated.

I had previously installed Proxmox on the IOTA for testing before using its internal eMMC instead, so I just popped that SSD into the Sigma (with a 3D-printed jig to hold the half-length board in place) and, as you’d expect, everything worked perfectly.

With 32GB RAM, two extra P-cores and dual 2.5GbE, this is a really good home server, especially considering the power envelope, so it was a no-brainer to temporarily migrate over a few of the things I am running on the Terraserver:

• My Gitea instance and two of the CI/CD workers (the other two run on borg, on-demand)
• The main piclaw development instance, which is constantly rebuilding itself
• The test Jellyfin LXC I have been using to develop jellyfin-livetube, which, despite not having local access to the ZFS video storage, performed just as well over Wi-Fi 6 (it is, after all, using a nearly identical Intel Xe chipset, and the network overhead is minimal).
• The test instance for wrdp, which also had zero issues serving Wayland desktops using H.264 acceleration.

This deserves a little more digging into, since VA-API can be fiddly to set up, and getting it to work correctly with Fedora’s media packages when I booted back into it required some tweaks.

In the initial test installation, Fedora’s default ffmpeg-free build disabled the native H.264 and HEVC decoders, so hardware acceleration was effectively unavailable–no H.264, HEVC or even AV1 in sight.

Debian (in the Jellyfin LXC container inside Proxmox) “just worked”, which was annoying, so I went back to the all-Fedora setup and got H.264 acceleration working using rpm-fusion.

All around, transcoding 4K content was smooth and didn’t tax the CPU significantly (depending on the particular codec combo, of course, since audio tends to be piped through the CPU). Multiple streams weren’t an issue, either.

In fact, I am currently using the Sigma as my reference machine to develop my wrdp and go-264 projects since it is already proving to be a very capable platform for media acceleration and transcoding tasks.

One of the quirks of the Sigma is that the i5-1340P has four performance cores with Hyper-Threading and eight efficiency cores without it–that’s 12 physical cores, not 16 equivalent ones. The E-cores are useful, but doubling the thread count doesn’t mean doubling the available compute: first you’re adding SMT threads to the same P-cores, then you’re bringing in a different class of core altogether.

7-Zip makes good use of the extra threads, but the “linear” scaling you’d hope for isn’t quite there.

Going from four P-core threads to eight with SMT raises the total rating by only 36%, not 100%.

Adding the eight E-cores brings another 60%, so even though all 16 threads deliver the best result, they only manage about 2.2 times the throughput of four physical P-cores, despite having four times the thread count.

That’s useful extra performance, but it isn’t proportional scaling–and neither SMT threads nor E-cores truly replace physical P-cores. But for background workloads like what you’d have on a server or during heavy multitasking, the extra threads can still be beneficial.

As to RAM speed, the Sigma’s LPDDR5-6400 does not disappoint.

I pulled out a little memory bandwidth testing to see how the Sigma handles sustained data transfers–not just the peak theoretical numbers, but what it can actually deliver under load. After futzing around a bit, I hit upon a simple STREAM-style benchmark that uses three 256MiB arrays: Copy transfers data from one array to another, while Triad multiplies values from one array by a constant, adds values from a second, and writes the results to a third. The GB/s figures count the data read and written per second, showing the sustained memory bandwidth the CPU can actually achieve:

Four P-cores already saturate the best copy result, so adding more threads doesn’t help much there. The E-cores add around 9% to the best Triad result (probably because they will lean heavily on cache), and it plateaus after that–but it’s nothing to sneeze at.

The upside is that, in practice, the CPU and Iris Xe share this 52-58GB/s pool–there is no separate GPU memory bottleneck, or a need to bucket data across a slow bus.

This is, as usual, where I went totally overboard.

Update: I have tidied up all the tests I did (many of which did not make it into this review, since they were exploratory) into this set of documentation in my private llama.cpp fork, so if you want to reproduce any of this or look into the post-review iGPU work, this is where you will find it.

Based on older experiments on the TerraMaster, I was expecting quite low performance (around 3 tokens/s by default), but I have been tweaking my own fork of llama.cpp, so I had piclaw rebuild it with Clang 22, -march=native, AVX2 and AVX-VNNI support to take advantage of the new CPU features.

Then I downloaded the cool models du jour (Gemma 4, Qwen 3.6 and Ornith–a biased Qwen derivative) and set up a little agentic test suite: Each candidate got the same repository-search agent task (sized to fit under 4K tokens), which prompted the model to do at least one tool call (which when successful was under 200 tokens):

This is effectively one-shotting a 4K context, and, overall, I can’t complain about the Sigma for this kind of workload:

Gemma 4 E4B was the obvious winner (as it tends to be in low-resource scenarios), and its performance advantage was clear both in prefill and generation throughput–but, most importantly, it can do tool calls right, which is not something every model can do (even though the other two did fine, Gemma is a bit more predictable at that at the expense of actual coding skills).

Ornith ingested prompts faster than Qwen and was slightly faster for short generation, while Qwen caught up somewhat in longer generation scenarios, but they’re fairly evenly matched.

Then I began trying multi-token prediction (MTP) to see if it could improve throughput without sacrificing accuracy. If you’re new to this, MTP uses a draft head (i.e., a smaller “model”) to propose several tokens and lets the target model verify them together. It is not a generic “turbo” switch–the useful depth depends on the model, and more drafting can make things slower, but it can significantly boost throughput when used appropriately.

After a couple of hours of trial and error (and with longer prompts), I arrived at the following results:

Then I started poking at other parameters–including stuff that affects memory usage and computational efficiency, and that doesn’t make sense in CPU-only scenarios. Also, I quickly realized that on this i5, the best way to maximize throughput was to carefully balance the load across the P-core SMT pairs (yes, you can do CPU pinning) without overwhelming the CPU–given what I got from the memory bandwidth tests, that was unsurprising.

But from a user perspective this is still essentially one-shotting prompts, which is cute but not very realistic for agents that need to maintain a large working context over time, so I froze a prompt at about 124K tokens and ran it through Gemma and Ornith in one 131,072-token slot:

This was a lot more interesting, and a trifle hotter than the earlier one-shot tests (fortunately, again, the CPU did not actually throttle):

The thing is, even though Gemma and Ornith handled the large context without crashing, the generation speed dropped significantly as the context grew. Gemma took up less RAM (and sweeping through weights in RAM more efficiently is, ultimately, why it was able to maintain higher throughput), but for coding tasks that require frequent context updates, this is not really a usable speed–consider it the extreme end of what one might tolerate interactively, and yet perfectly good for batch processing or long-form generation where latency is less critical.

This did not go as expected. I’m used to seeing some improvement with GPU offload, especially for prompt ingestion, but the Iris Xe behaved differently, and I’ve yet to pin down exactly why (but I have some theories).

First of all, there are two main ways to do compute on the Iris Xe: using Vulkan for explicit GPU offload, or using SYCL for a more integrated approach with the CPU. And… they are both quirky, and (initially) worse than the CPU:

So I just filed that away for future investigation and tried to squeeze more performance out of the CPU path instead.

When I came back to this in September, I decided to use a trick that works well with discrete GPUs: let Vulkan handle prefill, then stop the GPU worker and hand the cached state over to the CPU for generation with MTP. This was a particularly fun trick to pull on the Sigma, because:

• Vulkan handles the heavy lifting for the initial prefill, which is usually the most computationally expensive part.
• I can just copy across stuff to the CPU in this architecture, without a transfer across PCIe from discrete GPU memory.
• The cached state goes across as a checkpointed snapshot (not zero-copy, sadly, because, well, Vulkan and conversions, etc., so the handoff still takes time).
• Follow-up tool turns with a warm cache stay on the CPU, so they don’t pay for another handoff.

Getting that working with Gemma required fixing two fairly fundamental things in my llama.cpp fork, though: There was a stupid bug (probably mine) that clipped things to 16K entries, and (this was the bit where Astra was useful) I had to make Gemma’s compact sliding-window attention cache transferable, preserving its valid padding and checking the text/token state format so the CPU could resume without processing the whole prompt again.

Watching it re-use N-1 cached tokens in an N-token test was quite satisfying–no need to chew through the whole prompt again. But compared with keeping everything on the CPU, the gain was more noticeable in the complete workflow, not follow-up turns:

And yes, this is not quite a general-purpose speedup: the complete coding workflow took 28.8% less time, but the warm follow-up rounds were 3.4% slower. It helps when there’s a fresh prompt to ingest; once an agent is working from a warm cache, there isn’t an extra turn-by-turn gain here.

I am looking into this further to see if there are ways to generalize the approach or improve the handoff between Vulkan and the CPU, but this is the kind of rabbit hole I can’t really get into these days, so I pivoted to another thing: speech recognition.

Why speech? Well, because that Vulkan/CPU hybrid approach for Gemma got me thinking: Whisper has a much smaller model size and lower computational requirements compared to Gemma, and it might benefit from a similar prefill-and-handoff strategy, potentially allowing for faster speech recognition on the CPU after an initial Vulkan prefill. At least that was the theory.

So far, I don’t have pretty charts because the conversion from Vulkan-prefill to CPU generation is still a pain to do on the fly (even segmenting the audio, etc.), but I got Whisper v3 Large working with that approach at eight times real-time speed on the Sigma already without really optimizing anything and just doing the bulk Vulkan to CPU data conversion repeatedly.

I am now porting that into go-pherence, so I’ll likely update this post once I have repeatable benchmarks.

But the short version is that I can run both Whisper and Gemma simultaneously on the Sigma–which in turn means that this might well be a killer home automation server if you want fast speech recognition and simple, efficient language model processing all in one place.

Of course, not being a Home Assistant person (I rely on Siri and HomeKit, for better or for worse), I can’t really take the next logical steps here, but I do want a local, private speech transcription solution (I would like to clone the Index 01 to a degree), and the Sigma is working quite well for that purpose already.

I’ve since swapped back to the Fedora SSD full time, and have been using the Sigma as a development server for wrdp, go-264, go-pherence, etc. I am thinking of reinstalling Proxmox on the bigger drive and consolidating most of my development there–including migrating quite a few of my other projects from borg to it as well, since even though borg has ample storage and RAM, the Sigma is just quieter and more power-efficient.

The expandability, built-in 32GB of RAM and the i5-1340P’s core count would already make me choose the Sigma over most Intel mini-PCs I’d otherwise consider. But quiet operation and power efficiency are what make me want to keep using it as a development and home server.

For consolidating services into a custom server build or a small 10-inch rack, I’d also much rather start with this board than stack a bunch of mini-PCs. The two M.2 storage slots and SATA connectivity leave room to expand–if you need more SATA ports, you can use the second M.2 slot with an adapter, and Thunderbolt gives you another option for fast storage. I haven’t tested every expansion option (and, like many times before, I wish I had an eGPU setup to try).

Taking a DIY approach, I appreciate the readily accessible I/O and don’t particularly miss the enclosure (though a proper case would certainly make things tidier).

For now, it’s back on Fedora doing development work while I find the time to design a 3D-printed case that suits me–there are some available, but none is quite what I’d like…

The desire to own an Apple Studio Display has probably been hanging over most Mac desktop users since time immemorial (well, since 1998 at least, but most people are more familiar with the “modern” 2022-era look) for two reasons:

• It defines what a desktop Mac display should, ideally, look like–a black-edged, aluminium-backed slab with zero frills and impeccable image quality.
• It has, traditionally, been hilariously expensive along every single dimension, including polishing cloths, until the historic date of August 27^th this year.

And I, too, have always wanted one. But economics and insularity are part of the reason I never got one, although that hasn’t stopped me: I’ve always been curious about what it would be like to use a credible approximation of one, but with a twist: I like taller displays.

And now, I can confirm that this is probably the best single monitor set-up I’ve used for a long while:

Disclaimer: Kuycon supplied me with a P20 free of charge (well, actually two, but that’s part of the story) and this follows my review policy.

Getting here took several months. The first panel flickered, and pressing on a corner of the monitor improved things. I suspected a partially disconnected internal connector, but couldn’t confirm the cause, although I very strongly suspect shipment damage.

I returned the first unit, but the replacement arrived without a stand, so I couldn’t use it for many weeks. And then I went on vacation, and that further delayed things…

I finally set it up (again) on our living room desk (the space I now retire to whenever I’m not working, either due to needing clear separation from work or to my 3D printers making the office too noisy) and have now been using it properly for a few weeks.

And (spoiler) it’s pretty great.

First of all, I’ve always been a fan of the Microsoft Surface Studio–not the computer itself (which was far too feeble), but its screen size and 3:2 aspect ratio. Its 4500x3000 resolution was also exactly the same as the Kuycon P20.

My preference for taller displays goes back a long way–all the way back to the huge, monochrome 4:3 DECstations I used in college, and I still prefer those proportions to the modern 16:9 default that we seem to be saddled with in this age of video consumption.

Second, I’ve been using LG panels and a combo ultrawide and portrait setup at my office desk for quite some time now, largely because ultra-wides, despite their popularity for gaming and video editing, are actually a slow-burning hindrance when researching, writing or coding because of their comparatively limited screen height. I use my portrait display for coding, researching, final page layout stuff, and, increasingly, CAD and 3D modelling.

However, it’s a bit annoying to flip windows to and fro (even with Moom), so when I realised I had a shot at using a subtly taller, better balanced display with what I still think are the right proportions for me, I jumped at the chance.

Why do I care about this so much? Well, for three reasons, two of which are related to my physical health:

• I have high myopia, which makes the vertical space on my displays particularly important since anything off-centre, being invariably distorted by my corrective lenses, requires actual neck movement to view properly–even if my widescreen were curved, I would still have trouble seeing it clearly without moving my head.
• My back and neck have been giving me trouble, so being able to raise the screen to the centre of my visual field matters a lot to me.
• I simply prefer taller displays for productivity, as they allow me to see more content vertically without constantly scrolling.

In order to better convey my point of view on this, I had my “assistant” draw up this comparison:

The rectangles above are drawn to the same physical scale (which took some doing), leaving out bezels and stands.

I’ve also added a couple of insets showing how 4K and 1080p images fit at native 1:1 pixels, rather than the physical sizes of other monitors. You can futz with desktop scaling to change how much content fits and how large the text is, but the panel proportions stay the same–and the comparison makes those much clearer than diagonal sizes alone.

The P20 has a 28.2-inch IPS panel running at 4500x3000 and 60Hz, with a 3:2 aspect ratio (also written as 4.5:3). That gives it about 22% more pixels than my 5120x2160 LG ultra-wide, arranged in a much taller, narrower workspace–and a bit sharper, too.

The monitor and stand come in separate boxes (even though the illustration on the monitor box shows both, the stand is in the box on the right).

Inside the main box, everything’s neatly packed:

Let’s get this out of the way: Yes, this is very heavily based on what we’ve come to consider Apple design language, from the glossy display, thin black bezels and all-aluminium look to the back vents:

And yes, that is part of the reason I was intrigued by the P20 in the first place, and a controversial aspect for some, but what matters is what the hardware can do for you, and how.

Besides the sturdy aluminium stand (which I like the look of, and which allows the P20 to be rotated 90°, if you want), the monitor itself ships with a stylish VESA mounting bracket:

The bracket itself appears to be machined out of a couple of solid plates of aluminium and is well designed in terms of strain relief, but as it happens none of my monitor arms was strong enough to hold the monitor without noticeably straining and drooping (my LGs are, after all, encased in light plastic), so I had to wait for the replacement stand.

The solid aluminium stand holds it steady. It does require some assembly, but nothing overly complicated:

Once the stand arrived, its height adjustment let me put the screen at the centre of my visual field–the top stop is high enough to get it where I want it.

You get 2 HDMI ports, a DisplayPort, and a USB-C port as inputs, plus a USB-C hub with 2 additional ports for peripherals (I plugged a Logitech Brio 4K into one of them) and a headphone jack.

Note that there are no speakers on this monitor (and likely no good place to put them inside the chassis), so you’ll need to rely on external audio solutions.

As you would expect, we plugged everything we could into the monitor to see how it would handle different connections:

• All our Macs (including old Intel ones) worked without any issues.
• Our Windows machines, both Intel and ARM, also had no trouble detecting and using the monitor at full resolution (and HDR where supported, which was the usual hit-and-miss in Windows).
• Our Linux machines also detected and used the monitor without any major issues–I even wrote a Noctalia shell extension for my MiniBook X for managing monitor placement in Niri.
• The iPad Pro worked seamlessly, as discussed in the next section.
• And a Chromebook I tested also worked without any issues (except for resolution limitations due to its ARM hardware).

The only input I was unable to test was DisplayPort, simply because we have zero machines in the house with it–most of the laptops and SBCs I used connected to the monitor’s USB-C input, including those with Thunderbolt ports.

My trusty old Lenovo ThinkPad X1 Yoga had no real trouble driving it at full resolution (albeit at 30Hz) via HDMI. I also tried a few USB-C to HDMI adapters, including one of my trusty travel cables, without any significant issues (other than 4K limitations in some of the converters, which was expected).

To put it bluntly, this thing is glorious to use with my iPad Pro. Completely overkill, but also completely right as far as screen proportions and resolution are concerned, even if Apple still provides essentially zero control over any monitor features other than HDR:

I worked on this draft on the P20 itself using my iPad Pro (Obsidian on the right of the display, references on the left, and Notes on my iPad just below the monitor), and I would make that a habit if it were easier to manage and split windows on iPadOS:

One of my teens, who is just as obsessively attuned to colour as I am, spent an afternoon trying to adjust the P20 to a close match of what our MacBook screens can do and eventually gave up–with or without HDR, our unit had a salmon/pink/warm tint that we just couldn’t get to go away for a while.

I don’t have any colour calibration hardware and I tend to only edit photos on my iPad these days out of sheer convenience (and, let’s face it, due to having given up any pretence at doing “pro” photography over the years), but that tint was something I noticed immediately, even after trying the various DCI-P3 profiles macOS offered in its settings window.

The monitor’s own DCI-P3 and sRGB modes didn’t resolve it either, so we’ve settled on turning off HDR and using its “User” and “Cool” colour settings instead–that and some more judicious tweaking of other settings finally removed the tint, so expect spending some time fiddling with settings on both ends if you’re fussy.

It was impossible to do a true side-by-side with my LG monitors because of plain physics (I don’t have a big enough desk, and swapping one of my monitors for testing the P20 alongside would require me to rewire a bunch of things), but we still haven’t been able to get the colours quite right, in any setup.

HDR mode was… OK, I guess.

But with HDR enabled, I couldn’t adjust the monitor’s colour settings (and the iPad offered no help there, either):

Note that I’ve mostly given up on it on computers both due to the wide variation in colour gamuts and the fact that it only really works for me on the Mac (and even then mostly on internal displays), so none of my machines are set to output HDR–but letting YouTube HDR videos play out at 4K on the P20 while I worked provided some uncanny “this feels like a window” moments, even if some of it was over-saturated until I settled on a colour space I liked.

In my tests, switching to HDR made the desktop look washed out, with muted colours on regular screen elements, and switching back made the difference particularly obvious on the P20. Even on the Mac, some YouTube footage was completely washed out in HDR mode–I couldn’t isolate whether that was down to the content, the software or the monitor.

Feature-wise, the one thing I found myself missing in the P20 was the ability to display two inputs–although it would likely have been pretty awkward in this 4.5:3 aspect ratio, I do use that capability a lot on my LG ultra-wide (to have work and personal machines alongside, in an approximately 4:3 ratio) and on my LG Dual Up (to have my Mac and an SBC, or a TV dongle to watch the news in more troubled times).

I was not a fan of the remote:

My objection is to having another remote at all: it’s the kind of loose end that I invariably end up losing or finding with a dead battery in between the three times I am likely to use it every year (which has been the fate of most non-TV remotes in the house). I already have three of these things for different kinds of portable monitors and gadgets, and those never work reliably.

I’d have much preferred an LG-like five-way switch to another remote to keep track of.

There are no built-in speakers, so if you want audio beyond what your computer or tablet provides, you’ll need separate speakers or headphones.

I didn’t miss them myself–the MacBook, my iPad and the Surface Laptop I was working on all have great speakers, and the only mild annoyance was when any of the machines forgot to keep using its internal speakers.

After all the delays, the P20 has actually been a very good fit for the way I work. I like the height, the resolution and being able to write or research without shuffling windows between two displays, and I particularly like using it with the iPad–so much that it is going to stay on my living room desk (where I retire to focus and write) for the foreseeable future.

And not just for myself, since with college-aged children around, having an extra display in the living room has proven to be extremely useful for everyone in the household–although fights haven’t broken out over it yet.

The colour tint is the only reservation I’d have before recommending it to anyone doing colour-critical work. I don’t have calibration measurements, but both of us could see it, and settling on a cooler preset isn’t the same as correcting it. But we did manage to offset it, so I would rate it as “finicky”.

But for my purposes–writing, coding and everyday use, plus occasional Shapr3D sessions–the proportions are still perfect to my eyes.