Fixing Nouveau 3D acceleration glitches on MacBook Pro

Hi there,
I want to share some notes on how I fixed some graphics glitches with openSUSE Leap 15.0 on my 2010 MacBook Pro. Partly to help others, but also to help myself in the future if I need to redo this fix.

After working through some early issues (1, 2, and 3), my fresh install of openSUSE seemed to have settled down nicely. I noticed however some frequent graphical glitching (mostly when scrolling firefox, but also in other applications).

The system was using the “nouveau” driver at this point, with the Mesa-dri-nouveau package present (I had been prompted about this package during install, and warned about potential instability of it). I first tried removing this package, which was successful at resolving the glitches, but made the desktop perform very poorly (even scrolling was choppy).

I then tried the NVIDIA binary drivers using the wiki instructions. This was awful. After a reboot the screen went blank when attempting to start X. I didn’t try resolving this problem but instead removed the NVIDIA drivers in single user mode, and went back the “nouveau” drivers with the Mesa-dri-nouveau package. The system was usable and performant again but still had the glitches.

I examined the Xorg logs and saw numerous errors of the form: “nouveau_dri2_flip_event_handler: Pageflip has impossible msc”. I looked at the man page for “nouveau” and discovered an option that looked relevant:


       Option "PageFlip" "boolean"
              Enable DRI2 page flipping. Default: on.

I don’t know what this feature is, but disabling has fixed my glitches. I am successfully using Nouveau’s 3D acceleration glitch-free!


~> cat /etc/X11/xorg.conf.d/80-nouveau-fixes.conf 
Section "Device"
    Identifier "nouveau"
    Driver "nouveau"
    Option "PageFlip" "false"
EndSection

Another possibility: instead of nouveau, you could try the upstream default DDX “modesetting”, discussed on the nomodeset SDB page. It’s what I use on my 2007 iMac, and all my PCs with NVidia GPUs.

To be clear, do you mean to try the “nomodeset” kernel parameter and the NVIDIA binary drivers together, as a suggestion that this might fix the blank screen problem?

No! You seem to have been mislead by the page title. Just below the middle of the page is this:

The generic default FOSS DDX driver is named “modesetting” and provided by the xorg-x11-server package…Even though modesetting is the default driver, most installations include all xf86-video-* packages, thus overriding the technical default.
Without having any (video-related) proprietary or optional software installed, you should see something resembling the following:

> inxi -V | head -n1
[inxi 3.0.34-00](https://smxi.org/docs/inxi-installation.htm#inxi-manual-install) (2019-04-30)
> inxi -GxxSa
System:    Host: p5bse Kernel: 4.12.14-lp150.12.58-default x86_64 bits: 64 compiler: gcc v: 7.3.1
           parameters: root=UUID=foobarbaz ipv6.disable=1 net.ifnames=0 noresume
           Desktop: KDE 3.5.10 tk: Qt 3.3.8c wm: kwin dm: N/A Distro: openSUSE Leap 15.0
Graphics:  Device-1: NVIDIA GT218 [GeForce 210] vendor: eVga.com. driver: nouveau v: kernel bus ID: 01:00.0 chip ID: 10de:0a65
           Display: server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa alternate: nouveau,nv,nvidia
           resolution: 2560x1440~60Hz
           OpenGL: renderer: llvmpipe (LLVM 5.0 128 bits) v: 3.3 Mesa 18.0.2 compat-v: 3.0 direct render: Yes
> grep -i 'nel comm' /var/log/Xorg.0.log
  1233.525] Kernel command line: root=UUID=foobarbaz ipv6.disable=1 net.ifnames=0 noresume

I read the wiki page you linked to in more detail, and also read up on a bit more context on KMS, modesetting, various xorg drivers.

I now interpret your suggestion as: “try using the modesetting xorg driver (with glamor acceleration), instead of the nouveau one” (both of these use the “nouveau” kernel module).

In practice this means swapping my fix:


Section "Device"
    Identifier "nouveau"
    Driver "nouveau"
    Option "PageFlip" "false"
EndSection

with:


Section "Device"
    Identifier "modesetting"
    Driver "modesetting"
EndSection

This too fixes the glitches I was experiencing with the nouveau xorg driver. Thanks for the suggestion.

Which then should be the preferred fix? I don’t think I’m clear on the pros and cons of xorg-modesetting driver vs xorg-nouveau.

I guess instead of editing config files, removing the “xf86-video-nouveau” package also works - as that causes xorg to eventually try the modesetting driver automatically.

This is perhaps the neatest solution.

I agree! :o

xf86-video-nouveau is a result of reverse engineering. The default is not - different, and newer, technology.

Hm, actually this solution isn’t quite complete. Running “zypper install-new-recommends” (or zypper inr) as is common after adding new hardware or a software repository results in zypper suggesting to reinstall the “xf86-video-nouveau” package.

In addition to removing this package, it makes sense to mark it never to be installed. Example on how to do that: How to blacklist a package from being re-installed by ZYpp? - Applications - openSUSE Forums

Yes, that was my experience with an older nvidia card. But, instead of blacklisting the package, I simply removed the nvidia repo.

I also found that I needed to do a forced reinstall of mesa.

[quote="“nrickert,post:9,topic:136206”]

Yes, that was my experience with an older nvidia card. But, instead of blacklisting the package, I simply removed the nvidia repo.[/QUOTE]Pauldoo is referring to a new recommends causing xf86-video-nouveau to be installed again, after it had been removed to cause the upstream default modesetting DDX to be used. Neither modesetting DDX nor nouveau DDX come from optional repos. So, either zypper al xf86-video-nouveau or its equivalent tabooing in YaST is required to specifically prevent its reinstallation via recommends, or another method must be employed, e.g. that which I do to minimize installed size and updates resource consumption: in /etc/zypp/zypp.conf uncomment “solver.onlyRequires = true”, which avoids all recommends.

Yes, I misread that. Thanks for the correction.