[Openchrome-devel] [Bug 94797] K8M800/K8N800 (unsure which): OpenChrome crashes if viafb is not enabled

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94797

--- Comment #3 from Kevin Brace <kevinbrace at gmx.com> ---
(In reply to Roc Vallès Domènech from comment #0)

Hi Roc,

> Created attachment 122674 [details]
> kernel boot log.
> 
> Hardware: Benq Joybook R23E (really old laptop I got gifted recently)
> 
> Arch Linux (x86), Linux 4.4.5.
> 
> If I boot with viafb disabled, starting X freezes the whole system.
> Xorg.0.log doesn't get a chance to be written to disk.
> 
> If I boot with viafb enabled, it's fine. Therefore I suspect some
> initialization (or modesetting?) is done properly by viafb, but openchrome
> driver can't do it on its own.
> 
> I attach log of 0.3.3, 0.4.0 (before release, built last evening due to
> testing request), and kernel boot (w/viafb enabled).
> 
> Note that this problem was already present in 0.3.3.

Thank you very much for testing the newly released OpenChrome Version 0.4.0.
Since there are only so many VIA hardware I can get a hold of, as a developer,
I do appreciate the feedback from the users of OpenChrome.
It is definitely okay to compare how OpenChrome Version 0.4.0 fares against
Version 0.3.3, but just to make it clear to other people reading this post
(Roc, I am not criticizing you or being hostile to anyone, just for the
record.), I will not maintain or fix any bugs with Version 0.3.3 since it is
really broken, and all development and bug fixing efforts will center around
Version 0.4.x and newer versions from now on.
    Just to summarize the issue, this is my understanding of the bug you are
reporting.

- X Server boots fine with OpenChrome Version 0.4.0 if viafb is enabled 
- X Server crashes with OpenChrome Version 0.4.0 if viafb is disabled 
- When X Server crashes, it does not record Xorg.0.log

Let me know, if I missed something.
Obviously, at this point, I do not know the exact cause of the bug, but I think
your speculation that OpenChrome is not initializing all the internal registers
on its own and viafb happened to be doing this for OpenChrome, is probably
reasonable.
Just for your information, I do know that connecting your laptop's S-Video
output to a TV will likely cause a boot time hang, and if you happened to have
an S-Video capable TV, it will be nice if you can test it.
Based on my own testing, connecting the RCA video output to a TV caused a boot
time hang, and I assume the result is similar with S-Video.
    I only "discovered" this in the past week or so, but as far as display
initialization is concerned, viafb source code is probably the most complete
source that documents the hardware registers of VIA UniChrome and Chrome9 IGPs
since VIA never released hardware programming documents other than CX700 /
VX700, VX800, VX855, and VX900 to the public (i.e., without requiring an NDA).
I only got a commit privilege for freedesktop.org OpenChrome repository around
February 9th, 2016, and had to concentrate on fixing DVI to VGA adapter screen
detection problem, removing "known device table," and getting rid of OpenChrome
legacy mode setting code for the past 2 months.
Personally, I will like to pad myself in the back for your K8N800 chipset's LCD
detection working correctly based on what I see in the Xorg.0.log you have
uploaded.
When I removed the infamous "known device table" the previous developers were
using, it definitely broke the LCD detection for some people.
VIA does use a fairly low tech way to communicate from the firmware to the
device driver the existence of an LCD panel and its panel resolution.
I have to use this since many LCD panels do not have an I2C bus for automatic
detection, and this is probably why your panel is working in the first place.
    I am "trying to" take several days off from analyzing what is going on
inside OpenChrome since, I have to admit, working on fixing OpenChrome has
really consumed my life for the past 2 months.
I will be studying how VIA initializes the IGP, and hope to feedback what I
learned from it into OpenChrome moving forward.
Over the next few weeks, I will be rewriting the display detection portion of
the code completely since the previous developers did not do a good job of
allocating display resources and outputs (This is why they resorted to that
infamous "known device table" I have discussed, but even that has many
problems. This is why I need to rewrite the display detection portion.).
In that process, I expect to improve the display initialization code, so that
it will eventually fix the bug you reported.
Please do not expect immediate results since releasing OpenChrome Version 0.4.0
took a lot longer than I originally expected, and it is very difficult to
sometimes comprehend the code the previous developers wrote.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/openchrome-devel/attachments/20160402/bc18bad1/attachment.html>