reverse prime produces corrupted output on specific resolutions

Bug #1892136 reported by Aleksander Miera
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Unknown
xorg-server (Ubuntu)
Fix Released
Undecided
Aleksander Miera
Focal
Fix Committed
Undecided
Timo Aaltonen
Hirsute
Fix Released
Undecided
Unassigned
Impish
Fix Released
Undecided
Aleksander Miera

Bug Description

The issue has initially been discovered for resolution 1366x768 on a DisplayLink (evdi)-backed device, but applies also to UDL, as well as reverse prime setups (rendering on Intel, output through NVidia).

The issue manifests with 1366x768 and several other resolutions only, due to the fact that the GPU seems to use 64-aligned framebuffer stride. This is "accidentally" fine with the most popular VGA resolutions (e.g. assuming 32bits/4bytes per pixel and FullHD, the stride would be 1920*4 -> 7680, which is divisible by 64 w/o a remainder, yet 1366*4=5464, 5464/64 = 85.375). The proposed fix is to update the stride with the GPU-provided value instead of the Xorg-calculated one at the stage of sharing the pixmap between GPUs. Doing that at earlier stage would probably require distinguishing between allocation of a FB and a generic pixmap, which is the same for Xorg.

Issue for sure was seen on 18.04 and 19.04, probably still there for 20.04.

Upstream report:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/889

And posted (not yet integrated) fix:
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/496

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Please note that 19.04 is no longer supported. It would be nice to know for sure if 20.04 is still a problem.

Changed in xorg-server (Ubuntu):
assignee: nobody → Aleksander Miera (amiera)
tags: added: bionic
Changed in xorg-server (Ubuntu):
status: New → In Progress
Revision history for this message
Aleksander Miera (amiera) wrote :

Just reproduced on 20.04.
xserver-xorg-core:
  Installed: 2:1.20.8-2ubuntu2.2
  Candidate: 2:1.20.8-2ubuntu2.2

No reproduction on 20.10 build, but it was tested on a different machine and issue might be hw-dependent. Te be confirmed on the same computer soon.

tags: added: focal
Revision history for this message
Aleksander Miera (amiera) wrote :

Managed to reproduce on fresh download 20.10, too. OTOH, I remember seeing that gone in some cases on 20.04. I wonder what the exact cases are, as apparently this seems more complicated than "reproduces always".

tags: added: groovy
Revision history for this message
Aleksander Miera (amiera) wrote :

@vanvugt is there any chance this gets merged? Preferably on Xorg's end, if you can give me a hint on whom to tag there it would be most appreciated.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

It appears the Xorg developers already know about it. I don't know enough about it myself to recommend Ubuntu jumps ahead of them on this.

Revision history for this message
Aleksander Miera (amiera) wrote :
Revision history for this message
Aleksander Miera (amiera) wrote :
tags: added: fixed-in-1.20.10 fixed-upstream
Changed in xorg-server (Ubuntu):
status: In Progress → Fix Committed
tags: removed: groovy
Changed in xorg-server (Ubuntu Impish):
status: Fix Committed → Fix Released
Changed in xorg-server (Ubuntu Hirsute):
status: New → Fix Released
Changed in xorg-server (Ubuntu Focal):
status: New → Fix Committed
assignee: nobody → Timo Aaltonen (tjaalton)
Changed in xorg-server:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.