"Sliced" horizontal lines

lightbulbil · 13 September 2021 07:50

Very recently, something happened to my video definitions/card and now almost any screen update is “sliced” into horizontal short lines.
This is very visible in videos, but happens with everything.
It’s as if the screen updates in “pixel-chunks” instead of by individual pixels.

Any idea where I could start looking?

System:    Kernel: 5.10.61-1-MANJARO x86_64 bits: 64 compiler: gcc v: 11.1.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.10-x86_64 root=UUID=ca3a2abf-6aba-40bf-b701-158852e4fa8f rw quiet apparmor=1 
           security=apparmor udev.log_priority=3 
           Desktop: KDE Plasma 5.22.5 tk: Qt 5.15.2 info: docker wm: kwin_x11 vt: 1 dm: SDDM Distro: Manjaro Linux 
           base: Arch Linux 
Machine:   Type: Laptop System: LENOVO product: 20S1SD1800 v: ThinkPad T14 Gen 1 serial: <filter> Chassis: type: 10 
           serial: <filter> 
           Mobo: LENOVO model: 20S1SD1800 v: SDK0J40697 WIN serial: <filter> UEFI: LENOVO v: N2XET27W (1.17 ) date: 12/10/2020 
Battery:   ID-1: BAT0 charge: 49.9 Wh (96.9%) condition: 51.5/50.5 Wh (101.9%) volts: 12.8 min: 11.6 model: LGC 5B10W13905 
           type: Li-poly serial: <filter> status: Unknown cycles: 38 
           Device-1: hidpp_battery_0 model: Logitech Performance MX serial: <filter> charge: 5% (should be ignored) 
           rechargeable: yes status: Discharging 
CPU:       Info: Quad Core model: Intel Core i7-10510U bits: 64 type: MT MCP arch: Kaby Lake note: check family: 6 
           model-id: 8E (142) stepping: C (12) microcode: EA cache: L2: 8 MiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 36812 
           Speed: 677 MHz min/max: 400/4900 MHz Core speeds (MHz): 1: 677 2: 689 3: 684 4: 693 5: 679 6: 644 7: 650 8: 695 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Enhanced IBRS, IBPB: conditional, RSB filling 
           Type: srbds mitigation: TSX disabled 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: Intel CometLake-U GT2 [UHD Graphics] vendor: Lenovo driver: i915 v: kernel bus-ID: 00:02.0 
           chip-ID: 8086:9b41 class-ID: 0300 
           Device-2: Lite-On Integrated Camera type: USB driver: uvcvideo bus-ID: 1-8:4 chip-ID: 04ca:7070 class-ID: 0e02 
           Display: x11 server: X.Org 1.20.13 compositor: kwin_x11 driver: loaded: modesetting alternate: fbdev,vesa 
           display-ID: :0 screens: 1 
           Screen-1: 0 s-res: 5760x1200 s-dpi: 96 s-size: 1521x317mm (59.9x12.5") s-diag: 1554mm (61.2") 
           Monitor-1: eDP-1 res: 1920x1080 hz: 60 dpi: 158 size: 309x173mm (12.2x6.8") diag: 354mm (13.9") 
           Monitor-2: DP-2-2 res: 1920x1200 hz: 60 dpi: 94 size: 518x324mm (20.4x12.8") diag: 611mm (24.1") 
           Monitor-3: DP-2-3 res: 1920x1200 hz: 60 dpi: 94 size: 518x324mm (20.4x12.8") diag: 611mm (24.1") 
           OpenGL: renderer: Mesa Intel UHD Graphics (CML GT2) v: 4.6 Mesa 21.2.1 direct render: Yes 
Audio:     Device-1: Intel Comet Lake PCH-LP cAVS vendor: Lenovo driver: sof-audio-pci 
           alternate: snd_hda_intel,snd_soc_skl,snd_sof_pci bus-ID: 00:1f.3 chip-ID: 8086:02c8 class-ID: 0403 
           Device-2: Lenovo ThinkPad Dock USB Audio type: USB driver: hid-generic,snd-usb-audio,usbhid bus-ID: 1-5.4.4:12 
           chip-ID: 17ef:306f class-ID: 0300 
           Sound Server-1: ALSA v: k5.10.61-1-MANJARO running: yes 
           Sound Server-2: sndio v: N/A running: no 
           Sound Server-3: JACK v: 1.9.19 running: no 
           Sound Server-4: PulseAudio v: 15.0 running: yes 
           Sound Server-5: PipeWire v: 0.3.34 running: yes 
