software renderer
thenameisluk opened this issue · 14 comments
i run linux (debian trixie) on old chromebook with no gpu drivers since there are no availble atm and probably never will
that's why for rendering graphics on it i use software renderer
most wayland window menagers (sawy or gnome/mutter) work on it without any issue
but niri doesn't really want to
when i try to run it says
2024-02-2016:56:57.0833562
INFO niri: starting version 0.1.2 (unknown commit)
2024-02-2016:56:57.1500902 DEBUG niri _config: loaded config from "/home/linux/.config/niri/config-kd1"
thread
'main'
panicked at src/main.rs: 162:6:
called
Result:: unwrap()
value: error initializing the TTY backend
Caused by:
error getting the render node for the primary GPU
stack backtrace:
0: rust_begin_unwind
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/std/src/panicking.rs:645:5
1: core:: panicking:: panic_fmt
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/panicking-rs:72:14
2: core: result::unwrap_failed
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1649:5
3: unwrap‹niri::niri::State, alloc:: boxed: :Box‹dyn core::error::Error, alloc::alloc::Global>
at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/result.rs:1073:23
at /home/linux/Pobrane/niri-0.1.2/src/main.rs: 156:21
5: call_once<fn()
→> core::result: :Result‹(), alloc: :boxed: :Box‹dyn core::error::Error, alloc::alloc::Global», (› at /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with 'RUST_BACKTRACE=full for a verbose backtrace.
my guess is that it either doesn't have software rendering support
or it is not enabled. i tried going through options and couldn't find anything. So my question is is there an option to enable it or there is no support yet or not planned at all (something like pixman)?
System Information
- niri version: niri 0.1.2 (unknown commit)
- GPU: PowerVR GX6250 (no driver)
- CPU: MediaTek MT8173
There's no software rendering support at the moment. I'm also not sure Smithay fully supports pixman for regular rendering at the moment (cc @cmeissl); but even if it does, this would require somewhat awkward refactors in niri, since we currently store GL textures directly in a few places which simplifies the logic.
It does, see: Smithay/smithay#1228
It should work with gbm and also with dumb buffers (tested during development by replacing multigpu renderer with PixmanRenderer) . What we lack is an easy way to dynamically select a renderer, multigpu makes it even more complicated.
+1
Debian arm64
CPU
Processor ARM Amlogic @ 1.80 GHz 1 Processor, 4 Cores
GPU Mali G31
[ 10.104388] panfrost ffe40000.gpu: clock rate = 24000000
[ 10.114842] panfrost ffe40000.gpu: mali-g31 id 0x7093 major 0x0 minor 0x0 status 0x0
[ 10.118863] panfrost ffe40000.gpu: features: 00000000,000027f7, issues: 00000000,00000400
[ 10.126978] panfrost ffe40000.gpu: Features: L2:0x07100206 Shader:0x00000000 Tiler:0x00000209 Mem:0x1 MMU:0x00002821 AS:0xff JS:0x7
[ 10.138672] panfrost ffe40000.gpu: shader_present=0x1 l2_present=0x1
Error msg:
2024-03-22T01:33:10.248289Z INFO niri: starting version 0.1.3 (unknown commit)
2024-03-22T01:33:10.439757Z DEBUG niri_config: loaded config from "/home/mxu/.config/niri/config.kdl"
thread 'main' panicked at src/main.rs:179:6:
called `Result::unwrap()` on an `Err` value: error initializing the TTY backend
Caused by:
error getting the render node for the primary GPU
stack backtrace:
0: 0x7f82a362fc - <unknown>
1: 0x7f82233a00 - <unknown>
2: 0x7f82a32e2c - <unknown>
3: 0x7f82a360ec - <unknown>
4: 0x7f82a37f64 - <unknown>
5: 0x7f82a37c44 - <unknown>
6: 0x7f82a38458 - <unknown>
7: 0x7f82a38330 - <unknown>
8: 0x7f82a367cc - <unknown>
9: 0x7f82a380e4 - <unknown>
10: 0x7f82140858 - <unknown>
11: 0x7f82140ba8 - <unknown>
12: 0x7f82683450 - <unknown>
13: 0x7f8268a4a8 - <unknown>
14: 0x7f8268c708 - <unknown>
15: 0x7f82a2b438 - <unknown>
16: 0x7f82684204 - <unknown>
17: 0x7f81d97780 - <unknown>
18: 0x7f81d97858 - __libc_start_main
19: 0x7f82196230 - <unknown>
20: 0x0 - <unknown>
GPU Mali G31
as far as i know ur cpu has open source drivers in mesa for opengl 3.1
so your issue might not be related to lack of software renderer in niri
I get the same error as mia0x75 on a Raspberry Pi Compute Module 4 with current RaspberryPi OS (Bookworm).
If I start gnome first and start niri inside a window it is working without problems.
But if I try to start niri from gdm3 it fails:
error.log
GLXInfo suggests my GPU drivers are there:
glxinfo.log
Can someone enlighten me please? Should I run a minimal WM around niri as a workaround?
@nougatbyte you're hitting #151
https://github.com/YaLTeR/niri/assets/92756992/d272c8f7-c9b2-4089-8e28-e7fbe346e548
i compiled latest version of main branch
and got a black screen, so unless someone introduced it in other commit nope
still broken
Okay, I think this means that the relaxed check worked as intended (instead of a panic, it tried to proceed, but the node was wrong). To exit the black screen, you could try Super+Shift+E followed by Enter.
Could you paste the output of ls /dev/dri/ and also try setting render-drm-device to the render or card devices there to see if one will work? Also, you can run in tmux to be able to see the output afterwards (might need a screen refresh when on a TTY to see the real output).
ls /dev/dri
outputs
by-path card0
can be seen on picture
adding
debug {
render-drm-device "/dev/dri/card0"
}
to
~/.config/niri/config.kdl
doesn't fix the issue
forgot to include the picture
sorry for markdown mess in reply
there is no preview in mobile github so i write it blindly
For me its fixed on main branch on Raspberry Pi Compute module 4
@LukIsHere thank you for testing. I'm assuming that in your case, the problem is indeed that there's no OpenGL support, and a software renderer would be needed. I see a part of the error message about EGL extensions on the photo, which usually comes up in this case.
@nougatbyte cool! Do you still need to set render-drm-device manually for it to work?