Hi everyone, I know that there recently was an article over at Phoronix that wrote about the state of OpenChrome.
http://phoronix.com/scan.php?page=news_item&px=OpenChrome-One-Dev-Roadmap It was probably a fairly low effort article written by Michael Larabel of Phoronix since he pretty much verbatim copied what I wrote at bugs.freedesktop.org when some anonymous person posted a question about xf86-video-modesetting and OpenChrome. https://bugs.freedesktop.org/show_bug.cgi?id=95524#c4 I guess I am a little sarcastic, but it must have been a slow news day for Michael. Since I have my usual "more than a month long" summer travel coming up soon, and I will be staying at a place about 60 miles from where Michael Larabel lives (he appears to reside in northern Indiana, USA). I plan to bring 3 pieces of VIA hardware with me, so the development will continue during the trip, but I will have fewer equipment to do testing before a commit. Personal matters aside, I wrote something like, "At this point, there is nothing newsworthy to write about OpenChrome." That was quoted by Michael Larabel, and it might imply that nothing is going on with OpenChrome. In practice, if one was following the OpenChrome Git repository, I have been making many small changes to the source code. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/log/ However, when I wrote the above comment, I was not sure when the runtime screen resize bug will be fixed. Anyway, after 2 months of struggle, yesterday I finally found the root cause of why changing the screen resolution from the OS causes the X Server to crash. I already committed the code changes, and I have confirmed that runtime screen resolution change now works reliably with CLE266, KM400, VN896, and VX800 chipsets. Furthermore, with this important fix, RandR is now working with OpenChrome, and in fact, I am writing this message using two monitors (one is a 15 inch VGA monitor and another one is my laptop's flat panel). The only limitation of the RandR and VIA IGP is that if one is using 32-bit color mode, one cannot have greater than 2048 dots in the X direction. What this means is that if your flat panel is 1280 dots wide, you will be limited to 2048 - 1280 = 768 dots on the second screen in the X direction. Practically speaking, when using 2 monitors, you will need to configure the first monitor as the top monitor and the second monitor as the bottom monitor. One might think of using a 16-bit color mode, but it appears that between Version 0.2.904 and 0.3.0, someone broke the code, and color palette appears to be messed up for the 16-bit color mode for now. If one used 16-bit color mode, you can have more than 2048 dots in the X direction (it appears to work fine), so I am thinking of fixing the palette bug in the next release. Please note that this limitation appears to be a hardware limitation of VIA IGP. While I am aware of the sensitivity of criticizing the past developers of OpenChrome, there has been total lack of QA (Quality Assurance) when doing commits. The runtime screen resize feature was broken by commit cee0a1fab9cade87e6de16c67cd34c84cf697531, yet no one seems to have noticed this for years. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=cee0a1fab9cade87e6de16c67cd34c84cf697531 I tracked down the runtime screen resize bug to this commit after doing several tests, but since I am not the original developer, it really took me 2 months to figure this out. Eventually, I compared the screen resize code to xf86-video-intel's screen resize code to figure out why the runtime screen resize was crashing. I will need to thank Intel Corporation employees for their contribution to the X Server development. If you wanted to test RandR, please download ARandR. I thank Eric Kudzin for letting me know about the existence of ARandR. Regarding the next release of OpenChrome DDX, please think of Version 0.4.158 as an RC (Release Candidate). I will do a few more code cleanups over the next week or so, but for now, I do not really plan to fix any further bugs for this release since it often takes weeks to months to fix just one bug. After that, the code will enter an official RC state when I bump up the code version to Version 0.4.901 since I once bumped up the version to Version 0.4.900 almost 2 months ago, but had to revert it back to a regular development version number. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=f160074511e8a2b51b72abc962b097fe94f8b71b Once OpenChrome Version 0.5 is out, there will be no support for Version 0.4 and older versions. As far as I know, Version 0.5 should be able to replace Versions 0.4 and 0.3.x safely. If you have a computer with VIA IGP, please start testing the latest code in the Git repository. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/ There are still a dozen or so bugs that need fixing, and I plan to post a development roadmap to the mailing list in the next couple of days. Regards, Kevin Brace OpenChrome Project Maintainer _______________________________________________ Openchrome-devel mailing list Openchrome-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/openchrome-devel
