<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - legacy modesetting removal breaks CLE266" href="https://bugs.freedesktop.org/show_bug.cgi?id=96397#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - legacy modesetting removal breaks CLE266" href="https://bugs.freedesktop.org/show_bug.cgi?id=96397">bug 96397</a> from <a class="email" href="mailto:kevinbrace@gmx.com" title="Kevin Brace <kevinbrace@gmx.com>"> Kevin Brace</a> <pre>Hi Xavier, 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 place. 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 CLE266. 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 that point. 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 perspective. 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 to. 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>