[Openchrome-devel] [Bug 96397] legacy modesetting removal breaks CLE266
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Mon Jun 6 07:18:26 UTC 2016
--- Comment #7 from Kevin Brace <kevinbrace at gmx.com> ---
There is a reason why I did not observe the bug your reported here.
I do not own a functional monitor that can do 1920 X 1080 resolution at my
The best I got that is working is capable of 1680 X 1050 maximum (Note: I
repaired this monitor by replacing the faculty "bulging" electrolytic
capacitors. It was made by Samsung, and it appears that Samsung tends to cut
corners on capacitor quality by using certain lousy Taiwanese vendor
capacitors.), and I did not observe a bug at this screen resolution.
Regarding the patch you have uploaded, I do not like the fact that you have
put back in many elements of the old rotten code into the patch.
The only way I can personally agree to handle this bug is to figure out why did
the so called "legacy mode setting" work in the first place, and borrow some
portion of the code to specifically fix the current mode setting bug for
I am not interested in bringing back alternative mode setting option into the
Git repository code since this is a very bad design decision (i.e., going back
to the UniChrome vs. OpenChrome schism that happened around Year 2005) that
OpenChrome developers (i.e., you were one of them) made back then.
I think you need to let such design go since everything is moving into
automatic display detection and configuration, and Luc Verhaegen was right on
I tend to agree with him on that point, and my work has been going in that
direction for the past 4 months.
I do not know how hard it was to bring back the old code back into the
current code (as of June 5th, 2016, Version 0.4.169), but if you merely
reported the bug, I definitely would have told you not to try to bring back the
old rotten code back into the current one I have been in the process of
cleaning it up for the past 4 months.
That being said, I certainly would not have minded to learn why the "legacy
mode setting" worked, and incorporate some aspects of the old code into the
mode setting code path for CLE266.
I am hoping that you can agree to the way I will like to triage the bug rather
than blindly bringing back the old rotten code you did with the proposed patch.
Since I have been focused on cleaning up the code for the past 2 months, in
addition to fixing the runtime screen resize bug, I have observed that
UniChrome (CLE266, KM400, etc) appears to be very sensitive to the change of
the display FIFO threshold values.
However, UniChrome Pro and Chrome9 appears far more robust, and based on this,
I honestly will not be surprised that UniChrome is buggy from a hardware
Just to let you know, I was planning to bump up the OpenChrome version to
0.4.901 (Release Candidate 2) in the next few days after I arrive at my
destination in preparation for the release of OpenChrome Version 0.5.
Since I fixed the runtime screen resize bug, this alone justifies a new
official version to be released.
I can consider fixing this bug with OpenChrome Version 0.6 since it affects
very few users (i.e., people who own a 1920 X 1080 capable monitor which is you
in this case).
I am going for a 5 week trip tomorrow, and I will be leaving my place in
the next 12 hours.
If you want me to bring a VIA Embedded EPIA-M mainboard (CLE266 + VT1622 TV
encoder), I can, but if I do not bring it with me, I will not have access to it
for the next 5 weeks.
Let me know in the next 10 hours if I need to bring it with me (I do not really
have room in my suitcase, but I might be able to bring it if you really want me
I am already bringing 3 pieces of VIA hardware with me for this trip.
I guess it shows how committed I am to improving and fixing OpenChrome.
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openchrome-devel