Use generic modesetting driver instead i915/i965 as default

[donob4n]

Qubes OS version:

R4.1

Affected component(s):

Xorg, fixes graphical artifacts with KDE (and others desktops)

---

Steps to reproduce the behavior:

From https://groups.google.com/d/msgid/qubes-users/5cc49553-b12c-4e4d-7601-f961330a14e6%40gmail.com

I had some graphical artifacts with current stable kernel but testing latest version they become more problematic (it can not draw the main menu, task bar does not properly refresh when switching virtual desktops and also some app windows stops redrawing after some time).

I noticed that it also fixed some ghost clicks from some windows to another (specially if they are full screen).

Also I have better system tray icons than with the other driver but I use "border1" mode. I tried to test default mode and it was pretty bad although I am not sure if it was worse or better than i915 driver.

General notes:

According to https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch this seems the current default driver in Fedora so probably Qubes dom0 should adopt the same decision.

---

Related issues:

#3267

[marmarek]

This should resolve itself automatically once we update dom0 in R4.1.

[dmoerner]

On my X1 carbon 3rd generation, running R4.1, I was getting graphical artifacts in gnome-terminal and firefox when scrolling. Switching back to the "intel" xorg driver from the modesetting driver seems to fix this problem. Thank you to drpfef on IRC for suggesting this.

That is, I added the following to /etc/X11/xorg.conf.d/20-intel.conf

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
EndSection

I think that perhaps something like this could be added to https://github.com/Qubes-Community/Contents/blob/master/docs/troubleshooting/intel-igfx-troubleshooting.md for R4.1 users who are having trouble with the new modesetting driver? I didn't submit a pull request for the docs myself because so far this is just my one case.

[dmoerner]

Just wanted to add that I also see this graphics corruption with the modesetting driver on a T460 (HD Graphics 520), although for some reason it's much rarer.

[AlxHnr]

Thanks @dmoerner! Switching from modesetting to intel fixed the problem for me. Without this, I was seeing artifacts on Qubes 4.1 on my T430i (Intel HD 4000):

I also get glitches at the boot password prompt. I tried fiddling with i915.mitigations=off, but that makes no difference.

[alt3r-3go]

As an additional data point - I also observe something very similar (streak-like artifacts on changed/highlighted portions of the screen, only in the GUI part - e.g. boot trace and Ctr+Alt+F2 console work fine) on my Intel ADL-H-based laptop. The default or explicit "modesetting" driver exhibit that and only the "intel" one fixes the problem (none provide acceleration though). That's on kernel-latest from the stable repo (5.16.13 as of right now), but relatively old Mesa packages that dom0 provides.

[DemiMarie]

As an additional data point - I also observe something very similar (streak-like artifacts on changed/highlighted portions of the screen, only in the GUI part - e.g. boot trace and Ctr+Alt+F2 console work fine) on my Intel ADL-H-based laptop. The default or explicit "modesetting" driver exhibit that and only the "intel" one fixes the problem (none provide acceleration though). That's on kernel-latest from the stable repo (5.16.13 as of right now), but relatively old Mesa packages that dom0 provides.

@marmarek is there any chance we can provide a newer Mesa?

[marmarek]

@marmarek is there any chance we can provide a newer Mesa?

If proven to solve the issue first, then maybe. But that's quite a few packages to repackage/rebuild, and I'm not going to do it "just in case". sys-gui-gpu may be helpful with testing various versions. Anyway, since the issue applies to relatively old hardware too (especially - way older than fc32 we have in dom0), it's unlikely the upgrade would help.

[alt3r-3go]

Yeah, I'm not sure Mesa is the culprit here, TBH. One thing I forgot to mention is that booting the same dom0 directly (i.e. commenting out Xen and changing module directives to linux and initrd respectively in the Grub menu) yields no artifacts - so it looks like that added variable of Xen changes something, though I don't see anything significant in the log diff.

There's still no HW acceleration when booted directly though - and that's where newer Mesa would probably help, but that's orthogonal to the original issue reported in this thread and I just mentioned that for completeness.

[DemiMarie]

Yeah, I'm not sure Mesa is the culprit here, TBH. One thing I forgot to mention is that booting the same dom0 directly (i.e. commenting out Xen and changing module directives to linux and initrd respectively in the Grub menu) yields no artifacts - so it looks like that added variable of Xen changes something, though I don't see anything significant in the log diff.

That is interesting. I wonder if disabling the IOMMU for the i915 integrated GPU would help. @marmarek is it safe to do this, on the assumption that the iGPU is trusted?

[marmarek]

I also get glitches at the boot password prompt. I tried fiddling with i915.mitigations=off, but that makes no difference.

I have this on one device too. There, starting just Linux (without Xen) helps(*), but iommu=no-igfx does not.

(*) there are no glitches, but when the prompt appears, I need to press ESC twice to make it update after key presses - otherwise no got appears when entering the passphrase. Could be totally unrelated issue to the graphics driver.

[marmarek]

I also get glitches at the boot password prompt.

In my instance, torvalds/linux@bdd8b6c98239cad fixes the issue. Unfortunately, I've seen regressions elsewhere caused by this commit (#7479).

[marmarek]

@alt3r-3go @AlxHnr can you test any of the 5.18.x kernel-latest package? It includes the commit mentioned above, and also a follow up fix for it.

[DemiMarie]

@alt3r-3go @AlxHnr can you test any of the 5.18.x kernel-latest package? It includes the commit mentioned above, and also a follow up fix for it.

Does that follow up fix fix #7479?

[marmarek]

Does that follow up fix fix #7479?

Yes. But when both are applied on top of 5.15.52, it brings back glitches on plymouth (on this specific hw). Which is kind of expected as the follow up fix un-does torvalds/linux@bdd8b6c98239cad from i915 driver point of view... There is probably some other relevant commit somewhere there, but I'd like to know how it looks for others.

[DemiMarie]

Maybe there needs to be some hardware-specific quirks?

[AlxHnr]

@alt3r-3go @AlxHnr can you test any of the 5.18.x kernel-latest package? It includes the commit mentioned above, and also a follow up fix for it.

No, I don't want to. I've stopped using graphical plymonth some months ago.

[alt3r-3go]

I'm installing those right now. FWIW I've been running 5.18.3 for a while and if that one includes the change in question, it didn't help, the artifacts were still there. I see the latest is 5.18.9 as of now, we'll see.

[qubesos-bot]

Automated announcement from builder-github

The component vmm-xen (including package python3-xen-4.14.5-15.fc32) has been pushed to the r4.1 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package vmm-xen has been pushed to the r4.1 testing repository for the CentOS centos-stream8 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.1-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package xen_4.14.5-15 has been pushed to the r4.1 testing repository for the Debian template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing buster-testing (or appropriate equivalent for your template version), then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package vmm-xen has been pushed to the r4.1 stable repository for the CentOS centos-stream8 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package xen_4.14.5-15+deb10u1 has been pushed to the r4.1 stable repository for the Debian template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The component vmm-xen (including package python3-xen-4.14.5-15.fc32) has been pushed to the r4.1 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[DemiMarie]

The modesetting driver still needs to actually be made the default. @marmarek: can the TearFree patch be backported?

[marmarek]

The modesetting driver still needs to actually be made the default.

It is already the case (see the very first comment in the issue).

can the TearFree patch be backported?

I don't know what you are talking about. But it looks offtopic in this issue.