Bug 101395 - Color banding with OpenChrome driver V0.6.133
Summary: Color banding with OpenChrome driver V0.6.133
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/openchrome (show other bugs)
Version: 7.7 (2012.06)
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Kevin Brace
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-06-12 21:36 UTC by Marty
Modified: 2019-09-18 20:50 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Xorg log file (108.49 KB, text/x-log)
2017-06-12 21:36 UTC, Marty
no flags Details
Lubuntu 12.04 16-bit color desktop (165.96 KB, image/png)
2017-06-14 22:46 UTC, Kevin Brace
no flags Details

Description Marty 2017-06-12 21:36:09 UTC
Created attachment 131905 [details]
Xorg log file

Hi Kevin,

With the new Version 0.6.133 of the OpenChrome driver (from git repository) I see color steps in images. This is not related to resume/standby because it is also there after a complete reboot of the computer.

I tested that in more detail with that web-page (using Firefox):

http://www.lagom.nl/lcd-test/gradient.php

With the original OpenChrome driver of lubuntu 14.04 the gradient is completely smooth. With Version 0.6.133 I clearly see two rows of 64 bands each.

This page
http://www.lagom.nl/lcd-test/display_settings.php
says I would have a color depth of 24 bit. I get the same result (24 bit) with:
xwininfo -root | grep Depth

My system:
Fujitsu Siemens Amilo Li 1705
VIA VN896 chipset
lubuntu 14.04 (upgraded to 14.04.5, but I didn't use a point release, so it is not a HWE version)
OpenChrome V0.6.133

Best regards,
Marty
Comment 1 Kevin Brace 2017-06-14 22:46:17 UTC
Created attachment 131962 [details]
Lubuntu 12.04 16-bit color desktop

This is from Lubuntu 12.04 16-bit color desktop.
Comment 2 Kevin Brace 2017-06-14 22:53:03 UTC
Hi Marty,

Does the screen you are describing look like the screenshot I just uploaded?
Note that this screenshot was taken in 16-bit color mode.
I do not see this in 32-bit color mode.
Comment 3 Marty 2017-06-15 07:52:19 UTC
Hi Kevin,

Yes. This is exactly what I see! I even downloaded from Internet the original Lubuntu 12.04 wallpaper to do a closer analysis of the number of color steps in the image. It is identical to what you uploaded. So I can say everything looks like being in a 16 bit color mode.

Cheers,
Marty
Comment 4 Kevin Brace 2017-06-15 20:51:08 UTC
(In reply to Marty from comment #3)

Hi Marty,

> Hi Kevin,
> 
> Yes. This is exactly what I see! I even downloaded from Internet the
> original Lubuntu 12.04 wallpaper to do a closer analysis of the number of
> color steps in the image. It is identical to what you uploaded. So I can say
> everything looks like being in a 16 bit color mode.
> 
> Cheers,
> Marty

Okay, at least for 16-bit color mode, I have known this issue for a while, but there are reasons why I had to live with this flaw for OpenChrome DDX Version 0.6.
Prior to OpenChrome DDX Version 0.5 or 0.6, 16-bit color mode was broken if gamma correction hardware was turned on.
Turning on gamma correction was the reason why the colors went nuts in 16-bit mode, so I had to turn it off.
16-bit color mode is still useful in some cases, especially one wants to use dual head mode with left and right screen (As I have discussed previously, due to hardware limitations, you will need to use 16-bit color mode if one wants to use 2 monitors side by side.).
At the end of the day, since I am the only one who gets to decide what goes into the code (because I am pretty much the only person on this planet that spends so much time in trying revive old, abandoned graphics device drivers), I had to make tradeoffs, and since there had to be a new version of OpenChrome released at some point, I had to ship a new version with this color gradient flaw.
My goal of OpenChrome development has always been to improve the quality of the code since Day One (sometime around mid-2015), and as far as I am concerned, the code is gradually getting to where it should be (i.e., The latest improvement in how display devices are detected which fixed the standby resume issue with your laptop's 24-bit FP interface to a VIA LVDS bridge chip.).
    Like the previous bug I have effectively fixed (i.e., standby resume 24-bit FP interface FP restoration bug), it might take a while for me to figure out how to fix the problem.
Since I practically do not use Lubuntu 14.04 at all, if you do not mind keeping Lubuntu 12.04 for now (until I fix the bug), that will be appreciated.
That being said, I tried the 16-bit color mode on Xubuntu 14.04 yesterday, and I did observe the same color gradient issue I saw on Lubuntu 12.04.
I will revisit what I did with the color palette and gamma control many months ago.
I think it will take a while to fix this issue, and I will also have to continue to devote some time to modernize the current OpenChrome DDX code so the code developed for OpenChrome DDX can be effectively shared with OpenChrome DRM.
Comment 5 Kevin Brace 2017-06-15 21:00:01 UTC
Hi Marty,

A few more comments.
If I understand it correctly, if you do not use xorg.conf, recent (since Year 2010) X Server all can run without xorg.conf.
It defaults to 32-bit color nowadays since everyone supports 32-bit color (24-bit color + 8-bit alpha).
The latest Xorg.0.log log file you attached to Bug 100679 (Titled: via_regs_dump after standby/resume Version 0.6.133) says that you are using 32-bit color mode.
I have only observed this gradient issue only when I used 16-bit color mode, and it appears only after getting past the log in screen (i.e., It does not appear during the log in screen. Only after I punch in the correct password, gradient problem shows up.).
Can you try to attach an external monitor since you laptop has a VGA connector to see what happens to the color?
Comment 6 Marty 2017-06-16 18:13:14 UTC
Hi Kevin,

Here are the results of my tests:

1. With LAPTOP ALONE I get ALWAYS color banding. Already with the log-in screen and also after log-in.

2. When I start the laptop alone but attach a CRT after the log-in I get color bands on the laptop LCD and at the same time NO color bands on the CRT. When I now lock the computer and go back to the log-in screen, both, the LCD and the CRT, show NO color bands! But when I log-in again it goes back to the behaviour before: color bands on the LCD, no color bands on the CRT.

3. When I connect the CRT right from the beginning (that means I boot the laptop with attached CRT) I NEVER get color banding! Everything is always smooth, on the LCD and CRT. Furthermore: When I disconnect the CRT after booting and log-in, the laptop LCD still remains without color banding!

I hope this anyhow says something to you...

Regards,
Marty
Comment 7 Kevin Brace 2017-06-25 22:25:17 UTC
Hi Marty,

Give me several weeks for me to figure out what to do about this problem.
In the meantime, I will continue to work on fixing other OpenChrome DDX issues, and develop the next generation OpenChrome DRM by importing code from OpenChrome DDX.
Comment 8 GitLab Migration User 2019-09-18 20:50:11 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/openchrome/old-bug-database/issues/22.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.