Intel Arc 140V on Linux: The Best GPU Control Panel Apps and Driver Setup

If you just got a Lunar Lake laptop and went looking for Intel’s Arc Control app on Linux, you already know: it doesn’t exist. Intel only ships Arc Control for Windows. What Linux users get instead is a community tool called LACT (Linux GPU Configuration and Monitoring Tool), which covers temperature monitoring, power limit adjustments, clock speed readouts, and voltage tracking through a proper GUI. For real-time performance data, intel_gpu_top and nvtop handle the rest from the terminal.

Below: driver setup, LACT installation, CLI monitoring tools, power tuning, and the most common things that go wrong on a fresh install.

Intel Arc 140V and the Lunar Lake Architecture

The Arc 140V is Intel’s integrated GPU in the Core Ultra 200V (Lunar Lake) processor series, launched in late 2024 and still prominent in the 2026 thin-and-light market. It ships with 8 Xe-cores and hardware ray tracing support - specs that put it firmly in competition with AMD’s Radeon 890M from the Strix Point platform.

On paper and in practice, the Arc 140V handles 1080p gaming respectably under Linux. Titles running through Proton typically land between 40-70 fps at medium settings depending on the workload, with heavier open-world games sitting toward the lower end of that range. AV1 hardware encoding and decoding is where it stands out: the dedicated media engine handles 4K AV1 transcoding at real-time speeds with low CPU overhead when the driver stack is configured correctly.

The architectural shift that matters for Linux users is the move away from the traditional i915 kernel driver. Previous Intel integrated graphics (Tiger Lake, Alder Lake, Raptor Lake) all ran on i915. Lunar Lake uses the new xe driver, which was upstreamed into the Linux kernel in version 6.8 but reached production-ready quality for Lunar Lake around kernel 6.12. The xe driver is not a minor update - it’s a full rewrite of the kernel graphics driver with a different memory management model, different firmware interface, and different sysfs layout. Many monitoring tools and power management scripts written for i915 don’t transfer directly.

If your distro is shipping kernel 6.11 or older, you’re going to have a frustrating experience. Kernel 6.12+ is the practical minimum for stable daily driving on Arc 140V hardware.

The Modern Driver Stack: Kernel 6.12+ and Mesa 24.2+

Getting the driver stack right is the foundation everything else builds on. There are three components to check: the kernel driver, the Mesa userspace, and the firmware binaries.

Verifying the xe kernel driver

Run this to confirm the xe driver is loaded:

lsmod | grep xe

You should see output like:

xe                   1234567  0
drm_exec               16384  1 xe
drm_suballoc_helper    16384  1 xe
drm_ttm_helper         16384  2 xe,i915

If you only see i915 and nothing for xe, your kernel is too old or the module isn’t loading. Check your running kernel version with uname -r and verify it’s 6.12 or newer.

To see which driver is managing your GPU device:

