[Openchrome-devel] xf86-video-openchrome: src/via_display.c src/via_driver.c src/via_driver.h src/via_lvds.c src/via_outputs.c

Wed Apr 6 03:00:02 UTC 2016

Hi Xavier,

> Sent: Tuesday, April 05, 2016 at 12:59 PM
> From: "Xavier Bachelot" <xavier at bachelot.org>
> To: "Kevin Brace" <kevinbrace at gmx.com>, openchrome-devel at lists.freedesktop.org
> Subject: Re: [Openchrome-devel] xf86-video-openchrome: src/via_display.c src/via_driver.c src/via_driver.h src/via_lvds.c src/via_outputs.c
>
> Hi Kevin,
> 
> Will do. I just sent a note as soon as I observed the regression on my
> setup and I know this is definitely not enough to debug the issue.
> Meanwhile, I've confirmed this is the faulty commit.
> Actually, I think I already stumbled on this very bug long time ago when
> James rewrote some part of the code and that's why CLE266 was reverted
> to legacy mode setting to avoid introducing a regression. Not sure why
> we did not fully debug this, but there was so many moving parts at the
> moment, we probably ran out of time then forgot about it to concentrate
> on KMS.
> I'm probably going to ship openchrome 0.4.0 on Fedora with a patch to
> revert the legacy mode setting removal. Indeed, this is only a temporary
> workaround, I don't want to maintain out of tree patches unless
> absolutely necessary and will remove it asap.
> 

I do not want to sound mean, but I recommend that you don't bother.
While I am committed to supporting old hardware like CLE266 in OpenChrome, it is very unlikely that this will affect anyone that uses Fedora.
If I am correct, Fedora official release is already AMD64 (x86-64) based, so one cannot physically use it with CLE266 chipset in the first place (assuming that stock kernel is used).
CLE266 chipset was almost always mated with VIA Technologies C3 processor, and C3 did not even support PAE.
In fact, my CLE266 testing was performed only on Ubuntu 10.04 LTS, since software cursor will not be displayed with Lubuntu 10.04 at this point (obviously a bug).
As far as official stock kernel is concerned, Ubuntu 10.04 LTS generation was the last one that supported non-PAE 32-bit x86 processors, so that is the only one I can do any testing.
OpenChrome does not work well with Ubuntu 8.04 LTS, so I have not been able to test it against it (I fixed a few bugs, so it can at least be compiled against it. However, it does not work.).
People who use Gentoo Linux might be able to compile OpenChrome Version 0.4.0, and test it without PAE.
At least this person got OpenChrome Version 0.4.0 working with CLE266.

https://lists.freedesktop.org/archives/openchrome-users/2016-April/007260.html

    Besides that, I did remove every part of the code that dealt with VBE mode setting, "legacy" mode setting, and known device table without breaking the code too much (the side effect from this was also repaired before the Version 0.4.0 release).
In some ways, 3 of these are intertwined in a really bad way, and it is not a good idea to bring it back.
Because it is a major break from the older broken version, I call it Version 0.4.0 rather than Version 0.3.4.
I already crossed the Rubicon with Version 0.4.0, and nobody is going backwards.

https://en.wikipedia.org/wiki/Crossing_the_Rubicon

When I did the commit that removed the known device table, I thought about the above phrase when I did it.
Of course, I knew you will not really like it.

> I don't particularly care about VBE, nor legacy mode setting. Less code,
> less bug :-)

I suppose Luc Verhaegen will disagree with you on that one.
Of course, that was then (11 or so years ago) and now.
Just for the record, I have e-mailed him over the UniChrome vs. OpenChrome a little while ago, and told me his side of the story.

> On the other hand, the known devices table might be a bit more
> problematic for older laptops. It was used in the first place to allow
> enabling otherwise undetectable LVDS panel.

OpenChrome already had the code infrastructure to support LVDS flat panels without I2C bus.
It is the scratch pad register interface that can pass the panel size from the BIOS setup.
I personally do not like this design, but VIA frame buffer device driver code they donated in 2008 or 2009 uses this, and James Simmons was also using this in the new DRM module (drm-openchrome).
I simply got rid of the strange code that was trying to do backdoor screen resolution detection, and now rely on the panel value the BIOS setup writes to the scratch pad register.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=6375a34fa3c8e413aafb6f161a19195571da1434

> That being said, I
> completely agree this is/was a maintenance burden, I've been trying to
> keep it up to date for years, and I'm more than happy to see it go.
> Hopefully the code you added is enough to handle such cases. This is
> definitely something that people with the hardware need to test, and
> that's not my case.
> 

