I have a Dell Vostro 1510 laptop with Intel GMA X3100. I am using Ubuntu 9.04 distribution. I noticed that videos appeared very jagged and blocky in all video players - VLC, Totem, mplayer etc. However, after I followed the instructions here - https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4 - and reverted the driver to 2.4, videos appear smooth as expected. -- chipset: 965GM -- system architecture: x86_64 -- xf86-video-intel/xserver/mesa/libdrm version: xserver-xorg-video-intel affected version: 2.6.3 xserver-xorg-video-intel proper version version: 2.4.1 xserver-xorg: 7.4 part of glxinfo output: OpenGL renderer string: Mesa DRI Intel(R) 965GM 20090326 2009Q1 RC2 OpenGL version string: 2.0 Mesa 7.4 libdrm version: 2.4.5 -- kernel version: 2.6.28-13-generic -- Linux distribution: Ubuntu 9.04 -- Machine or mobo model: Dell Vostro 1510 laptop $ lspci -nn | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c) I am attaching pictures which highlight the difference. Please tell me if any more information is to be provided. Thanks.
Created attachment 27919 [details] Screenshot on driver version 2.4
Created attachment 27920 [details] Screenshot on driver version 2.6 (notice jaggedness in t-shirt)
Created attachment 27921 [details] xorg.conf, essentially empty
Created attachment 27922 [details] Output of dmesg
Created attachment 27923 [details] Xorg.0.log of driver version 2.4
If it's the tearing issue, it has been fixed in 2.8.0.
How do I verify that I am being affected by the same bug? Do I need to download a compile a newer version of the driver to verify, or is there some other method?
Try the latest driver, thanks.
I compiled the 2.8.0 version of the driver. Still no change - the jaggedness persists. I am attaching relevant files and screenshot. Thanks.
Created attachment 27983 [details] Screenshot on driver version 2.8
Created attachment 27984 [details] Xorg.0.log of driver version 2.8
Created attachment 27985 [details] Output of dmesg after driver 2.8
Created attachment 27986 [details] xorg.conf, after modifications for driver 2.8
Please note that it's a bit messy as I had to upgrade libdrm to version .12, which was installed in /usr and /. Consequently, I had to add /lib/xorg/modules to the ModulePath of X11 to load the 2.8.0 version of the driver. Please tell me if any more debugging is to be done.
Which video output is used, xv or others? If using xv, which xv adaptor is used, overlay or textured?
I am using xv output. If I use the adaptor 0 i.e. Textured, the video is jagged as usual. If, however, I use the adaptor 1 i.e. Overlay, there are no jagged edges and it looks perfect. I used mplayer -vo xv:adaptor=0 and 1 to switch between adaptors. I am attaching a screenshot of overlay adaptor for comparison.
Created attachment 28044 [details] Screenshot on driver version 2.8 xv overlay adaptor
> Created an attachment (id=28044) [details] > Screenshot on driver version 2.8 xv overlay adaptor The dimension of this image is different from others. It is jagged if enlarging the size of this image. BTW, do you also use xv output and textured adaptor when using driver 2.4? I wonder if it is a regression of textured video.
The screenshot is of different dimension because I took the screenshot from within mplayer. The display with overlay adaptor is definitely not jagged even in fullscreen (in mplayer) in driver 2.8. In driver version 2.4.1, both overlay and textured xv adaptors are properly displaying, not jagged.
I tested some videos on 965GM and I didn't see any difference between 2.4.1 and 2.8.0. If possible, could you do a git bisect?
I am not familiar with that process. Can you please link me to some guide, or explain the procedure in short? Thanks.
read manual for detail. for example git bisect start ------- start bisection git bisect good xf86-video-intel-2.4.1 ------- mark 2.4.1 as a good revision git bisect bad 2.8.0 ------- mark 2.8.0 as a bad revision It will bisect the tree and say something. Now compile the driver and test it. git bisect good --------- if it is good or git bisect bad --------- if it is bad to ask for next bisection.
I went through the complete process. I started out exactly as you told. After a certain point, all subsequent compiles were "bad". I had to compile around 8-10 times in all. However, the final result does not really look promising to me. This is the output of "git bisect bad" after 0 revisions were left to be tested -- $ git bisect bad e4cd9de2933ada3e2a4b43552729ae3a370128bf is first bad commit commit e4cd9de2933ada3e2a4b43552729ae3a370128bf Author: Carl Worth <cworth@cworth.org> Date: Wed Apr 15 16:14:03 2009 -0700 Add a NEWS files with release-notes for 2.7.0 It will be nice to have release-notes under revision control, as well being able to document issues in an obviously time-sensitive file, (as opposed to README where we were documenting some of this previously). :000000 100644 0000000000000000000000000000000000000000 c059c98adae38cc87d256139c633396aead71982 A NEWS Please tell me if I am making a mistake somewhere, or if the above is indeed useful.
I must have done something wrong the first time. After running through the whole bisect process a second time, I got something else as the "bad commit": $ git bisect bad 830bf916724afd21b7947f797c22a8c8aab7a0a4 is first bad commit commit 830bf916724afd21b7947f797c22a8c8aab7a0a4 Author: Eric Anholt <eric@anholt.net> Date: Mon Dec 29 13:42:44 2008 -0800 Don't touch the pipestat regs for detecting FIFO underrun. The kernel owns them. Since we don't perform any synchronization with the kernel on these regs, we could race with the kernel to write stale values and end up not having vblank interrupts enabled when somebody was waiting on one. :040000 040000 b5560984df61226ed3f9abdba87400b1b32d74a5 87e1216abe0563a17aa6f4e6700a73820f5cd20c M src
Thanks for your help. Could you double check if XV is jagged with 830bf916724afd21b7947f797c22a8c8aab7a0a4, however it isn't jagged without this commit?
I already did that, right, during the bisect procedure? Or are you asking me to compile the "latest" version but without this commit? In that case, can you please guide me how to do that? I am a git-n00b. Also how do I update my git tree to reflect the latest changes.. something like a svn up? Thanks.
(In reply to comment #26) > I already did that, right, during the bisect procedure? Or are you asking me to > compile the "latest" version but without this commit? The later. I was surprised that this commit causes the regression, so I want to make sure this commit is the real 'bad' commit. > In that case, can you please guide me how to do that? You can use git revert to revert this commit after 0 revision is left, then compile and test. > do I update my git tree to reflect the latest changes.. something like a svn > up? Thanks. git pull
After reverting that commit, I notice something strange. My video is totally corrupted and out of colour (please refer to the attached screenshot). However, this happens only the first time X starts. If I later restart X, then the video displays properly without any weird colours, or jagged edges. I am still unable to pinpoint whether this commit is the cause of the error. That is because, once I was able to revert the commit cleanly. However, the other time, it informed me there was some conflict while trying to revert. I am a bit confused.
Created attachment 28315 [details] Screenshot after reverting commit (distorted colours and display)
(In reply to comment #28) > I am still unable to pinpoint whether this commit is the cause of the error. > That is because, once I was able to revert the commit cleanly. However, the > other time, it informed me there was some conflict while trying to revert. I am > a bit confused. > You can use git branch with this commit to create a new branch then use git checkout to switch to the new branch, then test the new branch. After that, revert this commit from the new branch then test again.
I am now beginning to think that my testing method is bad. This is what I currently do after each git bisect good/bad -- export PKG_CONFIG_PATH=/lib/pkgconfig/:$PKG_CONFIG_PATH ./autogen.sh --prefix=/usr --exec-prefix=/ make sudo make install -- and then restart the X server. Is that enough to "reset" the graphics hardware? I am asking because I get different results each time I restart X, with same driver. Do I need to reboot my PC after each install of the driver? For example, I asked someone in irc #git to help me out with your instructions in comment #30, and this is what I was told to do -- http://git.pastebin.com/m173e2e41 At line no 8 where it says "test - must be bad", I first got the weird green bars which I previously pasted in attachment 28315 [details]. After restarting X server, the green bars disappeared, but the jagged edges were there. After restarting yet one more time, the video is perfect, no jagged edges. I am bit lost here so as how to proceed. The version 2.4.1 is perfectly fine always reproducible, the version 2.8.0 has the bug always reproducible, I just can't pinpoint the commit in between.
I tried the complete bisect procedure once again. This time I restarted X twice after every commit. Somewhere down the line my X got completely hosed, gdm refused to start. I had to boot from a livecd and recover. This is what I got from git-bisect though: $ git bisect bad 1f61e97904dfe5f8c08bb9f284cfdfe878f7e541 is first bad commit commit 1f61e97904dfe5f8c08bb9f284cfdfe878f7e541 Author: Zhenyu Wang <zhenyu.z.wang@intel.com> Date: Wed Dec 31 22:56:57 2008 +0800 UXA: Fallback to dri_bo_map() if pin failed This fixes VT switch issue with UXA after Eric's aae4008096399a0e84abc7c016b35092caf9db25 on 2D side. :040000 040000 87e1216abe0563a17aa6f4e6700a73820f5cd20c 7b5a43c1ce983877644b157e767af279a3b3bc53 Music/src I am really at a loss as to what I am doing wrong here. Please give me a method of "properly" testing between bisects. Thanks!
commit 79b6851148574419389ac8055b0c31b8bdac3ab3 Author: Eric Anholt <eric@anholt.net> Date: Wed Aug 5 12:45:16 2009 -0700 Fix sampler indexes on i965 planar video. We only set up one sampler, because all of our sampling is the same. By using a non-zero index for the other two samplers, we'd dereference (likely) zeroed data, resulting in using NEAREST filtering. This was a regression in 40671132cb3732728703c6444f4577467fa9223f which incidentally switched from having 6 samplers to 1. Bug #22895, #19856
*** Bug 21522 has been marked as a duplicate of this bug. ***
After pulling in the latest head and reinstalling, I can confirm that the issue is solved for me. The videos display perfectly now. Thank you so much for all your help.
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.