Hi. I currently use Debian wheezy on my laptop and filed a bug at the Debian BTS, with a patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717813 It looks like the bug is also in the current git. The code structure has changed since 0.2.906 (the version in Debian), but the patch I sent to Debian should be pretty straightforward to adapt to the new structure. I didn't make a new patch, but, as of right now, the code to be replaced is at line 1217 of http://cgit.freedesktop.org/openchrome/xf86-video-openchrome/tree/src/via_xv_overlay.c I haven't been able to test this with the new openchrome driver yet. All of the stable releases 0.3.x have resulted in my machine hanging --- not even alt-sysrq-b worked. (I haven't tried the latest from git.) But I guess that should be the matter of a different bug report...
Would it be possible to provide a sample video showing the bad behaviour ?
Created attachment 83092 [details] [review] Patch fixing bad colors with VLC http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=flipped-colors-in-some-videos.patch;att=1;bug=717813
Created attachment 83357 [details] a short video exhibiting the bug Here is a short video I got from youtube. (Downloaded using clive.) Playing this in vlc shows the sky as red, instead of blue.
Another thing that could be related: I've noticed that this video (and some others) don't play correctly in totem either. The image is distorted. The colors look like they are from the original image, because I can change the top from red to blue with the vlc patch. There are diagonal lines running from top right to bottom left, as if some buffer is being read in a wrong way (using the wrong length?). Curiously, after I've started totem, if I start vlc, then the colors in the first image appear correct even without the patch. But vlc gets stuck after the first image and doesn't play the video. It's as if totem is setting colors correctly somewhere that vlc can read, even though totem showed the wrong colors too. Pretty strange.
Comment on attachment 83357 [details] a short video exhibiting the bug (Edited attachment to change MIME type)
I couldn't reproduce the bug on both a VX800 and a VX900, but I can confirm it for VLC on a KM400. However, while the patch does fix VLC the KM400, it breaks it on the VX900 (not tried on VX800, but it's likely the same). Xine is unaffected in any case. For completeness, I could test against a CN400 and a CN700, but no time for that yet and I'm not sure it really worths it anyway. Another point is the VX800 and VX900 are both laptops (thus LVDS), while the KM400 is a desktop (VGA), but I think it doesn't matter as you've reported the bug for an LVDS output, while I tested against a VGA output.
-- 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/11.
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.