Bug 104438

Sorry to hear about many regressions you have experienced.
I do own Averatec 3250 with KN400 chipset, and I regularly test OpenChrome DDX and DRM against it.
The general policy I have towards code support is that I only deal with the latest code, and as a result, Version 0.5 code is already EOL.
Because of OpenChrome Project's focus on OpenChrome DRM development, I have been removing many of the manual options from OpenChrome DDX since many of them were not conceptually compatible with OpenChrome DRM.
No plans to fix Xv stuff at this time since I have no involvement in it since I started working on OpenChrome since late 2015.
TV out is known to be broken, but I plan to start rewriting the code in the next version.
    You will need to compile the latest OpenChrome upstream repository code for real support.

https://lists.freedesktop.org/archives/openchrome-users/2016-February/007237.html

When you compile the code, you will need to build package dependency.
You should replace xserver-xorg-video-openchrome with xserver-xorg-video-openchrome-hwe-16.04.
I will assume this laptop has VGA.
At least that should work.
Assuming VGA works, attach Xorg.0.log so that I can take a look at what is going on with the flat panel.
I was planning to go into OpenChrome DDX Version 0.7 RC (Release Candidate) soon, but this might delay it.
I am okay with delaying it if necessary.

Sorry for the long delay, the notification email got sorted in the wrong place :(
Which is really too bad, since you made the effort of replying so fast.
Sorry for messing this up, since it means I won't be able to test anything at least for months, so I guess at most it would be possible to discuss how to handle things next time.
I managed to build the development version (that's how I noticed it doesn't detect the flat panel at all anymore in that version).
Testing the VGA port is a good idea, I didn't even think of that (I do have ssh connection though, so not necessary for debugging).
The main concern I wanted to raise is: A lot of the auto-detection seems broken, and with the options to override them they can only be debugged one by one. Even if a made more of an effort, it seems to me the result will be that bugs will be added quicker than there's any chance of fixing them.
Sure, the options won't make sense and won't work for DRM (well, I actually would think they still make sense, just that they would need to be kernel options?), but why is that a problem? Though I admit if the DRM driver is expected to be "production ready" medium term it would be a waste of time.
In order to at least not just waste your time, I'll attach a patch that I THINK removes the options that no longer exist from the man page, to at least eliminate that source of confusion.
You should double-check that I haven't removed something that does still exist after all though.

Created attachment 136710 [details] [review]
Remove options no longer existing from man page

Hi Reimar,

I will commit your patch verbatim for Version 0.6.171.


(In reply to Reimar Döffinger from comment #3)
> Created attachment 136710 [details] [review] [review]
> Remove options no longer existing from man page

I checked the code, and I think I have an explanation as to how FP is detected.
For K8M800 chipset, OpenChrome DDX looks for two things, non-use of AGP (SR13[3]) and VIA Technologies VGA BIOS scratch pad register (CR3B[1]).
Note that SR stands for sequencer register and CR stands for CRTC register (IBM VGA terminology).
CR3B[1] = 1 (CR3B[3] = 1 for CLE266 chipset) is a must since this is a BIOS supplied indicator of the availability of a FP.
SR13[3] = 1 indicates AGP pins are being used as FP pins.
As far as I know, pretty much all chipset vendor adopted this "trick" of having pin multiplexed AGP / FP pins since significant cost of an IC is the package, and higher the pin count, the more expensive package needs to be used.
PC chipset is a fairly cost sensitive business, so reducing 50 or so pins from the package / I/O pad ring is important from cost perspective.
If both are not 1, then OpenChrome DDX thinks that there is no FP attached to the computer (i.e., desktop mainboard).
Although it does not happen very often, you can have a situation where VT1631(L) or VT1636 is attached to DVP0 or DVP1 (Digital Video Port), and currently OpenChrome DDX nor DRM support these I2C bus configured devices (Because I do not own a functioning device with these ICs. I am willing to support them if I had a board with them.).
Just for your information, I have a KM400 chipset based laptop (Averatec 3250), and FP is automatically detected with this one (it has 1024 x 768 FP resolution).
Between November to December 2017, I fixed a few outstanding issues of OpenChrome DRM with KM400 chipset (Many of my commits during that period was related to that.).
For FP detection, KM400 and K8M800 chipsets both go through the same code path.
What also complicates FP detection is that many computer vendors do not use I2C supported FPs, and if a FP is detected from the above detection method, OpenChrome DDX still needs to figure out whether or not it is using an I2C bus capable model or without I2C bus support.
If I2C bus is not available, then OpenChrome DDX code integrated FP screen resolution table is used in order to pick the appropriate FP screen resolution.
VGA BIOS supplies the panel index (0 to 15) and OpenChrome then sets the screen resolution from the table.
It is possible that the table value needs some adjustment, and I have seen this issue in the past.
As far as I know, this is the first report of FP detection failing with the panel detection method code I have written.
    As for how the development is done, I am trying to merge hardware specific basic code structure to be the same for both DDX and DRM.
As a result, manual setting features that existed in the past are being gradually removed.
Eventually, DDX and DRM will have largely identical mode setting behavior, although DRM will get greater attention since that will be the only thing important moving forward.
    Regarding the addition of new code adding new bugs, well that happens (It did happen with HP 2133 mini-note's PCIe WLAN not working for OpenChrome DDX Version 0.5, although after someone else pointed this out, I fixed it for Version 0.6.), although I try to fix new issues whenever I notice it myself or someone else complains about.


(In reply to Reimar Döffinger from comment #2)
> Sorry for the long delay, the notification email got sorted in the wrong
> place :(
> Which is really too bad, since you made the effort of replying so fast.
> Sorry for messing this up, since it means I won't be able to test anything
> at least for months, so I guess at most it would be possible to discuss how
> to handle things next time.
> I managed to build the development version (that's how I noticed it doesn't
> detect the flat panel at all anymore in that version).
> Testing the VGA port is a good idea, I didn't even think of that (I do have
> ssh connection though, so not necessary for debugging).
> The main concern I wanted to raise is: A lot of the auto-detection seems
> broken, and with the options to override them they can only be debugged one
> by one. Even if a made more of an effort, it seems to me the result will be
> that bugs will be added quicker than there's any chance of fixing them.
> Sure, the options won't make sense and won't work for DRM (well, I actually
> would think they still make sense, just that they would need to be kernel
> options?), but why is that a problem? Though I admit if the DRM driver is
> expected to be "production ready" medium term it would be a waste of time.
> In order to at least not just waste your time, I'll attach a patch that I
> THINK removes the options that no longer exist from the man page, to at
> least eliminate that source of confusion.
> You should double-check that I haven't removed something that does still
> exist after all though.

Reimar,

By the way, you can keep this bug report open until you have access to the laptop in question again.
By that time, I am sure OpenChrome DDX Version 0.7 will be available.
If it is a fault of OpenChrome, I will try to fix it for Version 0.8.
I will likely release Version 0.8 4 to 6 months after the release of Version 0.7.
Version 0.7 will be available around late February 2018 with how things are going.
Assuming that this is a panel index data issue, I will think that there will have to be a second panel screen resolution table for older models.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/openchrome/old-bug-database/issues/23.