The hardware is a laptop with a 1024x768 panel (LVDS). Unfortunately I have access to this hardware about 1 week/year and that is usually used up just getting it to work at all. Nevertheless I'll try to put up an overview of the issues and progress I had with the openchrome driver, sorry if it's a bit long a unsorted. The biggest annoyance is how so many debug options have been removed, making it near impossible to just hack things to avoid all the auto-detection code that is not working. That in addition these options were never removed from the man page wasted a significant amount of time in addition. Starting point was around Ubuntu 10.04 when the driver as far as I remember just worked. In Ubuntu 12.04 it was necessary to use the VBEModes option to get it to work again (otherwise the screen would be corrupted and even switching to another VT would fail to fix it). In 16.04 (0.3.3 driver with patches?) that just started to crash with VBEModes, so I had to find a workaround... It seems the issue is a bad modeline, the first one is the one added by the driver, the second one the proper one that Windows uses that I added manually: Modeline "1024x768"x59.9 63.50 1024 1072 1176 1328 768 771 775 798 -hsync +vsync (47.8 kHz UeP) Modeline "1024x768"x60.0 65.03 1024 1056 1192 1344 768 771 777 806 -hsync -vsync (48.4 kHz) It is somewhat worrying that the first mode-line breaks things so badly that not even switching back to a console VT can restore things to working. Even with this, XVideo is no longer not working (neither with nor without DRI, nor with or without DMA - DMA if enabled prints errors). So the next attempt was to use the 0.5 driver from the Ubuntu 16.04 hwe packages. That driver is completely unusable since it claims the panel is 800x600 panel and thus refuses to use the only good modeline from above. Unfortunately the option to override the panel size was removed, so I was unable to debug any further. Using git, things are broken even worse, it now claims there is no flat panel connected, but instead a TV is connected. The ActiveDevice option does not seem to work (also removed without removing from the man page?) so I haven't been able to do any useful testing with the git version. I'll should be able to selected logs that would be useful until Jan 5th, though faster progress/debugging would be possible if there many of the removed debugging options could be restored.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.