Category Archives: Hardware, Treiber

Beiträge zu der von mir eingesetzten Hardware

Opensuse, KDE Plasma, X11, Nvidia – stop video and screen tearing

Posted on by

In these times of Corona, home-office and of increased Internet usage some of us Linux guys may experience an old phenomenon: screen and video tearing. In my case it happened with an Nvidia card and with X11 (Wayland does not yet work on my Opensuse Leap 15.1 – I am too lazy to investigate why). I have ignored the tearing already for some months – but now it really annoyed me. I saw tearing already some years ago; at that point in time activating triple buffering helped. But not these days …

Where did I see the tearing?

I observed tearing effects

  • when moving “wobbling windows” (one of KDE’s desktop effects) across the screen – strangely enough when moving them slowly,
  • when watching TV and video streams in browsers (independent of FF, Opera or Chromium) – mostly when major parts of the video changed quickly.

Not much, not always – but enough to find it annoying. So, I invested some time – and got rid of it.

Driver and contents of the xorg.conf file

Driver: Latest Nvidia driver from Opensuse’s NVidia Repository: nvidia-glG05, x11-video-nvidiaG05.

I have three screens attached to my NVidia card (GTX 960); two of them are of the same type, but one has a lower resolution than the others. The screens are configured to work together as a super wide screen via the Xinerama setting in the xorg configuration file. Below, you find the contents of the file “/etc/X11/xorg.conf” with details about the screen configuration and modes.

xorg.conf

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings:  version 450.80.02


Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from data in "/etc/sysconfig/mouse"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "IMPS/2"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "yes"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"

    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "DELL U2515H"
    HorizSync       30.0 - 113.0
    VertRefresh     56.0 - 86.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GTX 960"
EndSection

Section "Screen"

    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-2"
    Option         "ForceFullCompositionPipeline"  "on"
#    Option         "ForceCompositionPipeline"  "on"
    Option         "metamodes" "DP-4: nvidia-auto-select +0+0, DP-0: nvidia-auto-select +2560+0, DVI-I-1: nvidia-auto-select +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: nvidia-auto-select +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1920x1080 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1680x1050 +5120+0; DP-4: nvidia-auto-select 
+2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1600x1200 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1440x900 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1280x1024 +5120+0; DP-4: nvidia-auto-select +2560+0, DP-0: nvidia-auto-select +0+0, DVI-I-1: 1280x960 +5120+0"
    Option         "SLI" "Off"
    Option         "TripleBuffer" "True"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

 

The most important statement regarding the suppression of tearing is 

    Option         "ForceFullCompositionPipeline"  "on"

Alternatively, 

    Option         "ForceCompositionPipeline"  "on"

seems to work equally well. Use the latter, if your graphics should react a bit sluggish.

We find more information about these options in the “nvidia-settings” application:

When you move your mouse over the option for “ForceCompositionPipeline” and “ForceFullCompositionPipeline”, you get

The Nvidia driver can use a composition pipeline to apply Xscreen transformations and rotations. “ForceCompositionPipeline” can be used to force the use of this pipeline, even when no transformations or rotations are applied to the screen. This option is implicitly set by ForceFullCompositionPipeline.

and, respectively,

“This option implicitly enables “ForceCompositionPipeline” and additionally makes use of the composition pipeline to apply ViewPortOut scaling.”

Important: If you want to test the setting via nidia-settings, you have to activate the options it for all three screens!.

When I first tested “ForceCompositionPipeline” I just set it on the page of “nvidia-settings” for the first screen of my three, wrongly assuming that this setting was applied in general. However, tearing did not disappear. I realized after some time that it still happened on 2 screens predominantly. I even suspected a different quality of the display-port cables to my screens to be the cause of tearing. Wrong … the ForceCompositionPipeline had been applied to one screen, only.

So, switch to the other screens by using the first combo-box on the “nvidia-settings”-page and set “ForceCompositionPipeline” for all screens. Do this before you eventually save the settings to a “xorg.conf”-file (as root). Your resulting xorg.conf file may look a bit different; the CompositionPipeline-settings might be included as a side-option of the meta-mode settings – and not in form of a special separate line as shown above.

Regarding Xvideo- and OpenGL-settings you should activate syncing;

KDE Plasma settings

KDE Plasma settings for the screens should be consistent with the “nvidia-settings”. You use KDE’s “system-settings” >> “Display and Monitor” >> “Displays” and “Compositor”.

The combination of all the settings discussed above worked in my case – the tearing disappeared for videos in browsers, in video applications as well as on the Xinerama KDE Plasma screen in general.

Conclusion

It is easy to suppress video and screen tearing on an Opensuse Leap system with KDE PLasma and a Nvidia graphics card. The most important point is to activate “ForceCompositionPipeline” on all individual screens via “nvidia-settings” or to activate this option globally for the Xinerama screen of a multi-monitor configuration.

Bumblebee for Optimus systems on Opensuse 15.1

Posted on by

Recently, I upgraded a laptop from Opensuse Leap 15.0 to Leap 15.1. I successfully followed the upgrade procedure described by the Linux Kamarada in

kamarada: how-to-upgrade-from-opensuse-leap-150-to-151/ .

The only problems I got had to do with the Optimus-design of my old laptop. When I followed my own description how to install and use Bumblebee as described in