Network:   Device-1: Intel Comet Lake PCH-LP CNVi WiFi driver: iwlwifi v: kernel port: 4000 bus-ID: 00:14.3 chip-ID: 8086:02f0 
           class-ID: 0280 
           IF: wlp0s20f3 state: down mac: <filter> 
           Device-2: Intel Ethernet I219-V vendor: Lenovo driver: e1000e v: kernel port: efa0 bus-ID: 00:1f.6 
           chip-ID: 8086:0d4f class-ID: 0200 
           IF: enp0s31f6 state: up speed: 1000 Mbps duplex: full mac: <filter> 
           IF-ID-1: docker0 state: up speed: 10000 Mbps duplex: unknown mac: <filter> 
           IF-ID-2: veth2c0132a state: up speed: 10000 Mbps duplex: full mac: <filter> 
           IF-ID-3: vpn0 state: up speed: 10 Mbps duplex: full mac: N/A 
Bluetooth: Device-1: Intel AX201 Bluetooth type: USB driver: btusb v: 0.8 bus-ID: 1-10:7 chip-ID: 8087:0026 class-ID: e001 
           Report: rfkill ID: hci0 rfk-id: 2 state: up address: see --recommends 
Drives:    Local Storage: total: 506.18 GiB used: 165.06 GiB (32.6%) 
           ID-1: /dev/mmcblk0 maj-min: 179:0 model: 00000 size: 29.24 GiB block-size: physical: 512 B logical: 512 B type: SSD 
           serial: <filter> scheme: MBR 
           SMART Message: Unknown smartctl error. Unable to generate data. 
           SMART Message: Unable to run smartctl. Root privileges required. 
           ID-2: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: MZVLB512HBJQ-000L7 size: 476.94 GiB block-size: 
           physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter> rev: 5M2QEXF7 temp: 51.9 C 
           scheme: GPT 
Partition: ID-1: / raw-size: 476.64 GiB size: 468.09 GiB (98.21%) used: 165.06 GiB (35.3%) fs: ext4 dev: /dev/nvme0n1p2 
           maj-min: 259:2 
           ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%) used: 296 KiB (0.1%) fs: vfat dev: /dev/nvme0n1p1 
           maj-min: 259:1 
Swap:      Alert: No swap data was found. 
Sensors:   System Temperatures: cpu: 48.0 C mobo: N/A 
           Fan Speeds (RPM): cpu: 3381 
Info:      Processes: 345 Uptime: 3d 18h 8m wakeups: 39 Memory: 31.02 GiB used: 12.28 GiB (39.6%) Init: systemd v: 248 
           tool: systemctl Compilers: gcc: 11.1.0 alt: 10 clang: 12.0.1 Packages: 1417 pacman: 1414 lib: 366 flatpak: 0 
           snap: 3 Shell: Bash v: 5.1.8 running-in: konsole inxi: 3.3.06

Fabby · 18 September 2021 09:18

Does this only happen on-screen or also in screenshots? (just humour me and take a screenshot and look at the screenshot on another computer / your phone)

Can I have the contents of all the files in /etc/X11/mhwd.d/ too, please?

lightbulbil:

           Monitor-1: eDP-1 res: 1920x1080 hz: 60 dpi: 158 size: 309x173mm (12.2x6.8") diag: 354mm (13.9") 
           Monitor-2: DP-2-2 res: 1920x1200 hz: 60 dpi: 94 size: 518x324mm (20.4x12.8") diag: 611mm (24.1") 
           Monitor-3: DP-2-3 res: 1920x1200 hz: 60 dpi: 94 size: 518x324mm (20.4x12.8") diag: 611mm (24.1")

Have you tried this on one monitor only?

Probably unrelated to your issue but please read this…

lightbulbil · 18 September 2021 19:26

Hi,

Thanks for your response.
I tried capturing the “hiccups”, but they don’t get captured. I even tried recording the screen with OBS, but the video comes out clean. So nothing with any value to share here.

What do you mean by “one monitor”?
My setup consists of a Lenovo T14, connected to a Lenovo docking station, which is connected to the other two monitors.
The “line stutter” happens on all screens, including the built-in laptop screen.
What is the test you’d like me to do?

There’s nothing in /etc/X11/mhwd.d. The folder exists, but it’s empty.

Thanks for the comment about swap. I’ll look into it.

Fabby · 18 September 2021 19:45

That’s valuable info: so it’s the output only, not the internal VRAM.

Obviously, disconnecting the laptop from the docking station would be the easiest way to check it on “one monitor” of the 3 monitors I listed.

