QEMU Display Output is not active #2570
argosnothing
started this conversation in
General
Replies: 31 comments 7 replies
|
additional screenshot from the arch attempt: 
|
0 replies
|
I do not think this is a niri issue..? And more of none of the extensions from your card are being forwarded to QEMU |
0 replies
My bad I forgot to mention i also tested this with several other wms as well as cosmic. If it's not a niri issue i don't understand how these other environments just work in my case. |
0 replies
|
Does running Anvil in QEMU work..? |
0 replies
i have not tested this one yet. will do |
0 replies
|
And the reason why I don't think this is a niri issue, Just putting it here for you to look at |
0 replies
|
I read this but i'm not sure if this is applicable to me as I only have a single virtual display. |
0 replies
|
I tried messing with anvil, but on nix it's a little tricky because I imagine i'd need to deal with the libseat dependency. 
Also on my machine, on nix i don't get any issues with those extensions, but it still gives the same screen. 
|
0 replies
|
Hm, and there's no errors at all from running on the nix machine..? |
0 replies
|
well, its not being returned from the actual niri process at least. I'll double check journalctl |
0 replies
that's all from journalctl -xe
all this with 
|
0 replies
|
Hm, is the display configured in uh niri's config.kdl..? |
0 replies
|
yes, I linked a screenshot showing it with Virtual-1. I'm loading up my cosmic option rn to triple check that name is correct |
0 replies
|
but even without that, my intuition would be that it'd work regardless of display being specified |
0 replies
but i do not have those exact settings for the resolution and refresh so might as well give that a shot.
|
0 replies
Yeah i tried this as well and no dice. The other person with this issue has similar specs, gpu iirc. I am assuming this is some kind of user error as I would imagine there would be an issue about this, but the last one was from around a year ago and has since been fixed. |
0 replies
|
Ya, if you want, you can probably make this into a discussion instead |
0 replies
|
Chiming in here, why I think its niri specific is that other compositors are working fine on this vm for me, on Arch linux. Here are some of the specs, and the relevant Rust logs: 
Arch Linux, 6.17.1 kerneel |
0 replies
|
I don't think this is related to this previous Smithay issue But may be worth a look at |
0 replies
|
Yeah I looked at that. If this can be converted to a discussion, that is fine. I imagine we aren't going to be the only two with this issue. |
0 replies
Out of curiosity, did you try any other Smithay based Compositors..? |
0 replies
I think @YaLTeR is able to convert this to a discussion |
0 replies
|
I had this issue on my previously working vms. I think my actions were relevant. I had been having unstability on my new desktop - most likely due the Intel stability issue - so I tried to copy stuff to my old computer. My new computer had a AMD graphics card, my old has a RTX 2080. I believe most likely my old computer is running the proprietary nvidia drivers. I copied accross my VM by dumping and importing the XML, copied the image across, and updated the reference to the image. But the VM wouldn't start, with EGL_NOT_INITIALIZED. Preliminary investigation seemed to indicate that I can't get 3d acceleration with nvidia unless I have a dedicated graphics card (not 100% sure of the accuracy here). I saw a claim this should work: https://forums.developer.nvidia.com/t/egl-errors-with-qemu-kvm-and-virtio-w-hardware-acceleration/318750/5 but it didn't. So I disabled 3d acceleration in the VM. At this point I get the blank display when trying to start niri. My theory is niri does not like the lack of 3d acceleration, and I can't get 3d acceleration in a VM with a single nvidia card. |
0 replies
|
If there was a way to run a remote niri session that would be good also. wayvnc looks like it should be the solution. Last time I tried wayvnc with niri though I couldn't get the two to work correctly. |
0 replies
|
I had this issue when I tried to use Niri in OpenSUSE Tumbleweed on Distrosea, but it ran fine when I ran it in a window inside of Xfce or Cinnamon. |
0 replies
|
I have the same issue running Niri in NixOS in a libvirt VM with 3d acceleration enabled (virtio). Niri runs fine as a window inside of GNOME though. Happy to help debug. |
0 replies
|
Same issue here. It seems like the Just for testing Sway worked, Niri refuses find a suitable display. |
4 replies
|
|
|
Same here, the following seems to work: But using venus with: Currently errors with |
|
What video card is this? That looks to me like you are enabling virtualized GPU. My experience was I couldn't get virtualized GPU working with nvidia (seems to require a dedicated GPU just for the VM). But it worked fine with AMD. |
|
Yeah, sorry AMD, specifically Steam Deck's APU. |
|
I don't think it will be possible anytime soon to run Niri using qemu without underlying GPU. #218 - apparently @YaLTeR made a design decision to rely solely on OpenGL APIs in Smithay and when you use virtio (not virgl with a real GPU on host) it just won't work. EDIT: so I think that fix is not on Niri side - some of you guys mentioned you have real GPU backing Qemu - you might just need to change VGA backend to VirGL GPU and Niri might work :) |
0 replies
|
Indeed, the issue is that niri has a hard dependency on OpenGL. It's too bad it doesn't give a better error message but instead just hangs. Still, I got it working in 
And by the way I'm using a libvirt 
The only elevated privileges, maybe, are that I'm in They key steps I took were:
<video>
<model type="virtio" heads="1" primary="yes">
<acceleration accel3d="yes"/>
</model>
<alias name="video0"/>
<address type="pci" domain="0x0000" bus="0x00" slot="0x01" function="0x0"/>
</video>
(the /dev/dri path is probably different for you) <graphics type="spice">
<listen type="none"/>
<image compression="off"/>
<gl enable="yes" rendernode="/dev/dri/by-path/pci-0000:00:02.0-render"/>
</graphics>Here's my complete config in case it helps someone: libvirt-domain.xml |
3 replies
|
And my versions are: HostOS: ArchLinux lspci on my graphics carddrm_info |
GuestOS: ArchLinux Packages:
lspci on virtual GPUdrm_info on virtual GPU |
|
This worked for me, thank you! |
|
Just some info on my experience here. I am running Fedora 43 and have both niri and hyprland working. I have an nvidia RTX 3090 and use the proprietary nvidia drivers. I wanted to tweak my niri setup a bit as I've only just started using it, so I just used quickemu to run up a copy of fedora's Sway spin, installed niri and tried to boot it. Would not work with niri, but worked fine with hyprland and sway on the guest. When selecting niri from the display manager, I just got a black screen. On an off chance, I restarted the VM and used sdl as the view and it works fine. No special settings or tweaks with qemu drivers etc. The only slight downside is that sdl doesn't give that closer integration you can get with spice i.e. shared clipboard. However, this does tend to indicate that niri will work fine running as a VM under qemu/kvm provided you use SDL as the viewer rather than spice and that problems are more likely with the viewer or qemu rather than niri? |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Through libvert, using virtuo and any other display over a virtual machine produces
On nixos this was tried using the sodiboo-flake, but the issue seems to step from niri itself as installed on arch also gives the same error.
niri version:
Additionally a separate individual tested this on arch against the latest commit.
Ryzen 7
All reactions