DmaBuf show graphic glitch with mesa 20.0 + iris driver

[12101111]

workaround:

<qemu:env name="MESA_LOADER_DRIVER_OVERRIDE" value="i965"/>

[winsock]

Can confirm that the workaround fixes this issue for me. I don't know if this information is helpful but for me if you drag a window around while having this issue it clears up the screen. As soon as you stop moving a window it goes back to this.

This started for me when I upgraded from Fedora 31 to 32

[hexchain]

I've opened an issue at Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2678

[h1ghrise]

fixed it for me as well :) THANKS ❤️

[grazzolini]

The qemu:env workaround seems to fix not only the garbled screen, but it also makes the POST visible. Also, it fixes the mouse pointer for me.

[winsock]

If you want to keep using the Iris driver instead of i965 you can use this environment workaround too:

<qemu:env name="INTEL_DEBUG" value="norbc"/>

[grazzolini]

If you want to keep using the Iris driver instead of i965 you can use this environment workaround too:

<qemu:env name="INTEL_DEBUG" value="norbc"/>

I will also give that a try. I have been experimenting a lot since the latest -lts kernel broke everything. Found out that, for some reason, prime render offload causes issues, see #162. I also found out that when, using the mainline kernel, if you start a VM with a vGPU, stop it, issue a remove on the vGPU (I'm using a libvirt qemu hook) and suspend the host machine, after you resume it, and try to start the VM again, it won't load anymore. It gets stuck on the early userspace, when i915 module is loaded. This doesn't happen on -lts at least, so I'm using that.

[TerrenceXu]

Thanks all, since this issue is mesa issue, close it, and for #162 we will have a look later.

[lattice0]

Where do I add this parameter <qemu:env name="MESA_LOADER_DRIVER_OVERRIDE" value="i965"/> on virt-manager? I tried adding like this

<domain type="kvm">
  <name>unsafe_code_2</name>
    <qemu:commandline>
      <qemu:env name="MESA_LOADER_DRIVER_OVERRIDE" value="i965"/>
  </qemu:commandline>

but when I click apply, virt-manager takes it out

[12101111]

Where do I add this parameter <qemu:env name="MESA_LOADER_DRIVER_OVERRIDE" value="i965"/> on virt-manager? I tried adding like this

<domain type="kvm">
  <name>unsafe_code_2</name>
    <qemu:commandline>
      <qemu:env name="MESA_LOADER_DRIVER_OVERRIDE" value="i965"/>
  </qemu:commandline>

but when I click apply, virt-manager takes it out

Insert this right above the closing tag

https://wiki.archlinux.org/title/Intel_GVT-g#Garbled_graphics

[cynecx]

Change this line:

<domain type='kvm'>

into this line:

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

[lattice0]

@cynecx

<domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0" type="kvm">
  <name>unsafe_code_2</name>
  <uuid>e5ee6dde-b43b-4ff7-8604-c657bd62e721</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://ubuntu.com/ubuntu/20.04"/>
    </libosinfo:libosinfo>
  </metadata>
  <qemu:commandline>
    <qemu:env name="MESA_LOADER_DRIVER_OVERRIDE" value="i965"/>
  </qemu:commandline>
   ...

after I hit apply on this, virt-manager erases the

  <qemu:commandline>
    <qemu:env name="MESA_LOADER_DRIVER_OVERRIDE" value="i965"/>
  </qemu:commandline>

[lattice0]

Nevermind, turns out it was not erasing the tags but putting on the very end of the xml

So, with the quirk enabled, now simply the screen goes black on startup. Intel Iris Xe here with i7, virt-manager ubuntu 20.04

[lattice0]

<qemu:env name="INTEL_DEBUG" value="norbc"/>

fixed the glitches, but I get this

[cypherpunk1984]

<qemu:env name="INTEL_DEBUG" value="norbc"/>

fixed the glitches, but I get this

That issue appears when your host uses Hi-DPI, if you turn it off the VMs go back to normal.
Unfortunately when you select normal scale everything in your host will look tiny. But you can turn Hi-DPI back on when you finish using your VM. Very annoying but there is no other way, at least that I know of.

[lattice0]

<qemu:env name="INTEL_DEBUG" value="norbc"/>

fixed the glitches, but I get this

That issue appears when your host uses Hi-DPI, if you turn it off the VMs go back to normal.
Unfortunately when you select normal scale everything in your host will look tiny. But you can turn Hi-DPI back on when you finish using your VM. Very annoying but there is no other way, at least that I know of.

Indeed it works when I turn off scaling but my notebook is 4k and just 13" so it's impossible to use without scaling

[cypherpunk1984]

<qemu:env name="INTEL_DEBUG" value="norbc"/>
fixed the glitches, but I get this

That issue appears when your host uses Hi-DPI, if you turn it off the VMs go back to normal.
Unfortunately when you select normal scale everything in your host will look tiny. But you can turn Hi-DPI back on when you finish using your VM. Very annoying but there is no other way, at least that I know of.

Indeed it works when I turn off scaling but my notebook is 4k and just 13" so it's impossible to use without scaling

I have found a solution! No need to turn off scaling. Hopefully it works for you too.

1. Run your VM normally with virt-manager.
2. Open terminal in you host and type: GDK_SCALE=1 virt-viewer --connect qemu:///system [GUESTNAME] --attach
3. Your VM's display now has been de-attached from virt-manager and attached to virt-viewer (with scaling). You can close the virt-manager window, and just keep the virt-viewer one.

Don't forget to replace [GUESTNAME].

Unfortunately virt-manager doesn't respond to GDK_SCALE because of a gtk bug when typed in the XML as:

  <qemu:commandline>
    <qemu:env name='GDK_SCALE' value='1.0'/>
  </qemu:commandline>

People have been asking for a fix for more than 4 years.
But at least we can use it with virt-viewer, it has less features than virt-manager but it works.