|Summary:||Display artifacts when using MST|
|Product:||DRI||Reporter:||Dan Doel <dan.doel>|
|Component:||DRM/Radeon||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED MOVED||QA Contact:|
|i915 platform:||i915 features:|
Description Dan Doel 2015-11-17 08:10:23 UTC
Created attachment 119730 [details] image 1 - half of window uses different colors I've been trying out the support for tiled MST monitors on Radeon drivers, and seem to be encountering some visual anomalies that seem like they are likely to be related to this component. My setup is two UP2414Q monitors, which have native resolutions of 3840x2160. Over DisplayPort 1.2, they are capable of running as two 1920x2160@60 displays each. I have a nvidia card that is capable of driving them in this mode, so I am reasonably sure that the hardware isn't the problem (unless it is the Radeon card, but that seems unlikely). First, there seems to be a color anomaly with the primary display. The right half of the display has different colors from the left (see first image). I noticed that this may be due to the left half displaying a different color depth than the right. The second image shows the gnome overlay, and while the shadows are smooth on the right, there is banding on the left. My second monitor seems to have both sides in this reduced color mode, and enough fiddling with settings after a boot causes both halves of the primary monitor to be configured that way as well, but needless to say, the reduced color depth (if that's what it is) is undesirable. Second, the secondary monitor has some visual artifacts to the left of center (a vertical band about an inch wide) as well as to the far right (a vertical band around 1/4 inch wide). The third image should give some idea what it looks like. A better photo might show that things in that region look somewhat interlaced, and are repeated horizontally. I apologize for the poor quality of the images, but screenshots don't capture these artifacts, so I had to use my phone. I'm running with packages from Fedora 23, so xorg-server 1.18.0, xf86-video-ati 7.6.0-0.4.20150729git5510cd6, kernel 4.2.5-300. If you'd like any other information, let me know.
Comment 1 Dan Doel 2015-11-17 08:10:58 UTC
Created attachment 119731 [details] image 2 - color banding on half of display
Comment 2 Dan Doel 2015-11-17 08:11:40 UTC
Created attachment 119732 [details] image 3 - interlacing/smearing near center of display
Comment 3 Dan Doel 2015-11-17 23:43:51 UTC
I realized I'd forgotten a couple potentially relevant details. First, the duplication artifact seems to be related to the overall coordinates. I switched cables (and thus DP outputs) at the monitors, but putting the desktop in the same layout gives the same artifacts. Also swapping things so that the right half of the monitor is logically to the left of the left half seems to switch the duplication artifacts (i.e. they happen at roughly the same logical coordinates, not physical coordinates). Second, my card is a Radeon 7870, for reference. Also, I've now tried the modesetting driver (so that I can have the tiled displays work as one logical display), and experience the same anomalies with it; both color depth mismatch on the left monitor (I previously described it as 'primary', but perhaps it is more relevant that it is the monitor with a +0 X offset), and the duplication on the right monitor (with a +3840 X offset) occur. So the problem is not specific to the xf86-video-ati portion of the driver.
Comment 4 Dan Doel 2015-11-19 03:44:55 UTC
I've conducted some tests with respect to the color oddities on the left-most/main monitor. First, colorizing a blank image in gimp gives a way of seeing the color disparity in a decent manner. When changing the hue step by step, it's possible to see the colors becoming closer and farther apart from one another, which would make sense if the color depths are different, I think. I was never able to make the colors match exactly. I'm unsure if it's ever possible to get a color to display the same when approximated to 24 bit and 16 bit color. Next, it occurred to me that the issue may be gamma or brightness, because even white on the right half of the monitor was 'more white' (or, brighter) than white on the left. However, regardless of what I set these to on the left half of the monitor using xrandr, the white was not as bright as on the right half. I'm unsure if color depth is a sensible explanation for this, as I wouldn't expect 16-bit white to be 'less white' than 24-bit white. Finally, some other issues have led me to cause mode resets in which the main monitor gets laid out logically backwards, so that the right half of the monitor is the left half of the desktop. When this happens, the right half of the monitor then gets put in the 'low' color mode, and is stuck there until a reboot. So it seems that the color oddity is somehow related to _ever_ being laid out with a positive x offset (since the entire right monitor is in this mode from the start). I don't know if any of this is helpful, but I thought I'd document it for whoever eventually looks into this stuff.
Comment 5 Dan Doel 2015-11-21 16:42:34 UTC
So, just to complicate matters, I've now had the left monitor get its right half unstuck from the low-color mode. Yesterday, both halves of the left monitor were in the low-color mode. After waking up the monintors, the left half of the monitor was rather garbled. So I did a layout switch and reverted to hopefully reset the monitors. This fixed the left half and somehow put the right half back into the mode it usually boots up into, where white looks brighter, and there is no color banding. I don't think I've ever seen it do this before, so perhaps it was somehow related to the garbling of the screen (though I doubt I'll be able to reproduce that reliably).
Comment 6 Martin Peres 2019-11-20 08:03:04 UTC
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/967.