Summary: | radeon: annoying flashblacks | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | xorg | Reporter: | Elmar Stellnberger <estellnb> | ||||||||
Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||||
Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
Severity: | normal | ||||||||||
Priority: | medium | ||||||||||
Version: | 7.4 (2008.09) | ||||||||||
Hardware: | Other | ||||||||||
OS: | All | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Attachments: |
|
Description
Elmar Stellnberger
2009-10-13 10:37:33 UTC
please attach your xorg log and config. What GPU and driver version are you using? Created attachment 30352 [details] [review] Xorg.0.log xorg-x11-driver-video-7.4-83.3 Created attachment 30354 [details]
xorg.conf
can you try with ati from git master? Specifically commit 66b194a78c470cb3978f310828dd96c3f3e96944. Will xorg-x11-driver-video-radeonhd-1.3.0_20091009_8cbff7b-5.1 do it? What if I wanna install fglrx (currently no 3D support for Radeon Mobility HD 2700). Will it be sufficient to pack-up the /usr/lib64/xorg/modules directory? Please have a look at Bug 22114 and how the problem was resolved for radeonhd; the flashblacks are still there and very annoying (xorg-x11-driver-video-7.4-87.88.1). Please do have a look at Bug 22114 and how the problem was resolved for radeonhd; the flashblacks are still here and very annoying (xorg-x11-driver-video-7.4-87.88.1). Can you try xf86-video-ati from git master? Some flashblacks are still observable with xorg-x11-driver-video-7.4-138.1.x86_64 though they are somewhat less frequent and not that extremely annoying any more. Still very frequent and annoying by time. Singleton flashblacks seem to last longer though. Still extremely annoying with xorg-x11-driver-video-7.4-139.1.x86_64 (every now and then there are very little flashblacks for a while). I'm not sure what versions of the driver are in the distro packages you've mentioned. You best bet is to try xf86-video-ati from git master. Could you assist me in creating an xorg-x11-driver-video package with an updated radeon driver at #opensuse-buildservice? (https://build.opensuse.org/package/show?package=xorg-x11-driver-video&project=openSUSE:11.2, https://build.opensuse.org/package/show?package=xorg-x11-driver-video&project=home:estellnb) Then I could always test the git-master release. which .tar.bz2 will I have to replace by what? Will it be OK if I use xf86-video-ati-6.12.4.tar.bz2 from http://cgit.freedesktop.org/xorg/driver/xf86-video-ati ?? - how can I otherwise create the respective .tar.bz2 on my own? (In reply to comment #15) > Will it be OK if I use xf86-video-ati-6.12.4.tar.bz2 from > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati ?? > - how can I otherwise create the respective .tar.bz2 on my own? > That's 6.12.4. You need to grab the code from git from master or the 6.12-branch. See these instructions: http://wiki.x.org/wiki/radeonBuildHowTo as horrifying as before with the latest git release from yesterday. Which display is having problems? The built in laptop panel or the hdmi? The external HDMI, only. Created attachment 31693 [details] [review] possible fix Does this patch help? Unfortunately only one of four patch hunks has succeeded (https://build.opensuse.org/package/live_build_log?arch=x86_64&package=xorg-x11-driver-video&project=home:estellnb&repository=openSUSE_11.2, https://build.opensuse.org/package/live_build_log?arch=x86_64&package=xorg-x11-driver-video&project=home:estellnb&repository=openSUSE_11.2). How can I update an already checked-out git-branch of radeon? (In reply to comment #21) > How can I update an already checked-out git-branch of radeon? > git fetch git pull origin/<branch> so if you have master checked out: git fetch git pull origin/master > git fetch ... > git pull master fatal: 'master' does not appear to be a git repository fatal: The remote end hung up unexpectedly > git pull 6.12-branch fatal: '6.12-branch' does not appear to be a git repository fatal: The remote end hung up unexpectedly ... followed the description at http://wiki.x.org/wiki/radeonBuildHowTo (first two git commands) You need to have a xf86-video -ati git tree checked out. So the following should work: 1. git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-ati 2. download the patch in comment 20 and save it in the xf86-video-ati directory created by git clone 3. cd xf86-video-ati 4. patch -p1 -i bug24505.diff 5. ./autogen.sh --prefix=/usr 6. make 7. (as root) make install 3 out of 4 hunks failed - patch can not be applied to 6.12-branch: + /usr/bin/patch -s -p0 --fuzz=2 1 out of 1 hunk FAILED -- saving rejects to file xf86-video-ati/src/radeon.h.rej 1 out of 1 hunk FAILED -- saving rejects to file xf86-video-ati/src/radeon_atombios.c.rej 1 out of 3 hunks FAILED -- saving rejects to file xf86-video-ati/src/radeon_crtc.c.rej see also: Comment #21 (In reply to comment #25) > 3 out of 4 hunks failed - patch can not be applied to 6.12-branch: > + /usr/bin/patch -s -p0 --fuzz=2 > 1 out of 1 hunk FAILED -- saving rejects to file > xf86-video-ati/src/radeon.h.rej > 1 out of 1 hunk FAILED -- saving rejects to file > xf86-video-ati/src/radeon_atombios.c.rej > 1 out of 3 hunks FAILED -- saving rejects to file > xf86-video-ati/src/radeon_crtc.c.rej > see also: Comment #21 > Patch is against git master, not the 6.12-branch. Sorry, it is absolutely impossible for me to build the code from the master branch. It requires xorg-macros version 1.3 though I do only have version 1.2.2 available. Can you try with the latest code from xf86-video-ati git master? I just committed some new PLL code that might help. You can easily build the macros from source: http://cgit.freedesktop.org/xorg/util/macros/ git clone git://anongit.freedesktop.org/xorg/util/macros cd macros ./autogen.sh --prefix=/usr make sudo make install (In reply to comment #28) > git clone git://anongit.freedesktop.org/xorg/util/macros > cd macros > ./autogen.sh --prefix=/usr > make > sudo make install $ ./autogen.sh --prefix=/usr autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal autoreconf: configure.ac: tracing autoreconf: configure.ac: not using Libtool autoreconf: running: /usr/bin/autoconf autoreconf: configure.ac: not using Autoheader autoreconf: running: automake --add-missing --copy --no-force autoreconf: Leaving directory `.' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... yes checking for a BSD-compatible install... /usr/bin/install -c configure: creating ./config.status config.status: creating xorg-macros.pc config.status: creating Makefile config.status: creating xorg-macros.m4 $ make make: Nothing to be done for `all'. they are just macros so there is nothing to build. just install. What if I can not install on path due to missing privileges? may I install the macros into /usr/local as well? Is there any way to force the usage of /usr/local/share/aclocal/xorg-macros.m4 instead of /usr/share/aclocal/xorg-macros.m4? export M4=/usr/local/share/aclocal/xorg-macros.m4 autoreconf -fi autom4te: need GNU m4 1.4 or later: /usr/local/share/aclocal/xorg-macros.m4 aclocal: autom4te failed with exit status: 1 autoreconf: aclocal failed with exit status: 1 The environment variables AUTOCONF, AUTOHEADER, AUTOMAKE, ACLOCAL, AUTOPOINT, LIBTOOLIZE, M4, and MAKE are honored. any way to specify /usr/local/lib/pkgconfig/xorg-macros.pc? These might be useful: export ACLOCAL="aclocal -I /usr/local/share/aclocal" export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:${PKG_CONFIG_PATH} Unfortunately it still complains about a wrong m4 version although I have m4-1.4.13-2.2.x86_64 installed. Now it works (I wouldn`t have dared to think that we would succeed at last.). Is it true that the patch is already incorporated into the newest master release (have ceased to apply it); if yes - then You can expect the test results by the next day. What about installing radeon into /usr/local? Still there and extremely annoying for the latest unpatched build of the master branch. Perhaps you wanna have a look on how the problem was resolved for radeonhd. (In reply to comment #39) > Still there and extremely annoying for the latest unpatched build of the master > branch. Perhaps you wanna have a look on how the problem was resolved for > radeonhd. > You just said it worked in comment 38. Were you referring to the sources from git master? I think it should be fixed in git master, however, you will need to install the latest macros to built it. No, just building the new driver from the master-sources has worked for me in Comment #38. "If yes - then You can expect the test results by the next day. ": Hereby I told you that I can provide you with the test results no sooner than by the next day (before I kept trying to apply the patches to a non master-twig; that was why it didn`t work for so long). Even the newest radeonhd driver works fine in this regard. Perhaps you wanna have a look at the git changes between the stated versions (Comment #6) or simply ask the radeonhd developers. To me it looks as if the screen turned black due to some auto-configuration (like on switching the graphics mode). Still not resolved. What about another trial? Did you ever try xf86-video-ati from git master with the new pll code? Yes, in deed; see comments #42, #41 & #38. When it comes to test a new patch you should get the results by the next day. Now I know that I need to use the master branch and I have already gone through all this configuration issues. However I will be away now until 2009-12-28 so that tests in this time may get delayed. Is this still an issue with kms or a newer driver? Resolved for xorg-x11-driver-video-7.5-15.2.x86_64. |
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.