cat /sys/bus/pci/devices/*/driver_override 2>/dev/null
ls -la /sys/bus/pci/drivers/xe/

Mesa version check

Mesa provides the Vulkan driver (ANV - Anvil) and OpenGL driver (Iris) for Intel hardware. The 24.2 release included significant optimization work for Xe-core architecture, particularly around pipeline caching and descriptor set handling that matters for gaming workloads.

Check your installed version:

glxinfo -B | grep "OpenGL version"
vulkaninfo --summary | grep driverVersion

On Ubuntu 24.10 and Fedora 41+, Mesa 24.2+ ships in the default repositories. On Ubuntu 24.04 LTS, you’ll need either a PPA or an upgrade path. The kisak-mesa PPA is the standard recommendation for LTS users who need current Mesa without switching distros.

On Arch Linux, Mesa in the extra repository tracks upstream closely, so pacman -Syu is usually sufficient.

Firmware verification with vainfo

Hardware video acceleration on Arc 140V depends on GuC (Graphics microController) and HuC (HEVC/AVC microController) firmware binaries being loaded correctly. Without these, video decoding falls back to software, which burns CPU cycles and kills battery life on media playback.

Install vainfo and run it:

# Debian/Ubuntu
sudo apt install vainfo

# Fedora
sudo dnf install libva-utils

# Arch
sudo pacman -S libva-utils

vainfo

A healthy output looks like:

Trying display: wayland
vainfo: VA-API version: 1.21 (libva 2.21.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 24.x.x
vainfo: Supported profile and entrypoints
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileAV1Profile0            :	VAEntrypointVLD
      VAProfileAV1Profile0            :	VAEntrypointEncSlice

If vainfo errors out or shows no supported profiles, your firmware is missing or outdated. The fix is covered in the troubleshooting section below.

LACT: The Closest Thing to a Linux GPU Control Panel

LACT started as an AMD GPU management tool and expanded Intel support progressively through 2024 and 2025. As of current releases, it handles Arc 140V monitoring and basic power management through a clean GTK interface. It’s not as feature-complete as Windows Arc Control, but it covers the practical needs of most users.

What LACT shows you

Once installed and running, LACT’s main panel covers the basics: real-time GPU temperature with a history graph, core and memory clock speeds, GPU utilization percentage, current power draw in watts, and fan speed (which often shows N/A on laptops since the embedded controller handles fans, not the GPU driver).

Installing LACT

The Flatpak from Flathub is the easiest path and works on any distro:

flatpak install flathub io.github.lact_gui
flatpak run io.github.lact_gui

LACT runs a background daemon (lactd) that needs root privileges to interface with the GPU. The Flatpak handles this through a systemd service that gets activated on install. If the daemon isn’t running, the GUI will open but show no data - check it with:

systemctl status lactd
sudo systemctl start lactd
sudo systemctl enable lactd

On Arch Linux, LACT is in the AUR:

yay -S lact
# or
paru -S lact

On Fedora, it’s available through COPR:

sudo dnf copr enable ilyaz/LACT
sudo dnf install lact

After installation via native packages, enable the daemon the same way as above.

Professional Monitoring with CLI Tools

If you prefer the terminal - or you’re doing performance analysis where you need precise numbers without a GUI overhead - there are three tools worth knowing.

intel_gpu_top

Part of the intel-gpu-tools package, intel_gpu_top gives you a live view of every GPU engine broken down by percentage utilization:

# Install
sudo apt install intel-gpu-tools   # Debian/Ubuntu
sudo dnf install igt-gpu-tools     # Fedora
sudo pacman -S igt-gpu-tools       # Arch

# Run
sudo intel_gpu_top

The output shows separate rows for each engine: Render/3D, Blitter, Video (the media decode/encode engine), and VideoEnhance. This per-engine breakdown makes it easy to diagnose where a workload is hitting limits. If you’re transcoding video and the Render engine sits at 80% while Video sits at 10%, the pipeline is going through software rendering rather than the hardware media engine - a firmware or VA-API configuration problem.

The -s flag sets the sample interval in milliseconds, and -d selects a specific device if you have multiple GPUs:

sudo intel_gpu_top -s 500 -d pci:vendor=8086

nvtop

nvtop presents GPU information in an htop-style interface with per-process GPU usage. This is the tool to run when you want to know which specific application is hammering your GPU:

sudo apt install nvtop    # Debian/Ubuntu
sudo dnf install nvtop    # Fedora
sudo pacman -S nvtop      # Arch

nvtop

The process list at the bottom shows each application consuming GPU resources with its PID, memory allocation, and utilization percentage. Useful scenarios: figuring out whether your browser’s GPU acceleration is working, confirming that a game is actually hitting the GPU, or checking that an AI inference workload (like llama.cpp with Vulkan backend) is properly offloading to hardware.

nvtop gained Intel xe driver support in version 3.1.0. If your distro ships an older version, you may see your Arc 140V listed but with missing or incorrect metrics.

gputop

gputop is a lighter-weight alternative optimized for Intel’s performance monitoring unit (PMU) interface. It gives lower-level metrics that intel_gpu_top doesn’t expose by default, including per-subslice shader utilization and cache hit rates. It’s more relevant for graphics developers debugging shader performance than for general users checking if their laptop is overheating. For most use cases, intel_gpu_top and nvtop are sufficient.

Power Management and Thermal Optimization

Lunar Lake laptops use a unified power budget across CPU and GPU, meaning the PL1/PL2 limits you set affect both. This is worth understanding before you start sliding power limits in LACT.

Adjusting power limits

PL1 is the sustained power limit - the wattage the system can maintain over extended periods. PL2 is the boost limit - allowed for short bursts (typically 10-30 seconds). On a 20W TDP laptop, you might see PL1 at 20W and PL2 at 28W.

In LACT, the Power tab has sliders for both limits. On battery during light work, dropping PL1 to 10-12W cuts power consumption noticeably without making the desktop feel sluggish. When plugged in for gaming, raising PL2 to the maximum the firmware allows lets the GPU hold higher clocks during short burst workloads.

Changes in LACT apply immediately but don’t persist across reboots by default. To make them persistent, LACT has an “Apply on startup” option in settings that writes a systemd override.

Identifying thermal throttling

The Arc 140V in thin laptops frequently hits thermal limits before it hits power limits. When thermal throttling occurs, the GPU drops its clock speed to reduce heat. You can watch for this in intel_gpu_top by monitoring the frequency column while running a load. If the frequency is jumping between 1.8 GHz and 0.9 GHz erratically, the cooling system isn’t keeping up.

To monitor GPU frequency directly:

watch -n 1 "cat /sys/class/drm/card*/gt_cur_freq_mhz"

