Prime-sync can't be enabled in xrandr to fix screen tearing

LxMaD · 2022-07-13 00:14:59

Hey everyone,

I experience some mild screen tearing which I'd like to try and fix. My laptop has an integrated haswell intel GPU (which I mainly use) and a GTX 860m which I only use with prime-run for gaming. To my understanding the intel-GPU drives both the laptop screen and the external HDMI-screen that I primarily use (looked into the xorg log which driver connects to which display output). I use KDE Plasma with Kwin

The guide on the wiki suggests fixing screen tearing by using prime-sync. I enabled nvidia-DRM which seems to have worked:

$ sudo cat /sys/module/nvidia_drm/parameters/modeset  
Y

I can't find any DRM related errors in dmesg or the xorg log. When I try to enable prime-sync I get the following error:

$ xrandr --output HDMI-1 --set "PRIME Synchronization" 1
X Error of failed request:  BadName (named color or font does not exist)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  11 (RRQueryOutputProperty)
  Serial number of failed request:  32
  Current serial number in output stream:  32

I've seen a few people get this error but none of the problems they had seemed to apply. I already use the modesetting driver. The nvidia-settings menu doesn't display the option for prime-sync because I'm using prime-render offloading (I think that is the reason). I also couldn't really find any useful information on what this error actually means, so maybe this would be a first step to understand what is going on.
My "xrandr --prop" doesn't mention anything regarding prime-synchronization at the moment, so maybe that is the problem (however I don't know how to fix that).

HDMI-1 connected primary 1920x1200+1920+0 (normal left inverted right x axis y axis) 520mm x 320mm
        EDID: 
                *EDIDNUMBER*
        max bpc: 12 
                range: (8, 12)
        content type: No Data 
                supported: No Data, Graphics, Photo, Cinema, Game
        Colorspace: Default 
                supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater
        aspect ratio: Automatic 
                supported: Automatic, 4:3, 16:9
        Broadcast RGB: Automatic 
                supported: Automatic, Full, Limited 16:235
        audio: auto 
                supported: force-dvi, off, auto, on
        link-status: Good 
                supported: Good, Bad
        CTM: 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 
                0 1 
        CONNECTOR_ID: 85 
                supported: 85
        non-desktop: 0 
                range: (0, 1)
   1920x1200     59.95*+
   *other resolutions*

If you need any additional logs or have another way to fix tearing please let me know.

I have another quick question: sometimes it feels like my mouse takes a split second to wake up (maybe this is imagination). I'm using a wired gaming mouse. I followed the USB autosuspend article on the wiki but I am not sure if this is working or not. Do you know if there is a way to display whether any powersettings are being enforced or not? I found "udevadm info -a /sys/class/usbmisc/hiddev0", 1, etc. which displays "ATTRS{power/runtime_suspended_time}=="0"" but I am not sure if that is the only place to look.

V1del · 2022-07-13 06:55:44

PRIME sync won't fix anything if both displays are driven by the intel GPU, it's explicitly for the case where the external display is actually attached to the dedicated GPU. Also are both outputs using the same refreshrate? If the laptop display is significantly higher and you only see the tearing on the secondary screen then that's a limitation of X. Is the KWin compositor enabled? Check it's settings maybe post

qdbus org.kde.KWin /KWin org.kde.KWin.supportInformation

Also many people misname "tearing" what's the exact artifact you see? It should be a horizontal line while moving windows and such. Is it visible on a (phone/camera) screen recording?

As for the secondary question, if you adjusted the option for the usbcore module you can check what the parameters are set to under "/sys/module/usbcore/parameters/autosuspend" and "/sys/bus/usb/devices/$device/power/autosuspend" where you replace device with the bus/device you want to look at. Note that TLP and laptop-mode-tools and similar have their own configurations for handling these, so if you are using those then chances are that whatever you are setting is overwritten by them and you need to adjust the configuration there.

Last edited by V1del (2022-07-13 06:58:29)

LxMaD · 2022-07-13 11:51:45

Thank you so much for your input. I assumed prime-sync would help because the wiki states "When using PRIME, the primary GPU renders the screen content / applications, and passes it to the secondary GPU for display.". Is that out of date or did I misunderstand what is happening? (In my case the "primary GPU" should be the nvidia card used by prime-run and the secondary GPU is the intel GPU which got both displays assigned, I thought?)