Installation Opensuse Leap 15 auf Laptop – Grafik Probleme, Optimus

I always got an error message when trying to load the Nvidia kernel module: 

mytux:~ # sudo modprobe nvidia

modprobe: ERROR: could not insert 'nvidia': No such device

The reason was given by the command “dmesg”; the Nvidia device was no longer available on the PCI bus: 

NVRM: The NVIDIA GPU 0000:01:00.0
               NVRM: (PCI ID: 10de:134d) installed in this system has
               NVRM: fallen off the bus and is not responding to commands.
[    3.312435] nvidia: probe of 0000:01:00.0 failed with error -1

The bbswitch-module could, however, be loaded without any problems.

Workaround

A workaround is described in here :

After having started KDE or Gnome issue the following commands as root in a terminal:

mytux:~ # echo 1 > /sys/bus/pci/devices/0000:01:00.0/remove
mytux:~ # echo 1 > /sys/bus/pci/devices/0000:00:02.0/rescan

Afterwards my Nvidia card (640M) was available on the bus again – and e.g. “primusrun glxgears” worked.

So, something with starting the dkms.service and the bumblebeed.service, switching off the Nvidia card by the bbswitch module during system startup and later on loading of the nvidia-module was failing. I suspected the bbswitch-module to be the cause …

Solution

In my case I could solve the problem by installing the RPM packets

bumblebee, dkms, bbswitch, bbswitch-kmp-default

from the standard Update repository of Opensuse Leap 15.1

https://download.opensuse.org/update/leap/15.1/oss/

instead of installing them from the Bumblebee-repository

https://download.opensuse.org/repositories/X11:/Bumblebee/openSUSE_Leap_15.1

Otherwise I followed the instructions in
Installation Opensuse Leap 15 auf Laptop – Grafik Probleme, Optimus .

I.e.: I installed only the packets

nvidia-bumblebee, nvidia-bumblebee-32bit

from the Bumblebee repository.

Do not forget to issue a “mkinitrd” after you have successfully tested e.g. “optirun glxgears” and “tee /proc/acpi/bbswitch <<< OFF". Then reboot and use Optimus as you were used to. I do not know what is wrong with the packets in the Bumblebee repository - but I hope this bug is fixed soon. It is a bit annoying when one has to play around with packets of different repositories.

Addendum, 03.08.2020: A problem with VirtualGL

The present Bumblebee repository of Opensuse contains a new version of the VirtualGL library (version 2.6.4). Do NOT install this RPM-file. It will break your optirun/primusrun with an error:

Error: undefined symbol: glXGetProcAddressARB

Although this type of error is discussed in various forums on the Internet I have no clue how to mend it.

Workaround:
Use the original VirtualGL RPM of the Opensuse Leap 15.1 Update repository! Works on my system.

 

Linux SSD partition alignment – problems with external USB-to-SATA controllers – II

Posted on by

In my last article
Linux SSD partition alignment – problems with external USB-to-SATA controllers – I
I wrote about different partition alignments parted and YaST’s Partitioner (Opensuse) applied when one and the same SSD (a Samsung 850 Pro) was attached

  • to external USB-to-SATA controllers and the USB bus of a Linux system (1 MiB-alignment: start sectors as multiples of 2048 logical 512 byte blocks)
  • or directly to an internal SATA-III-controller of a Linux system (alignment to multiples of 65535 logical 512 byte blocks).

We saw that different controllers led to the detection of different disk topology parameters (I/O limits) by the Linux system via the libblkid library. For one and the same SSD different values were reported by different controllers e.g. for the following parameters (I/O Limits data) :

physical_block_size,    minimum_io_size,    optimal_io_size

We saw in addition that even different Linux disk tools may report different values; e.g. fdisk showed a different value [512 byte] for the “optimal_io_size” for the SSD on the SATA bus than e.g. lsblk and parted [0].

Guided by a Red Hat article https://people.redhat.com/msnitzer/docs/io-limits.txt we came to the conclusion that at least parted and YaST’s Partitioner use heuristic rules for its alignment decisions. The rules take into account the values for disk “I/O Limits” parameters. They are consistent with a default of “optimal” for the alignment parameter of parted and provide a decision when “the value for “optimal_io_size” is found to be zero. By applying these rules we could explain why we got different partition offsets and alignments for one and the same disk when it was attached to different controllers.

But this insight left us in an uncomfortable situation:

  1. Should we cling to the chosen settings when we use the SSD on external controllers, only? Can we partition SSDs on an external USB-to-SATA controller and move them later directly to a SATA-bus without adjusting partition borders? We saw that “parted” would complain about misalignment when SSD partitions were prepared on a different controller.
  2. As many people discuss the importance of partition alignment for SSD performance – will we see a noticeable drop in performance when we read/write to “misaligned” partitions?
  3. We saw that at least a JMicron controller indicated a bundling of 8 logical 512 byte blocks into a 4096 byte (fake?) “physical block”. Another question might therefore be what happens after an installation and something is written by Grub to the first sector of a disk with GPT layout – and maybe assuming some wrong disk topology? This is not so far fetched as one may think; see the third link at the bottom for a disaster with an MBR.

I cannot answer all these questions in general. But in this article I will at least look a bit into performance issues and answer the last question for my test situation.

Continue reading →