If you see frequent dips below 50% of the rated boost frequency during sustained gaming, your laptop’s thermal paste or fan curve is the bottleneck, not the power limits. LACT can’t fix a cooling system problem - at that point the options are a cooling pad , undervolt (currently limited on Lunar Lake), or accepting the thermal cap.

Frequency pinning

On discrete Arc GPUs, you can pin the clock to a specific frequency to reduce variance at the cost of power efficiency. On the integrated Arc 140V, this capability is currently restricted by the driver. The xe driver exposes frequency range controls through sysfs (/sys/class/drm/card0/gt/gt0/freq*) but setting a minimum frequency equal to the maximum to force a fixed clock doesn’t work reliably on Lunar Lake as of kernel 6.12. This may improve in future kernel releases.

Troubleshooting and Common Pitfalls

GPU not found / xe driver not loading

If LACT shows no GPU, or intel_gpu_top exits immediately with an error, start by confirming the driver loaded:

lsmod | grep xe
dmesg | grep -i xe | head -40

If xe isn’t in lsmod output, check whether the module exists:

find /lib/modules/$(uname -r) -name "xe.ko*"

If it’s missing entirely, your kernel doesn’t have xe compiled in or as a module. The fix is to upgrade to kernel 6.12+. On Ubuntu 24.04, the HWE kernel track gets you there:

sudo apt install linux-generic-hwe-24.04

Screen tearing

On X11, Intel’s xe driver uses the modesetting DDX by default, which doesn’t support the traditional TearFree option from the old intel DDX. Using a compositor with vsync enabled (most desktop environments do this out of the box) resolves it, or you can switch to Wayland entirely .

On Wayland with GNOME or KDE, tearing should be absent by default since the compositor controls presentation timing. If you’re seeing screen tearing on Wayland , verify the compositor is actually running in hardware-accelerated mode:

WAYLAND_DEBUG=1 weston-info 2>&1 | grep renderer
# or for GNOME
gsettings get org.gnome.mutter experimental-features

Missing or outdated firmware

If vainfo shows errors or no supported profiles, the GuC/HuC firmware files may be absent or outdated. Check what’s loaded:

dmesg | grep -i "huc\|guc" | head -20

If you see “firmware not found” or version mismatch warnings, update the linux-firmware package:

# Debian/Ubuntu
sudo apt update && sudo apt install --reinstall linux-firmware

# Fedora
sudo dnf update linux-firmware

# Arch
sudo pacman -S linux-firmware

If your distro’s package is lagging significantly behind upstream, you can pull the latest firmware directly from the linux-firmware git repository and copy the Intel files manually:

git clone --depth=1 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
sudo cp linux-firmware/i915/* /lib/firmware/i915/
sudo update-initramfs -u   # Debian/Ubuntu
# or
sudo dracut --force         # Fedora/RHEL

Reboot after updating firmware to ensure the new binaries are picked up during driver initialization.

The Arc 140V is a solid GPU for Linux in 2026. The driver situation has matured from the rocky early days of the xe transition, and LACT covers the GUI monitoring and power tuning that most users need. The CLI tools fill in where the GUI falls short. The one hard requirement is running a current software stack - old kernels and old Mesa versions will cap your performance well below what the hardware can actually do.