Created attachment 77247 [details] Xorg.0.log Hi, since updating openchrome on my Amilo Pro V2030 (running EL 6.4) to version 0.3.0-3.20120806git, image corruption appears. I have also tried the latest version from git, which did not fix the issue. Xorg.0.log and picture are attached.
Created attachment 77250 [details] picture of the issue also happens with latest upstream version (git) and ubuntu 12.10.
Created attachment 77251 [details] picture of the issue
RHEL 6.4 (and clones) are using an openchrome snapshot between 0.3.0 and 0.3.1. RHEL 6.3 and earlier were using 0.2.904, this is a huge gap. It would be nice if you can bisect the regression or at least try 0.2.905 and 0.2.906. Also, can you please provide the X log from 0.3.2 (which is at this point similar to git master) ?
hi, builds of 0.2.905 and 0.2.906 fail because of: via_accel.c:37:22: error: xaalocal.h: No such file or directory it seems as if the current version of xorg-x11-server-devel-1.13.0-11.sl6.i686 does not include xaalocal.h anymore. any help on building it anyway is much appreciated.
Created attachment 77272 [details] 0.3.2 Xorg.0.log
XAA has been removed from X server 1.13, that's why 0.2.905 and 0.2.906 are not building. It might be possible to backport some fixes to allow building without XAA, I'll try to take a look. Meanwhile, can you try to run 0.3.2 without 2D acceleration ? You need to use Option "NoAccel" in your X configuration.
NoAccel does not solve the problem.
Created attachment 77663 [details] Xorg.0.log with noaccel true
So, I've now compiled a KMS kernel based on those instructions: http://www.freedesktop.org/wiki/Openchrome/TtmGemKms Does not work, image corruption (different now) still appears. I'll attach logs regarding this issue.
Created attachment 77940 [details] Xorg.0.log with custom compiled kernelTtmGemKms )
Created attachment 77941 [details] picture of the issue (custom compiled kernelTtmGemKms ) please note that the above data from today all appeard in combination with via.modeset=1. ill also provide data for if via.modeset=0
Created attachment 77942 [details] Xorg.0.log with custom compiled kernelTtmGemKms and via.modeset=0
Created attachment 77943 [details] picture of the issue with custom compiled kernelTtmGemKms and via.modeset=0 heres the picture belonging to the issue. the cursor corruption can be probably solved by using swcursor besides of that, colors are unreal (too much blue, too much red), there's a little bit of image corruption in the middle of the background and sometimes there also was a translucent scientific logo in the middle everywhere.
Created attachment 77944 [details] screenshot of the issue (glxgears) with custom compiled kernelTtmGemKms and via.modeset=0 I just realized that you can even take normal screenshots of the issue. I found it interesting that you can't spot the red wheel in glxgears, here's another screenshot from it.
Created attachment 77949 [details] kernel log with custom compiled kernelTtmGemKms drm.debug=255 and via.modeset=1
Hello. The image corruption deals with the hardware cursor. I have seen this issue as well on my VX900 laptop but it doesn't happen all the time. Because of this I haven't been able to track down the problem. If you run into this problem all the time then we might be able to solve it. Also I never seen it in UMS mode like you have which tells me the same cursor bug exist for both the KMS kernel and the xorg UMS code for the cursor. Does this show up only on the LVDS or when you have external monitor plugged in? As for the wrong colors that is a kernel drm bug for the second display. I have seen it recently with my multiscreen testing for KMS.
I tried using an external monitor but it does not work in any scenario (black image) - either because of the VGA-port being defective or a bug in the driver.
Created attachment 79651 [details] [review] Fix colors on second crtc Can you try this patch against the drm-opernchrome tree. This should fix the wrong color issues you see. The cursor is still not fixed. I thing it is a initialization issue.
drm-openchrome tree with that patch (via.modeset=0) shows the same behavior.
Created attachment 79659 [details] Xorg.0.log with patch from comment #18 applied
Created attachment 79660 [details] screenshot with patch from comment #18 applied (blueish, watermark)
Can you try with modeset=1. This patch only impacts KMS mode setting
with via.modeset=1: colors ok, image still blurry.
Can you post Xorg.log and dmesg.
Created attachment 79673 [details] dmesg with patch from comment #18 applied and via.modeset=1
Created attachment 79674 [details] Xorg.0.log with patch from comment #18 applied and via.modeset=1
Created attachment 80515 [details] picture of issue with patch from comment #18 applied and via.modeset=1 heres another picture of the issue. any chance that it gets fixed?
Created attachment 80581 [details] [review] Turn off secondary cursor by default. Here is a patch for broke cursor issue. Let me know if you can now use the second cursor.
Created attachment 80582 [details] [review] Test patch to see if LVDS is TTL I have been thinking about why your LVDS is blurry. It could be a TTL based LVDS. Please try the test patch attached.
applied the "Test patch to see if LVDS is TTL", and it works - great. Not sure what the cursor patch is supposed to do (applied it, though), as far as I know the cursor issue only appeard with via.modeset=0 (I have taken out the swcursor option in xorg.conf)
Created attachment 80870 [details] Xorg.0.log with patches from 2013-06-09
Created attachment 80871 [details] dmesg with patches from 2013-06-09
Much better. Could you post the output of dmidecode. I can use that output to handle your LVDS special case.
Created attachment 81236 [details] dmidecode sorry for answering late, heres the dmidecode output
Thanks. I updated the drm-openchrome tree to handle your case automatically.
It appears that this issue was resolved. I will be closing the bug.
If the problem persists with the latest OpenChrome DDX UMS code, let us know.
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.