Index | Thread | Search

From:
Christoph Liebender <christoph@liebender.dev>
Subject:
niri-25.11.20260220 crashes: "couldn't find GPU"
To:
ports@openbsd.org
Cc:
tobhe@openbsd.org
Date:
Wed, 25 Feb 2026 18:41:51 +0100

Download raw body.

Thread
Hi ports@, Tobias,

when trying to startniri.sh from vt0, it crashes for me with the 
attached error. (Specifying render-drm-device as it was suggested in the 
pkg-readme causes niri not to start at all, as I reported in the initial 
import thread already.)

I wonder, is there any other steps involved to get niri running? Do I 
need seatd, greetd, or anything like that? Or _should_ it just be a 
"raw" login to vt0 with startniri.sh? Because that's what I am trying.

- christoph
niri:/usr/local/lib/libinput.so.0.1: undefined symbol 'libevdev_event_type_from_name'
niri:/usr/local/lib/libinput.so.0.1: undefined symbol 'libevdev_event_type_get_max'
niri:/usr/local/lib/libinput.so.0.1: undefined symbol 'libevdev_event_code_from_name'
niri:/usr/local/lib/libinput.so.0.1: undefined symbol 'libevdev_property_from_name'
␛[2m2026-02-25T17:22:19.223395Z␛[0m ␛[32m INFO␛[0m ␛[2mniri␛[0m␛[2m:␛[0m starting version 25.11 (unknown commit)
␛[2m2026-02-25T17:22:19.344805Z␛[0m ␛[34mDEBUG␛[0m ␛[2mniri_config␛[0m␛[2m:␛[0m loaded config from "/home/chris/.config/niri/config.kdl"

thread 'main' (552285) panicked at src/main.rs:181:6:
called `Result::unwrap()` on an `Err` value: error initializing the TTY backend

Caused by:
    couldn't find a GPU
stack backtrace:
   0:      0xf16414bce4e - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h0135d11357e767e9
   1:      0xf16414e61ad - core::fmt::write::h6d8467e16b3f3f38
   2:      0xf16414b0617 - std::io::default_write_fmt::hb0395fb9d1a508b0
   3:      0xf16414bbe66 - std::sys::backtrace::BacktraceLock::print::h34d49d19aa3abeeb
   4:      0xf16414c862c - std::panicking::default_hook::{{closure}}::h234a3010c929fc68
   5:      0xf16414c84c0 - std::panicking::default_hook::h0c069c521bf83685
   6:      0xf16414c88be - std::panicking::panic_with_hook::had8c7a2d030db1d6
   7:      0xf16414bc0a9 - std::panicking::panic_handler::{{closure}}::h80acd896171c9d4c
   8:      0xf16414bbf7d - std::sys::backtrace::__rust_end_short_backtrace::hb71ecc129b170deb
   9:      0xf16414c5ee1 - __rustc[9a678ed50e966dd8]::rust_begin_unwind
  10:      0xf16414eadd0 - core::panicking::panic_fmt::hb73cae62b55d56e2
  11:      0xf16414e93c6 - core::result::unwrap_failed::ha3cd1f1a5c794328
  12:      0xf16408688c2 - niri::main::h870fff08d9612002
  13:      0xf1640845736 - std::sys::backtrace::__rust_begin_short_backtrace::h3d87117d9370eca2
  14:      0xf164084557a - std::rt::lang_start::{{closure}}::h9b70037addad502b
  15:      0xf16414b14ea - std::rt::lang_start_internal::h4700e6e55d756d66
  16:      0xf1640869ea1 - main
  17:      0xf1640834a3b - <unknown>
udev_input_destroy