All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@freedesktop.org
To: dri-devel@lists.freedesktop.org
Subject: [Bug 92977] Display artifacts when using MST
Date: Thu, 19 Nov 2015 03:44:55 +0000	[thread overview]
Message-ID: <bug-92977-502-gF7VcHu178@http.bugs.freedesktop.org/> (raw)
In-Reply-To: <bug-92977-502@http.bugs.freedesktop.org/>


[-- Attachment #1.1: Type: text/plain, Size: 1779 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=92977

--- Comment #4 from Dan Doel <dan.doel@gmail.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 2505 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2015-11-19  3:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17  8:10 [Bug 92977] Display artifacts when using MST bugzilla-daemon
2015-11-17  8:10 ` bugzilla-daemon
2015-11-17  8:11 ` bugzilla-daemon
2015-11-17  9:09 ` bugzilla-daemon
2015-11-17  9:10 ` bugzilla-daemon
2015-11-17 23:43 ` bugzilla-daemon
2015-11-19  3:44 ` bugzilla-daemon [this message]
2015-11-21 16:42 ` bugzilla-daemon
2019-11-20  8:03 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-92977-502-gF7VcHu178@http.bugs.freedesktop.org/ \
    --to=bugzilla-daemon@freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.