<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Many regressions for K8M800 on Acer Aspire 1362LC" href="https://bugs.freedesktop.org/show_bug.cgi?id=104438#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Many regressions for K8M800 on Acer Aspire 1362LC" href="https://bugs.freedesktop.org/show_bug.cgi?id=104438">bug 104438</a> from <a class="email" href="mailto:kevinbrace@gmx.com" title="Kevin Brace <kevinbrace@gmx.com>"> Kevin Brace</a> <pre>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 <a href="show_bug.cgi?id=104438#c2">comment #2</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>