KDE Settings is showing both the internal and external HDMI monitor using 60Hz, they also can't go higher than this as this setup is a little older. This shouldn't be a problem.

Here is the pastebin of the KWin information. Yes, the compositor is enabled but I think it might be automatically disabled by fullscreen applications (don't know if that matters): https://pastebin.com/6rDZH7Gq

I may have fallen victim to also misusing the term tearing. When I first noticed it it looked like a line but it wasn't quite horizontal (diagonal from top left to bottom right, which I also can't explain why). In trying to get some more fps I used the launch parameter -vulkan on csgo which didn't work before but now it seems like it works and the artifact is gone. So I guess it is some openGL problem? That artifact, whatever it is, is also clearly visible in the openGL screen recording you suggested but I guess I got a fix by using vulkan.

All of that said, do you know what the error xrandr outputs actually means? Can't prime-sync be enabled because my monitor is not connected to the nvidia gpu which is running the game? Shouldn't the syncing of the display output and the rendering be the main use of prime sync? I would love to understand whether this is a case of cannot run or miss-configured.

Thank you for your input on the mouse energy saving. My udev rule looked like this (I also put the controller etc. in there but I shortened it for a better overview):

# blacklist for usb autosuspend
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0951", ATTR{idProduct}=="1729", GOTO="power_usb_rules_end" #the ID of my mouse

ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"
LABEL="power_usb_rules_end"

I now changed to line to "ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="0951", ATTR{idProduct}=="1729", ATTR{power/autosuspend}="-1", GOTO="power_usb_rules_end"", hopefully this is right. I'll keep an eye on it, but thanks for pointing out where to look. I didn't install TLP nor laptop-mode-tools so unless there is something present in KDE this should probably be the only place.

MrJake · 2022-10-25 05:53:35

Did you manage to fix your issue with tearing?

V1del · 2022-10-25 06:47:40

Judging by the last reply they did, if this is an attempt at getting support for your own problem, please make a new thread instead of hijacking an existing one and detail your setup: https://wiki.archlinux.org/title/Genera … _hijacking

MrJake · 2022-10-25 09:51:21

No they didn't. They've only fixed the "secondary" mouse issue. Not a word about fixing the tearing issues.

V1del · 2022-10-25 12:13:51

...That artifact, whatever it is, is also clearly visible in the openGL screen recording you suggested but I guess I got a fix by using vulkan

Generally speaking, running a game on a xorg server from steam will disable the compositor on KDE, which will by definition of the matter introduce tearing, which in normal cases should be eliminated by the fact that you enable vsync in the game / via the vulkan context that normally enforces this. If you still get tearing under these conditions and having checked that then you can look at if/how PRIME sync is exposed by the xorg server (... you also should generally use the modesetting driver built into xorg here, I'm less than sure how well tested this is on xf86-video-intel)

seth · 2022-10-25 13:04:22

OP never had a tearing issue:

I may have fallen victim to also misusing the term tearing. When I first noticed it it looked like a line but it wasn't quite horizontal (diagonal from top left to bottom right, which I also can't explain why).

Sounds like tiling and was likely xf86-video-intel caused.

On top of that the OP was confused about VSYNC on a single GPU and prime-sync and it's not clear from any post whether anyone here is using reverse prime to begin with (the OP suggested "no") nor whether this is a multiscreen issue (chances to sync to more than one output are slim), so the entire tearing thing is this thread is vastly underspecified.

Arch Linux

#1 2022-07-13 00:14:59

Prime-sync can't be enabled in xrandr to fix screen tearing

#2 2022-07-13 06:55:44

Re: Prime-sync can't be enabled in xrandr to fix screen tearing

#3 2022-07-13 11:51:45

Re: Prime-sync can't be enabled in xrandr to fix screen tearing

#4 2022-10-25 05:53:35

Re: Prime-sync can't be enabled in xrandr to fix screen tearing

#5 2022-10-25 06:47:40

Re: Prime-sync can't be enabled in xrandr to fix screen tearing

#6 2022-10-25 09:51:21

Re: Prime-sync can't be enabled in xrandr to fix screen tearing

#7 2022-10-25 12:13:51

Re: Prime-sync can't be enabled in xrandr to fix screen tearing

#8 2022-10-25 13:04:22

Re: Prime-sync can't be enabled in xrandr to fix screen tearing

Board footer