Details of the X-stack:
Build Date: 5-Jan-2008
mesa/drm: master (git)
mesa/mesa : 7.2
xorg/driver/xf86-input-keyboard - 1.3.0
After installing the driver , check 'glxinfo' and make sure the driver is installed properly and DRI is enabled.
And then run 'glxgears'
*** It results in blank window! (attached screen shot)
Created attachment 21672 [details]
Created attachment 21673 [details]
Created attachment 21674 [details]
Created attachment 21675 [details]
Created attachment 21676 [details]
couldn't attach screen shot due to large size. But anyway it is just a blank window.
Other observations are:
- I can't play a video with 'mplayer -vo gl' or 'mplayer -vo gl2' options where as I can play with 'mplayer -vo xv' option
- I also can't play games like urban terror, as I just see a blank window!
Increasing the priority and severity
All the above mentioned problems are not appearing with 29-DEC-2008 build
Created attachment 21677 [details]
Mplayer Run logs
This log contains ,
- mplayer run with "-vo xv" option which works fine
- mplayer run with "-vo gl" and "-vo gl2" options which FAIL
(In reply to comment #7)
> All the above mentioned problems are not appearing with 29-DEC-2008 build
So, please try and isolate which change in which component caused it. I think xf86-video-ati is the most likely candidate.
I am providing some additional info for better resolution:
- The last working build for me was on 29-DEC-2008 on Ubuntu-8.04
- I upgraded my system to Ubuntu-8.10 and did a fresh git on 5-JAN-2009
then the reported problem appeared.
For cross checking I performed below things:
- I used the same working source code of 29-DEC-2008 and built the entire X-stack against Ubuntu-8.10, same result, failed!
- Another observation is that I get the same problem on openSUSE-11.0 using 5-JAN-2009
Attaching logs of 'glxgears' and 'mplayer' with LIBGL_DEBUG=verbose
Created attachment 21714 [details]
glxgears run with debug=verbose
Created attachment 21715 [details]
mplayer run with debug=verbose
Are there any drm related messages in your kernel log?
(In reply to comment #13)
> Are there any drm related messages in your kernel log?
Attaching the 'grep -i drm kern.log' output.
There are some lines of this statement: (only seen on 5th Jan time stamp)
"Jan 5 20:21:34 sunil-desktop kernel: [17156.029451] [drm] wait for fifo failed status : 0x9803C100 0x00080000"
Created attachment 21742 [details]
drm kernel logs
I rebuilt my Xserver with some older "libdrm-2.4.1" and still i get the same problem!
The only major change I did was upgraded my system to Ubuntu-8.10 from Ubuntu-8.04.
I will revert back to Ubuntu-8.04 and try again if it works again like before.
I freshly installed an Ubuntu-8.04.1-LTS and the code base git'ed on Jan-12th.
**It works fine**. I can see 'glxgears' and few other opengl apps working fine.
Now the question is why it is not working on Ubuntu-8.10 and OpenSUSE-11.0 ?
(In reply to comment #17)
> Now the question is why it is not working on Ubuntu-8.10 and OpenSUSE-11.0 ?
Perhaps an issue with the newer kernel on these systems? Does the DRI work if you leave the stock drm modules and only upgrade the userspace portions?
Now I found the culprit! :-)
My xorg.conf has the Virtual field set to a higher value for some other purpose, and didn't change it back to a lower value!
- Virtual 4096 4096
After reducing the value to 'Virtual 1024 1024' all of the reported problems have gone.
- glxgears works fine
- mplayer with gl/gl2 works fine
But only drawback for me is I get very few Resolutions supported for using with the driver when Virtual value is low.
What optimal value should I keep?Any advice?
Can I close the bug?
(In reply to comment #19)
> Now I found the culprit! :-)
> But only drawback for me is I get very few Resolutions supported for using with
> the driver when Virtual value is low.
> What optimal value should I keep?Any advice?
Until we finish the unified memory manager, you'll have to change the virtual settings based on your usage patterns. Set the Virtual size large enough to handle the largest dualhead setup you plan on using. For 3D you may want to set it lower to free up more resources for textures and such.
> Can I close the bug?
Thanks Alex for clarification.
closing the bug...