ls /etc/X11/xorg.conf.d/

winnie · 18 September 2021 20:43

For Intel graphics, it’s good to rule out if using “triple buffering” can resolve (or partially improve) such video artifacts and lines.

Here is the contents of my custom /etc/X11/xorg.conf.d/99-intel.conf

Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "TripleBuffer" "true"
  Option "TearFree" "true"
EndSection

I use a combination of TearFree and TripleBuffer.

You need to logout and login for it to take effect, or preferably reboot after making the changes.

I can only vouch for 60Hz and 75Hz refresh rates, as I do not have a 144Hz (or higher) monitor in my possession. Not sure how this can translate for multiple monitors, or if you need to define a Screen section.

As @Fabby alluded, you can run a test without the dock or any externally connected monitors, and see if there’s a notable difference by using the laptop monitor exclusively, as a process of elimination (with and without the above option for triple buffering.)

Since you’re using KDE, another place to look that can be used in conjunction with the driver settings is under Settings → Display and Monitor → Compositor

You can adjust the Latency and Rendering Backend.

lightbulbil · 19 September 2021 08:02

Same issue when disconnecting the laptop from the docking station.

total 16
drwxr-xr-x 2 root root 4096 Aug 20 01:39 .
drwxr-xr-x 5 root root 4096 Apr 10 13:08 ..
-rw-r--r-- 1 root root  345 Apr 13 00:51 00-keyboard.conf
-rw-r--r-- 1 root root  131 Apr 10 13:09 30-touchpad.conf
lrwxrwxrwx 1 root root   41 Aug 20 01:39 50-tablet.conf -> /usr/share/X11/xorg.conf.d/50-tablet.conf

lightbulbil · 19 September 2021 08:07

These are my “Compositor” settings.
I’ll try and play with them a bit, but I have no idea what I’m doing.
Do they seems reasonable to you?

lightbulbil · 19 September 2021 08:14

Here’s another piece of information that might be useful:
I tried to changed the “Rendering Backend” from OpenGL 2.0 to 3.0, and the display became very slow to respond.
This is something that’s been happening recently, so I knew how to solve it:
I opened the “Display configuration”, and rearranged my screens, moving the leftmost screen (the laptop screen) to the right of the other two screens, and applied the changed. Display went back to normal. I then moved the laptop screen back to its original place (leftmost) and applied. Display is good.

I’ve seen this issue (Slow display response) happen recently multiple times, after playing games.
Making a significant change to the display, makes the display come back to life.

Not sure what all this means, but I’m assuming it’s all related.

BTW, switching to OpenGL 3.0 didn’t fix the “breakup” bug.

Fabby · 19 September 2021 12:53

@winnie was correct: you don’t have an intel.conf
Remediate that first , go back to OpenGL 2.0 and reboot afterwards. Then we’ll take it from there…

lightbulbil · 19 September 2021 13:22

I added the .conf file (does it have to be 99?), and it seems to have helped, from the simple test that I ran.

Thanks!

I guess it’s the tearing. But why was it okay up until now, and only started tearing recently?

winnie · 19 September 2021 13:51

That’s awesome to hear! It doesn’t have to pre-pend with “99-”, but I use “99” to sort of mark the custom files I created manually, rather than those that are included in a distro/package (e.g, “10-”, “20-”, “40-”).

I also employ this little trick to be able to migrate or review my custom system-wide configs.

Perhaps changes in driver development, and a combination of GPU, monitor, kernel, etc? I tend to have the best results with it on Intel graphics.

Fabby · 19 September 2021 15:20

Therefore, I’ve marked this answer as the solution to your question as it is by far the best answer you’ll get.

However, if you disagree with my choice, please feel free to take any other answer as the solution to your question or even remove the solution altogether: You are in control! (If you disagree with my choice, just send me a personal message and explain why I shouldn’t have done this or or if you agree)

P.S. In the future, please don’t forget to come back to your question after your issue has been solved and click the 3 dots below the answer to mark a solution like this below the answer that helped you most:

so that the next person that has the exact same problem you just had will benefit from your post as well as your question will now be in the “solved” status.

lightbulbil · 19 September 2021 15:41

Thanks for marking the solution.

I was reluctant to mark it, as I’m not 100% sure it’s fixed yet.
But I guess your approach it more practical. If I see that it’s not resolved, I’ll come back and unmark the solution.

Thanks again for your time and attention.

Fabby · 19 September 2021 15:42

Exactly! You still have 3 days…