Although I probably should not get into the e-mail I received from you in September or October 2015 since it probably was assumed to be a private conversation, back then you did not really sound enthusiastic for me to even to meddle with that VIA_VM800 parameter typo, and the reason that was given was something like it will mess up the known device table.
It was around that time I wanted to get rid of that monster, and I finally did it in March 2016.
In general, I did not really get a good response to the patch I sent to you, and until now, this was the only e-mail I received from you.

> One cannot test every possible hardware and software setup, and bugs
> will fall through the cracks. This did happen numerous time already and
> will happen again :-)
> 

Yes, but keeping that "known device table" is for this long was much worse of a design decision than myself getting rid of it at this point with possible side effects manifesting itself.
To be honest, other than removing VBE and "legacy" mode setting and "known device table," I did not really add that many lines of code thus far.
Most of the code is still there.
All I did was carefully rewrite some portions of it, so that it handles display detection mostly automatically.
This shows that if people who wrote the code cared a little more about what they were doing, it would have worked much better without that huge table.
Besides, the bug related to the known device table was causing many VIA hardware to not work with all Linux distributions since pretty much all of them now have Version 0.3.3.
Jeffrey Walton really wanted new release due to this, so I had to release an imperfect version (i.e., VX900 chipset and DVI issues).

> > Although I probably should not get personal, I will need to let you
> > know that I sent you 4 e-mails between October 2015 to December 2015
> > regarding OpenChrome. It appears that you choose to ignore all of
> > them. You are under no obligation to explain why you choose to do
> > this to me, but personally, I think it is very unprofessional to
> > completely ignore me this way. While I sent several e-mails to James
> > Simmons around the same time, at least he has completely disappeared
> > since January 2015 or so.
> > 
> Sorry about that, but please note I did not ignore you, I was unable to
> answer and I did already explain why in a private mail to you and a
> couple other people involved or looking to get involved with openchrome
> at the very beginning of the year, and I'm not going to repeat on a
> public mailing list. I'm sorry if you feel offended, that was
> definitively not the intention.

Although I will not want to sound vindictive, I have a hard time believing what you are saying.
Even if you had technical issues with your e-mail account (I have no way to verify this, but it is quite possible.), you should have known since November 2015 that I have been posting patches on bugs.freedesktop.org.
In fact, you posted a comment in December 2015 over at openchrome-devel.

https://lists.freedesktop.org/archives/openchrome-devel/2015-December/001588.html

Obviously, I was not happy to see this posting since I have tried to contact you multiple times to no avail.
Again, at least for James Simmons, he has completely disappeared, so he is consistent.
I had to interpret this as you not really liking my contribution (i.e., patch) to OpenChrome, and may have even hoped that I will somehow go away.
This is why I still think that you intentionally ignored me for whatever reason, and this obviously slowed me down.
This only hurts users who want bugs fixed.
Besides, why did the e-mail you sent to Benno Schulenberg even have to be private?
I do not plan to post the portions I received from him, but I think you could have been more open with OpenChrome project management since you were the only one who did not completely disappear and had commit privilege at that time.
Instead, I had to embarrass myself in public.

http://www.phoronix.com/scan.php?page=news_item&px=OpenChrome-Maintainer-Hope

This is why I wrote what I wrote in the reply to you (I also sent it to the mailing list so it is public record.).

> On a related note, don't take it personal either, but I sometime feel
> you're a bit unfair and unnecessarily rude to the previous developers
> and it would be beneficial to everyone to not judge too quickly.
> Anyway, no need for drama on any side, thanks for doing the much needed
> work and inflating some life again into openchrome, this is much
> appreciated.
> 
> Regards,
> Xavier
> 

For my own sake, I personally wanted what happened to be on record, and that is what I wanted to do in case people are wondering why OpenChrome is still so underdeveloped and broken.
I am not too surprised that you are not happy with the criticism of the code, and that is understandable.
While I am an opinionated person, I am not a mean person, but that being said, as someone who has worked on trying to fix OpenChrome since July 2015, I have been battling broken and unmaintainable code for the past 8 to 9 months.
Obviously, from time to time, I cannot help but to criticize the code quality of OpenChrome, and it is not really surprising that OpenChrome developers did not get along with Luc Verhaegen over this issue.

http://markmail.org/message/vutzfc65va4h554r#query:+page:1+mid:x4bp6vxkd7kmf3sh+state:results

Maybe Luc is a difficult person to get along with (possible, but I don't know), but I think very short sighted software design decisions were made in 2004 to 2005, and we (VIA hardware users and myself) are still paying the price 11+ years later.
Maybe all the OpenChrome developers who forked UniChrome code (i.e., you, Thomas Hellström, and others excluding James Simmons, of course) owe Luc Verhaegen an apology.
It is ironic that 11+ years later, OpenChrome philosophically is starting to resemble UniChrome, again.

Regards,

Kevin Brace