[Openchrome-devel] [ANNOUNCEMENT] OpenChrome Version 0.4.0 is almost ready

[Kevin Brace]

Hi Sebastian,

> Date: Thu, 31 Mar 2016 04:27:47 +0200
> From: Svenska <svenska-ml at arcor.de>
> To: openchrome-devel at lists.freedesktop.org
> Subject: Re: [Openchrome-devel] [ANNOUNCEMENT] OpenChrome Version
> 	0.4.0 is almost ready
> Message-ID: <56FC8B23.1090502 at arcor.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi,
> 
> I have tested the current master branch (1203f32) on my "One A110" 
> netbook (Quanta IL1, VX800) without any xorg.conf.
> 
> What works:
> - internal display (800x480, detected as LVDS-1)
> - VGA connector (including hotplug)
> - panning (within limits, see below)
> - mouse pointer
> 
> This is already a big step forwards - thank you!
> 
> Complicated mode changes and advanced features crash, e.g:
> $ xrandr --output LVDS-1 --off --output VGA-1 --preferred
> $ xrandr --output LVDS-1 --scale 0.5x0.5
> 
> Multi-Monitoring does not work, e.g:
> - "--output VGA-1 --right-of LVDS-1" makes LCD show garbage
> - then, trying to turn off LCD results in a crash
> 
> Panning works even with both displays active (that is, VGA shows full 
> 1280x768 image, and LVDS shows a 800x480 moving subimage). This is 
> useful when applications don't cope with small resolutions.
> 
> Approaching the untested boundaries of darkness (e.g. enabling panning 
> for framebuffers of 2048x2048 or larger) leads to dragins (garbage, 
> crashes, strange behaviour).
> 
> ACPI standby seems broken (display fades to white), but since the whole 
> system crashes as well, there might be other factors involved as well.
> 
> I did not test XVideo.
> 
> In my opinion, this version is still a major step forward from version 
> 0.3.3 and I am thankful for that.
> 
> Best Regards,
> Sebastian
> 

I am glad OpenChrome Version 0.4.0 is working for the most part (I know I still need to fix several more bugs to be truly stable as a graphics device driver. That's my ultimate goal. Computer is a tool to do something, and people should not have to agonize over software bugs of OSS platform.).
Sebastian, did Version 0.3.3 require an xorg.conf file to be usable?
I do plan to start looking into why the device driver crashes when the screen resolution is changed, and along with the HP T5550 DVI to VGA adapter bug.
It will be nice if you can file a bug report with freedesktop.org (http://bugs.freedesktop.org) over the RandR and screen resolution related bugs.
I am also willing to fix the ACPI S3 State bug eventually, and I wanted to work on this (Did some experimentation over this issue around December 2015, but was not able to fix the bug completely.), but all the time resources got sucked away fixing the DVI related bugs.
It will be nice if you can file that bug (ACPI S3 State resume bug) separately.
    For Version 0.4.0, I took a huge risk by removing "known device table" (I do not mean to claim credit, but I think that is the appropriate term for such a thing.), VBE mode setting, and "legacy" mode setting (That's the way the source code used to call it. It appears to be an alternative mode setting path that can be activated via xorg.conf, but for CLE266 chipset, it is turned on by default.).
It appears that another K8M800 chipset laptop owner had a success with flat panel detection (This person filed a separate bug report unrelated to flat panel detection.), so removing these 3 undesirable features (in 2016 standards) did not materially worsen the device driver stability and usability.
    The secret of the code major rewrite success is due to myself obtaining Sylvania gnet 13001 netbook (I spent $35 USD on ebay.).
When I tested OpenChrome with this one, I discovered that the flat panel it had did not have an I2C bus connection for automatic detection.
Instead, I discovered that OpenChrome was using a strange backdoor "hack" way to detect the panel native resolution.
When I removed the known device table, every chipset was now running through this backdoor "hack" code, and it was leading to a regression.
I think this is what Xavier Bachelot was making an issue out of recently.
Eventually, I did notice that VGA resolution detection was going wrong on some desktop platforms, and I did not want to introduce the known device table back, so I looked around for a more reliable way to detect flat panels without I2C bus.
It is definitely a policy of mine not to do commits that will lead to a regression, but it will inevitably happen between a release.
Eventually, I figured out a way VIA Technologies was doing automatic detection of a flat panel without an I2C bus (scratch pad register - basically a mailbox register coming from BIOS setup), and implemented that.
To give James Simmons and VIA credit, they were both actively using this scratch pad register for panel detection, and to my surprise, OpenChrome already had most of the code to do this, but it was not being utilized effectively (The "hack" code had to fail before scratch pad register was read, but this almost never happened.).
I did not have to write too many lines to activate this, and that was nice.
    Because I already wrote a lengthy reply to Xavier's post a few days ago, I will not want to criticize him too many more times (one big one is enough), but it is my personal view that I would not have been able to remove those 3 features that should have never been in the code in the first place without Xavier being AWOL for so long.
Ultimately, these features go back to the original UniChrome and OpenChrome schism / fork from year 2005 or so (Luc Verhaegen who was one of the major developers of UniChrome has told me that VBE was one of the major issue, although Xavier may have a different story.), and I personally will like to put that unfortunately history to rest (I was not a party to that dispute. I only learned about it within the past month or so.), and focus on improving VIA hardware Linux / BSD support.
With OpenChrome Version 0.4.0, there was a virtual philosophical unification of UniChrome and OpenChrome code base, in my opinion.
Again, I wish not to criticize Xavier too often from now on, but he has talked about submitting a patch to Fedora with the one of the 3 legacy feature revived for OpenChrome Version 0.4.0 ("legacy" mode setting for CLE266 chipset).
I believe the issue was fixed before the Version 0.4.0 release, so I do not think it is a good idea to create further confusion over this matter.
It is my view that we should let the VIA hardware users report how the new and improved code is doing, and fix a bug within the new code base rather than reviving difficult to maintain code and idea from the past.