Re: Sluggish 2D with radeon Xpress 200M
2009/4/27 Damien Mir mailings.x...@mirabel-sil.com With an old opensuse 10.0 with xorg 6.8 (32bit mode if relevant) on the same laptop, everything is stunning fast. With OS 11.1 xorg 7.4, although it is not really horrible or unusable, there's definitely something wrong, it feels a little sluggish in comparaison. Btw. glxgears gives about 780fps. This sounds a lot like my perf problems, though I don't have the exact same chip. I think Option AccelDFS true helped, I'm not sure. AccelDFS is enabled by default for PCI-E chips. In my case, no matter which option I tweak, I cannot get the very basic 2D performance I expected and got before, the slugishness increases in relation with the quantity of active windows on the desktops. (no flash or desktop effects, just static HTML and file management in KDE 3.5) could you post your /var/log/Xorg.0.log and /etc/X11/xorg.conf?! with also the output of the lsmod | grep radeon command? -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: New gotcha I just ran into, was radeonhd function missing
2009/3/18 Gene Heskett gene.hesk...@verizon.net: On Wednesday 18 March 2009, Beso wrote: 2009/3/18 Gene Heskett gene.hesk...@verizon.net: Greetings Beso; Sorry about getting sidetracked. I've cleaned up my busted edits in the script, and now have a new failure exit from the mesa build. gmake[4]: Entering directory `/usr/src/mesa/src/gallium/state_trackers/egl' gcc -I../../include -I../../auxiliary - I../../../../src/mesa/drivers/dri/common -I../../../../src/mesa - I../../../../include -I../../../../src/egl/main -I/usr/src/drm/build/include - I/usr/src/drm/build/include/drm -g -O2 -Wall -Wmissing-prototypes -std=c99 - ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM - DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN - DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING - DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -c -o egl_context.o egl_context.c In file included from egl_context.c:7: egl_tracker.h:131: error: expected specifier-qualifier-list before ‘drmModeModeInfoPtr’ gmake[4]: *** [egl_context.o] Error 1 gmake[4]: Leaving directory `/usr/src/mesa/src/gallium/state_trackers/egl' gmake[3]: *** [subdirs] Error 1 gmake[3]: Leaving directory `/usr/src/mesa/src/gallium/state_trackers' gmake[2]: *** [default] Error 1 gmake[2]: Leaving directory `/usr/src/mesa/src/gallium' make[1]: *** [subdirs] Error 1 make[1]: Leaving directory `/usr/src/mesa/src' make: *** [default] Error 1 error making mesa == [r...@coyote src]# cd mesa [r...@coyote mesa]# grep -R drmModeModeInfoPtr * src/gallium/state_trackers/xorg/xorg_output.c: drmModeModeInfoPtr drm_mode = NULL; src/gallium/state_trackers/egl/egl_surface.c:static drmModeModeInfoPtr src/gallium/state_trackers/egl/egl_surface.c: drmModeModeInfoPtr m = NULL; src/gallium/state_trackers/egl/egl_tracker.h: drmModeModeInfoPtr mode; src/gallium/state_trackers/egl/egl_tracker.c: drmModeModeInfoPtr m = NULL; === Looks like there is a missing include line? But otherwise things are looking good, it has come quite a ways. The modules are now installed I believe. However I haven't rebooted since the drm and the older version of mesa and radeonhd probably would not be a stable combination. I had to add a few lines to the script to stop the cp module errors because building a kernel without drm, it doesn't even have a gpu/drm dir in the /lib/modules/`uname - r`/kernel/drivers/ tree. I've attached a copy of the script as I ran it last. Hopefully it isn't too badly butchered. :) if you need to reboot, just reinstall the compiled modules (dri2proto, mesa, libdrm and kernel modules,xf86-video-radeonhd) from fedora repository. But that would mean I'd have to reboot to the stock, latest kernel I believe, at which point only the readeondh would be diff. yumex can install that right now in fact. Or I need to turn the drm back on and rebuild before I reboot. That is probably the preferable path of least resistance ATM. before rebooting reinstall the stock fedora mesa, dri2proto, libdrm, kernel modules, radeonhd. it should work as it worked before. if i run the script now it builds everything. from the erro it might be something from the official repository (sometimes they commit something that doesn't really work and they fix it some time after that). try posting the whole output of the script by redirecting everything to a file and attaching that file. I tried several different redir syntaxes earlier and wasn't able to generate a file of more than 0 bytes even after a re-read of man bash. What syntax are you using? normal redirection: ./radeon-updater-modified.sh /usr/src/ 1./output.txt 2./output.txt this redirects the script output to the file. if there's something missing in your system it might have been found by the autogen.sh script. Reran it again. Exit message still the same as above. Added the list so everybody see's it. If I can make the redirection work, I'll attach everything. I just enabled the configure line that was commented out, which seemed to make the un-init'd vars reports much more numerous, but the exit message remains as pasted above. However, I note in the building modules stanza, this: = Building modules, stage 2. fatal: Not a git repository MODPOST 13 modules WARNING: drm_agp_init_ttm [/usr/src/drm/linux-core/via.ko] undefined! WARNING: drm_agp_acquire [/usr/src/drm/linux-core/nouveau.ko] undefined! WARNING: drm_agp_bind [/usr/src/drm/linux-core/nouveau.ko] undefined! WARNING: drm_agp_init_ttm [/usr/src/drm/linux-core/nouveau.ko] undefined! WARNING: drm_agp_alloc [/usr/src/drm/linux-core/nouveau.ko] undefined! WARNING: drm_agp_enable [/usr/src/drm/linux-core/nouveau.ko] undefined! WARNING: drm_agp_info [/usr/src/drm/linux-core/nouveau.ko] undefined! WARNING: drm_agp_release [/usr/src/drm/linux-core/mga.ko] undefined! WARNING: drm_agp_acquire
Re: radeonhd stuff, missing function now?
2009/3/16 Gene Heskett gene.hesk...@verizon.net:
On Monday 16 March 2009, Beso wrote:
It still dies with this (different now) on the run to make mesa:
building mesa
***
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: configure.ac: not using Automake
autoreconf: Leaving directory `.'
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gmake... gmake
checking for makedepend... /usr/bin/makedepend
checking for sed... /bin/sed
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking whether to enable assembly... yes, x86
checking for gcc option to produce PIC... -fPIC
checking for dlopen... no
checking for dlopen in -ldl... yes
checking for posix_memalign... yes
checking pkg-config files for X11 are available... yes
checking for LIBDRM... yes
checking for DRI2PROTO... configure: error: Package requirements (dri2proto =
1.99.3) were not met:
Requested 'dri2proto = 1.99.3' but version of DRI2Proto is 1.99.1
you're missing dri2proto. i've added it to the script and modified the
order in order to build at first dri2proto, then libdrm and then mesa
and xf86-video-radeonhd. if you need other packages, usually you need
only git packages (protos or libs hosted on freedesktop) then try
adding them to the script:
1. add a line here:
EGIT_REPO_URI_1=git://anongit.freedesktop.org/git/mesa/drm
EGIT_REPO_URI_2=git://anongit.freedesktop.org/git/xorg/driver/xf86-video-radeonhd
EGIT_REPO_URI_3=git://anongit.freedesktop.org/mesa/mesa
EGIT_REPO_URI_4=git://anongit.freedesktop.org/git/xorg/proto/dri2proto
EGIT_REPO_URI_5=git://your new package git uri
2. copy the following lines:
## -- first git repository (mesa)
#
EGIT_REPO_URI=${EGIT_REPO_URI_3}
EGIT_BRANCH=${EGIT_BRANCH_3}
PN=mesa
EGIT_PROJECT=${PN/-git}
WORKDIR=${WORKING_DIR}/mesa
## -- cleaning old src directory, cloning/updating the drm repository
#
echo '***'
echo ' updating mesa '
echo '***'
rm ${WORKDIR} -fR
git_fetch || die git_fetch() failed
echo
echo `pwd`
to this (EGIT_BRANCH_3 is master (if you don't know of a particular
branch to use use this)) before the package that fails:
# new package
#
EGIT_REPO_URI=${EGIT_REPO_URI_5}
EGIT_BRANCH=${EGIT_BRANCH_3}
PN=new package name
EGIT_PROJECT=${PN/-git}
WORKDIR=${WORKING_DIR}/new package name
## -- cleaning old src directory, cloning/updating the drm repository
#
echo '***'
echo ' updating mesa '
echo '***'
rm ${WORKDIR} -fR
git_fetch || die git_fetch() failed
echo
echo `pwd`
3. copy the following before the package that fails:
echo '***'
echo ' building dri2proto ***'
echo '***'
cd ${WORKING_DIR}/dri2proto
## -- we're using the workdir/build prefix so that the package won't install
the
# files in the official directory and the script doesn't need the root
priviledges
# until we copy the files in the right directories
#
./autogen.sh --prefix=${WORKING_DIR}/dri2proto/build || die autogen on
drm failed
make || die error making dri2proto
make install || die error installing dri2proto
#sudo cp build/* -av /
to:
echo '***'
echo '*** building new package ***'
echo '***'
cd ${WORKING_DIR}/new package name
## -- we're using the workdir/build prefix so that the package won't install
the
# files in the official
Re: libxcb-xlib.la failures when building X11 with libxcb-1.2
2009/3/17 Halim Issa yalla...@gmail.com: On Tuesday 17. March 2009 18.07.37 Dan Nicholson wrote: Unfortunately, since libtool transfers needed libraries forward into the .la files, you'll probably need to rebuild libX11 and all the libraries that depend on it. You need libX11 to drop its link to libxcb-xlib.so and remove the reference to libxcb-xlib.la in libX11.la. Then you'd need to rebuild libXext so that libXext.la no longer contains its reference to libxcb-xlib.la. Etc... Or remove all the references to libxcb-xlib.la in all your installed .la files. Or just remove all the installed .la files (this can cause issues in a couple cases, but using pkg-config alleviates most of them). Thanks for thorough and useful explaination. I think I'll have to go carefully about when doing this. I believe this task is slightly bigger than what fits in an afternoon recompile, but I'll certainly give it a go in a weekend. Thanks again! or try this: fgrep -rZl /usr/lib/libxcb-xlib.la /usr/lib* /usr/kde/*/lib* | xargs -0 sed -i -e 's:/usr/lib/libxcb-xlib.la::g' this strips out the /usr/lib/libxcb-xlib.la from the various packages in /usr/lib and /usr/kde/all versions/lib (if you've prefixed kde to /usr/kde) directories that have incorrectly been injected with libxcb-xlib.la dep. after that you should still rebuild those packages, if you've used static linking, and this time they should be able to build just fine. you can use this command to strip out .la dependencies (remember that statically linked libs still need rebuild after the change of a library that they depend on). here's flameyees post, about preserved libs with references to the use of .la files, from which i've picked up this technique i've used more than once with gcc (which always triggers a rebuild when built with gcj support): http://blog.flameeyes.eu/2008/07/22/the-odyssey-of-preserved-libs-feature -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeonhd stuff, missing function now?
2009/3/16 Gene Heskett gene.hesk...@verizon.net: On Sunday 15 March 2009, Beso wrote: so the steps are: 1. install rpmfusion repository It is, but only the normal non-free channels are enabled, updates-testing and rawhide are not. I've enabled them one by one but no newer mesa stuff is showing up. Several other things I needed have, but no new drm, libdrm, mesa or libmesa stuff has appeared. I also sent FF to the repository and searched for new mesa drm. Zero. after more googling around without any hints (i only saw some forums of people with mesa 7.3 installed when using proprietary ati/nvidia drivers and all of them with references to the rpm-fusion repository) i've decided that it's faster to add the git version of mesa to the script. now the script fetches/updates mesa, libdrm, radeonhd. you might experience troubles if you have some packages not installed. i'm on full git with all x11 packages on my gentoo box and don't know what fedora has installed. the thing that i find strange is that fedora or external repos don't provide mesa 7.3 packages. I'm a sucker, so although it is way late, I'll sure give it a shot. And I gave it this startup: # sh radeonhd-updater-modified.sh /usr/src and it exited here: updating radeonhd *** xf86-video-radeonhd git clone start -- repository: git://anongit.freedesktop.org/git/xorg/driver/xf86-video- radeonhd Initialized empty Git repository in /usr/src/git-src/xf86-video-radeonhd/ remote: Counting objects: 712, done. remote: Compressing objects: 100% (671/671), done. remote: Total 712 (delta 531), reused 38 (delta 27) Receiving objects: 100% (712/712), 762.19 KiB | 171 KiB/s, done. Resolving deltas: 100% (531/531), done. error: could not lock config file .git/config local clone: /usr/src/git-src/xf86-video-radeonhd r6xx-r7xx-support fatal: Not a git repository tar: This does not look like a tar archive tar: Error exit delayed from previous errors Unpacked to /usr/src/xf86-video-radeonhd /usr/src/git-src *** building libdrm ** *** radeonhd-updater-modified.sh: line 271: ./autogen.sh: No such file or directory autogen on drm failed Many thanks Beso. I have to chuckle at your email handle though. I'm diabetic, type 2, so sugar is one of the poisons I have to miss as much of as I can, darnit. Getting old it turns out, is not for sissies. well, i forgot to export the GIT_DIR so that the git config would find it sorry. now it's fixed and i've added also the mesa git version. this would take some time to build up also because it builds up quite some stuff. you could add a ./configure for mesa before the make line so that it would configure it with what you really need (it doesn't build with xcb support which is a must if you want to use kde4). i haven't added the configure option since i don't know if your libX11 is build with xcb support. uncomment the ./configure line in the script if you're actually using kde4, since your libX11 should in that case be built with xcb support. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeonhd stuff, missing function now?
2009/3/16, Beso givemesug...@gmail.com: 2009/3/16 Gene Heskett gene.hesk...@verizon.net: On Sunday 15 March 2009, Beso wrote: so the steps are: 1. install rpmfusion repository It is, but only the normal non-free channels are enabled, updates-testing and rawhide are not. I've enabled them one by one but no newer mesa stuff is showing up. Several other things I needed have, but no new drm, libdrm, mesa or libmesa stuff has appeared. I also sent FF to the repository and searched for new mesa drm. Zero. after more googling around without any hints (i only saw some forums of people with mesa 7.3 installed when using proprietary ati/nvidia drivers and all of them with references to the rpm-fusion repository) i've decided that it's faster to add the git version of mesa to the script. now the script fetches/updates mesa, libdrm, radeonhd. you might experience troubles if you have some packages not installed. i'm on full git with all x11 packages on my gentoo box and don't know what fedora has installed. the thing that i find strange is that fedora or external repos don't provide mesa 7.3 packages. I'm a sucker, so although it is way late, I'll sure give it a shot. And I gave it this startup: # sh radeonhd-updater-modified.sh /usr/src and it exited here: updating radeonhd *** xf86-video-radeonhd git clone start -- repository: git://anongit.freedesktop.org/git/xorg/driver/xf86-video- radeonhd Initialized empty Git repository in /usr/src/git-src/xf86-video-radeonhd/ remote: Counting objects: 712, done. remote: Compressing objects: 100% (671/671), done. remote: Total 712 (delta 531), reused 38 (delta 27) Receiving objects: 100% (712/712), 762.19 KiB | 171 KiB/s, done. Resolving deltas: 100% (531/531), done. error: could not lock config file .git/config local clone: /usr/src/git-src/xf86-video-radeonhd r6xx-r7xx-support fatal: Not a git repository tar: This does not look like a tar archive tar: Error exit delayed from previous errors Unpacked to /usr/src/xf86-video-radeonhd /usr/src/git-src *** building libdrm ** *** radeonhd-updater-modified.sh: line 271: ./autogen.sh: No such file or directory autogen on drm failed Many thanks Beso. I have to chuckle at your email handle though. I'm diabetic, type 2, so sugar is one of the poisons I have to miss as much of as I can, darnit. Getting old it turns out, is not for sissies. well, i forgot to export the GIT_DIR so that the git config would find it sorry. now it's fixed and i've added also the mesa git version. this would take some time to build up also because it builds up quite some stuff. you could add a ./configure for mesa before the make line so that it would configure it with what you really need (it doesn't build with xcb support which is a must if you want to use kde4). i haven't added the configure option since i don't know if your libX11 is build with xcb support. uncomment the ./configure line in the script if you're actually using kde4, since your libX11 should in that case be built with xcb support. -- dott. ing. beso sorry, i forgot the script. -- dott. ing. beso radeonhd-updater-modified.sh Description: Bourne shell script ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeonhd stuff, missing function now?
2009/3/16 Gene Heskett gene.hesk...@verizon.net: On Monday 16 March 2009, Beso wrote: 2009/3/16, Beso givemesug...@gmail.com: 2009/3/16 Gene Heskett gene.hesk...@verizon.net: On Sunday 15 March 2009, Beso wrote: so the steps are: 1. install rpmfusion repository It is, but only the normal non-free channels are enabled, updates-testing and rawhide are not. I've enabled them one by one but no newer mesa stuff is showing up. Several other things I needed have, but no new drm, libdrm, mesa or libmesa stuff has appeared. I also sent FF to the repository and searched for new mesa drm. Zero. after more googling around without any hints (i only saw some forums of people with mesa 7.3 installed when using proprietary ati/nvidia drivers and all of them with references to the rpm-fusion repository) i've decided that it's faster to add the git version of mesa to the script. now the script fetches/updates mesa, libdrm, radeonhd. you might experience troubles if you have some packages not installed. i'm on full git with all x11 packages on my gentoo box and don't know what fedora has installed. the thing that i find strange is that fedora or external repos don't provide mesa 7.3 packages. I'm a sucker, so although it is way late, I'll sure give it a shot. And I gave it this startup: # sh radeonhd-updater-modified.sh /usr/src and it exited here: updating radeonhd *** xf86-video-radeonhd git clone start -- repository: git://anongit.freedesktop.org/git/xorg/driver/xf86-video- radeonhd Initialized empty Git repository in /usr/src/git-src/xf86-video-radeonhd/ remote: Counting objects: 712, done. remote: Compressing objects: 100% (671/671), done. remote: Total 712 (delta 531), reused 38 (delta 27) Receiving objects: 100% (712/712), 762.19 KiB | 171 KiB/s, done. Resolving deltas: 100% (531/531), done. error: could not lock config file .git/config local clone: /usr/src/git-src/xf86-video-radeonhd r6xx-r7xx-support fatal: Not a git repository tar: This does not look like a tar archive tar: Error exit delayed from previous errors Unpacked to /usr/src/xf86-video-radeonhd /usr/src/git-src *** building libdrm ** *** radeonhd-updater-modified.sh: line 271: ./autogen.sh: No such file or directory autogen on drm failed Many thanks Beso. I have to chuckle at your email handle though. I'm diabetic, type 2, so sugar is one of the poisons I have to miss as much of as I can, darnit. Getting old it turns out, is not for sissies. well, i forgot to export the GIT_DIR so that the git config would find it sorry. now it's fixed and i've added also the mesa git version. this would take some time to build up also because it builds up quite some stuff. you could add a ./configure for mesa before the make line so that it would configure it with what you really need (it doesn't build with xcb support which is a must if you want to use kde4). i haven't added the configure option since i don't know if your libX11 is build with xcb support. uncomment the ./configure line in the script if you're actually using kde4, since your libX11 should in that case be built with xcb support. -- dott. ing. beso sorry, i forgot the script. I enabled that .configure line before I ran it since this is kde-4.2. This error eventually: building mesa *** 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: configure.ac: not using Automake autoreconf: Leaving directory `.' checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gmake... gmake checking for makedepend... /usr/bin/makedepend
Re: radeonhd stuff, missing function now?
2009/3/15 Gene Heskett gene.hesk...@verizon.net: Greetings; Up till a week ago (approx) that script I wrote worked well to get me a much improved speed out of my x, but recently when I do the 'modprobe -r drm;modprobe drm' there is a function missing. And I'm stuck with an x driver that scrolls painfully slow. From dmesg: [135979.940024] [drm] Module unloaded [135990.364368] drm: Unknown symbol init_mm I have seen that previously during the build, but it worked anyway. Now its dead. Also, a couple lines in the script that I just changed so as to have a backup copy to revert to, do not appear to be working, so here it is again, please critique the attachment. Thirdly, I forgot to stop x before I did the module replacement attempted reloads. I take it that radeonhd is not dependent on radio or drm? They are unloaded and x is till working. Me goes off scratching head... -- i had a similar error some time ago with radeon driver, but after an update of the libdrm it went away. have you updated also the mesa and libdrm packages when you've updated the radeonhd driver? -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: general question: xorg Nvdriver
2009/1/28 Florian Lier f...@icram.de: Hey all, I'm trying to get the current (X.Org X Server 1.6.99.1) X running on several test-systems for like 2 or 3 months now. (for mpx purposes) I tested several systems with ATI, INTEL and NVIDIA gcards... The most difficult system seems to be the one with NVIDIA cards. As far as I can interpret the backtrace there is always a problem with the nv driver. Backtrace: 0: /home/fl0/mpxcompiz/bin/Xorg(xorg_backtrace+0x3b) [0x80e829b] 1: /home/fl0/mpxcompiz/bin/Xorg(xf86SigHandler+0x51) [0x809ccb1] 2: [0xb7f78400] 3: /home/fl0/mpxcompiz/bin/Xorg(xf86SetDesiredModes+0x27b) [0x80ab18b] 4: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a6412c] 5: /home/fl0/mpxcompiz/lib/xorg/modules/drivers//nv_drv.so [0xb7a64562] 6: /home/fl0/mpxcompiz/bin/Xorg(AddScreen+0x19d) [0x80684ad] 7: /home/fl0/mpxcompiz/bin/Xorg(InitOutput+0x23a) [0x808b12a] 8: /home/fl0/mpxcompiz/bin/Xorg [0x8068ba1] 9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7b19685] 10: /home/fl0/mpxcompiz/bin/Xorg [0x8068231] try manually modprobing drm and the nv driver before starting xorg. i've been having a very similar issue with radeon driver for a long time and the only workaround is modprobing the modules before startup. i've learned about this workaround from another user who had the same issues with the intel driver. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libXrender - documentation?
2009/1/26 Thomas Dickey dic...@his.com: On Mon, 26 Jan 2009, Clemens Eisserer wrote: I know that its not easy, but someone can't expect a step-by-step tutorial for such low-level stuff. hmm - the obvious conclusion is that xft is just a minor/useless library. Perhaps it should be removed, then. The whole discussion is about RENDER's documentation, not xft. very well, then apply my comments to RENDER (they're both presented as libraries that no one should try to use without some other library as a sanitizing layer). maybe i'm missing the point: what's the point in a library that needs another library in order to be used? i don't really think it's a good idea. maybe it would be better to better implement the library in order for it to be used without another sanitizing library, that would cost more resources. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Performance Issues with RV280
2009/1/12 8yrgr4dkp...@dyweni.com: Hi, My debugging consists of the following commands: X -verbose -config ./xorg.conf.new ouput 21 (to start X) synergyc _ipaddress_ (to allow control of test machine) openbox (start the window manager) firefox (start the browser and test scrolling) My system configuration: - Pentium III 550 (512KB cache) - 384MB RAM - Video Card: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) ATI Technologies Inc RV280 [Radeon 9200 PRO] (Secondary) (rev 01) (see lspci.txt attached) - OS is Gentoo Linux, using the X11 Portage Overlay (see git-hash.txt attached) - Kernel is 2.6.27 (see kernel-config.txt attached) - Loaded kernel modules: agpgart, intel_agp, drm, radeon - Linux Headers is 2.6.26 - Glibc is 2.9_p20081201 hmm, why are you using headers 2.6.26 on 2.6.27 kernel?! there are the 2.6.27 ones available. also, have you tried the new 2.6.28. it seems to improve some performance on my rs690. i don't seem to see issues with your configs and logs, if not the kernel built-in drm modules compiled as modules. for gentoo you should use instead the x11-drm (remember the radeon video card flag for mesa and ) package from x11 overlay. remove the radeon drm modules, recompile the kernel, rebuild the kernel modules and restart. you might be using the kernel drm instead of the radeon one. from what you're telling it seems that you don't have hw video acceleration enabled and you're using the cpu to accelerate your xorg. you've most likely not using dri for some sort of error while loading it Yeah, something doesn't seem right. (with XAA) # glxgears 3805 frames in 5.0 seconds = 760.863 FPS 3820 frames in 5.0 seconds = 763.980 FPS 3821 frames in 5.0 seconds = 764.196 FPS 3816 frames in 5.0 seconds = 763.128 FPS (with EXA) # glxgears 3757 frames in 5.0 seconds = 751.341 FPS 3769 frames in 5.0 seconds = 753.744 FPS 3771 frames in 5.0 seconds = 754.093 FPS 3769 frames in 5.0 seconds = 753.663 FPS See glxinfo.txt attached, it's the same for XAA and EXA (But mainly: direct rendering: Yes) you have direct rendering and Xv enabled by default on both xaa and exa. but i preffer exa since it has more future potential than xaa. or you have some kde4 effects that consume the cpu. in this case also the list of kwin effects would be useful. from the log and the list of kwin4 effects we might be able to give you more help. I can reproduce the scrolling / window resizing performance problems using only X11, Openbox (minimalistic window manager) and Firefox. No KDE involved here (to rule out any thing kde related) this might be the infamous firefox scrolling bug that it's there on most firefox versions. on kde there is an option to install a fix in the gtk+ control center. i don't know if something similar exists on openbox. try disabling the smooth scrolling and the autoscrolling in the advanced - browsing options of firefox. also, if you're using radeon then you'd want to really use exa instead of xaa since it's more perfomant than xaa. Switching to EXA provides no improvement. if it's not a driver problem then it's normal that it should not give too much improvement. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-input-mouse 1.4.0
2009/1/10 Alan Coopersmith alan.coopersm...@sun.com: Beso wrote: 2009/1/10 Alan Coopersmith alan.coopersm...@sun.com: Rémi Cardona wrote: Le 10/01/2009 05:45, Alan Coopersmith a écrit : The big change in 1.4.0 is the move of the OS-specific mouse handling code from the Xorg server to the mouse driver. This code was removed from the Xorg server in the Xorg 1.6 development cycle, so users of non-evdev systems (i.e. non-Linux or pre-evdev Linux) will need this version of the mouse driver to run with Xorg 1.6. It was moved to the module because the server never calls it directly - only the mouse module does, and if you're using another driver, like evdev or void, then the code is never called at all. i'm confused: if the code is never called by the server or evdev what's the reason for evdev to need it to run with 1.6 as you've stated in the previous mail? Read it again - I wrote users of *non*-evdev systems...will need this. i.e. I need it for my Solaris packages, and the BSD folks will need it, but common modern Linux distros could just delete the mouse module altogether if they're ready to go evdev-only. (If you do ship the mouse module at all with Xorg 1.6, you'll need this to avoid dlopen errors on the mouse module of not being able to find the xf86OSMouseInit function that moved from the server to the module.) sorry to have bothered you... :-( it seems that for today i've had enough time in front of the monitor with oracle and i need a pause. i was curious just about another thing: is or will ever be there a project for an evdev port on solaris and opensolaris? i think that evdev is one of that drivers that worth porting if there is the possibility. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Performance Issues with RV280
2009/1/8 8yrgr4dkp...@dyweni.com: Hi, I have a PIII 550 w/ a RV280 Radeon 9200 AGP card. Using the latest code checked out from X.Org Git repositories, I am experiencing performance issues. Firefox (2.x), Konqueror (KDE4), Kwrite (KDE4)... Seems to be any X application. In the case of Firefox and Konqueror (the two that I have done most of my testing with), top shows that the application and X itself are competing equally (roughly 40%-60% range) for CPU. The total cpu time of both combined is 100%. I'm using the default configuration that ships with X (X -configure) as my test configuration. The default configuration supports XAA Acceleration, and using glxgears, it get about 740 FPS. Setting 'Option AccelMethod exa' in the drivers section gives 10-20 additional FPS. All the applications (Firefox, Konqueror, Kwrite, etc) all have horrible response times when resizing windows, scrolling, etc. I'm open for any suggestions / instructions that can help troubleshoot and resolve this. posting the /var/log/Xorg.0.log would be helpful. from what you're telling it seems that you don't have hw video acceleration enabled and you're using the cpu to accelerate your xorg. you've most likely not using dri for some sort of error while loading it or you have some kde4 effects that consume the cpu. in this case also the list of kwin effects would be useful. from the log and the list of kwin4 effects we might be able to give you more help. also, if you're using radeon then you'd want to really use exa instead of xaa since it's more perfomant than xaa. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Memory leak in fedora 8 xorg server 1.3
2008/12/23 Barry Scott barry.sc...@onelan.co.uk: I have found the leak. isn't it simpler to update the xorg-server version?! 1.3 one is rather old and probably a memory leak bug would have been already discovered and fixed by now. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org crashes on current branches
2008/12/18 Tobias Hain tobias.h...@gmx.de: Hello, chipset: GM965 kernel: (vanilla) 2.6.28-rc8, (drm-intel-next) of Eric's 2.6.28-rc8 xserver: server-1.6-branch libdrm: master mesa: master and intel-2008-q4 xf86-video-intel: xf86-video-intel-2.6-branch remaining components: Kubuntu 8.10 I'm facing X.org crashes when launching X with all of the above: Backtrace: 0: /opt/gfx-test/bin/Xorg(xorg_backtrace+0x3b) [0x81323fb] 1: /opt/gfx-test/bin/Xorg(xf86SigHandler+0x51) [0x80b82a1] 2: [0xb7f9b400] 3: /opt/gfx-test/lib/dri/i965_dri.so [0xa75c6a08] 4: /opt/gfx-test/lib/dri/i965_dri.so(intelTexImage2D+0x7e) [0xa75c712e] 5: /opt/gfx-test/lib/dri/i965_dri.so(_mesa_TexImage2D+0x2aa) [0xa76647ea] 6: /opt/gfx-test/lib/xorg/modules/extensions//libglx.so [0xb7a40278] 7: /opt/gfx-test/lib/xorg/modules/extensions//libglx.so [0xb7a6a5fb] 8: /opt/gfx-test/lib/xorg/modules/extensions//libglx.so [0xb7a6eb8a] 9: /opt/gfx-test/bin/Xorg(Dispatch+0x33f) [0x808cc6f] 10: /opt/gfx-test/bin/Xorg(main+0x3bd) [0x807192d] 11: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7ad3685] 12: /opt/gfx-test/bin/Xorg [0x8070de1] Fatal server error: Caught signal 11. Server aborting It's always the same crash and related to 3D compositing manager loading I guess. I tried some permutations of the above branches, but none worked. Always the same crash that I didn't have before updating the branches. I've been tracking intel driver development for a while, but not on a regular basis. I think I updated branches one month old and before that everything worked fine. xorg.conf doesn't contain anything special. It's KDE 4.1 compositing manager. Haven't tried anything else yet. Hope it sounds familiar to some. do the drm and intel module load at x startup? i has some similar messages some time ago on radeon caused by modules not autoloading at x startup. i've added them to autoload at startup and then it worked. for some reason after the 1.5 release i couldn't start x without them forcedly loaded by the kernel. try loading the modules manually and see if something changes. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Cannot get DRI to work
2008/12/12 Hendrik Friedel hen_m...@web.de: Hello Beso, Thanks for your strong support. I'll try to answer your points: 1) Sorry, but I don't know when the libdrm modules are compiled. I've not compiled a new kernel on this installation, so if the modules are compiled with the kernel, then it should be still the right modules they are a part of mesa. usually distros build it separated since this needs to be rebuilt after each kernel update, while mesa itself doesn't. 2/3) I copied your recommended settings to my xorg.conf. Option BusType AGP Option MaxGARTSize integer # the one you set in the bios and the kernel finds out. Option UseInternalAGPGART no Option KernelModuleParm agplock=0 # then try unsupported Option AGPv3Mask 0x0001 # disable 8x and 4x agp Option AGPv3Mask 0x0002 Option AGPMask 0x0010 # disable fast writes and 4x and 2x support Option AGPMask 0x0004 Option AGPMask 0x0002 OptionDRI true Optionmtrr on OptionAccelMethod EXA a) no. Loading the module gives no direct error, but dmesg: uvesafb: mode switch failed (eax=0x14f, err=0) [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held [drm:drm_unlock] *ERROR* Process 31612 using kernel context 0 uvesafb: mode switch failed (eax=0x14f, err=0) well, the problem seems to be that the kernel doesn't really find the agp aperture. then it seems to be some sort of problem with xorg locks. i don't know if it's related to the kernel not finding the gart. If I restart X now, nothing has changed. b) I have no direct assess (only ssh) currently. I'll do that tomorrow. Regarding the resolution: The FullHD resolution works with this card. Regarding the framebuffer: I can't find an option for the ATI-Framebuffer in my kernel settings (attached). make menuconfig in the kernel directory and go to: device drivers - graphics support - framebuffer devices here you should just have selected: * video mode handling * enable firmware edid * vesa vga graphics support untagged the ati radeon display support then in the graphics support you should have -*- /dev/agpgart (AGP Support) - tagged like this and in the submodule all the chipsets as modules. (you seem to have the intel agp controller as default one). is this the agp controller of your mobo? the latest is needed for agp support. even if enabled on non agp systems it doesn't matter since it will simply not get used. also the problem i just found out is that you've compiled the kernel drm instead the mesa libdrm. this doesn't really work for radeon hw. you should go to the same graphics support where you controlled the agpgart and deselect the Direct Rendering Manager block (all of it, including its submodules). after that recompile the kernel with make make modules_install make install, get the libdrm in some way (usually your distro has it somewhere or download the archive from freedesktop) and install it. reboot, try loading the drm module with modprobe drm and see dmesg and lsmod. if everything went fine then try loading radeon with mdoprobe radeon. if that works you should have dri enabled and just try out by starting xorg. look at the xorg log and see the confirmation there. then go and tweak your configuration. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and specific signal PC
2008/12/9 Revolver Onslaught [EMAIL PROTECTED]: Hello, I recently purchased an FullHD 100Hz TV (Samsung LE40F86BDX) and a Nvidia GeForce9500 with HDMI output. This way, I can link my Linux on my TV. However, I cannot switch to 100Hz when the PC is linked to the TV (HDMI or VGA). I supposed it was a security but I was wrong : any of the 1080p FullHD source (Bluray, Xbox 360, etc) I use can be viewed in 100Hz even connected via HDMI. In the TV manual, it is wrote that it's the behaviour when PC is connected... what behavior?! does the manual indicate that the 100hz mode isn't available when connected to the pc output? So, I deduce that my Nvidia card send a specific signal, like RVB does (I suppose other cards have the same behaviour). This signal is then catched by the TV and the 100Hz mode is no more available. have you tried connectig to the dvi or a dvi-hdmi converter and then connect it to the tv?! Is there any way to switch off this signal with Xorg even with a patch ? Many thanks, RO if you're sure that the mode is supported you chould force it in your settings (nvidia control panel or xorg.conf). beware: if you force a mode that your tv doesn't support when connected to the pc then you'll most likely burn the tv and/or the videoboard. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg and specific signal PC
2008/12/9 Revolver Onslaught [EMAIL PROTECTED]: On Tue, Dec 9, 2008 at 1:19 PM, Beso [EMAIL PROTECTED] wrote: 2008/12/9 Revolver Onslaught [EMAIL PROTECTED]: Hello, I recently purchased an FullHD 100Hz TV (Samsung LE40F86BDX) and a Nvidia GeForce9500 with HDMI output. This way, I can link my Linux on my TV. However, I cannot switch to 100Hz when the PC is linked to the TV (HDMI or VGA). I supposed it was a security but I was wrong : any of the 1080p FullHD source (Bluray, Xbox 360, etc) I use can be viewed in 100Hz even connected via HDMI. In the TV manual, it is wrote that it's the behaviour when PC is connected... what behavior?! does the manual indicate that the 100hz mode isn't available when connected to the pc output? Yes. then you cannot have it work at 100hz. So, I deduce that my Nvidia card send a specific signal, like RVB does (I suppose other cards have the same behaviour). This signal is then catched by the TV and the 100Hz mode is no more available. have you tried connectig to the dvi or a dvi-hdmi converter and then connect it to the tv?! Not yet. I only tried HDMI and VGA. hdmi should understand the 100hz (it should send data as a normal blu-ray unit). Is there any way to switch off this signal with Xorg even with a patch ? Many thanks, RO if you're sure that the mode is supported you chould force it in your settings (nvidia control panel or xorg.conf). beware: if you force a mode that your tv doesn't support when connected to the pc then you'll most likely burn the tv and/or the videoboard. I don't think it's the right way. The TV computes the intermediates pictures in 100Hz mode. For example, when I read a DVD with my DVDplayer, the refresh rate is 50Hz (or 60) and the TV computes the pictures to render 100pic/sec. well, then your tv is doubling the scan. so if you attach an hdmi input from your pc at 50hz you should have the same 100hz result. just attach your pc output on hdmi and set it to whatever your board detects (i think it should be 60hz or something similar) and it should work at 100hz. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [newb] Will xorg still allow non-hal config?
2008/11/30 Kalle Vahlman [EMAIL PROTECTED]: 2008/11/29 Colin Guthrie [EMAIL PROTECTED]: eatdirt wrote: Hi all, sorry about the naive questions, I am a mandriva cooker tester/user, and I have just discovered recently that soon, I'll have to start HAL to get working device under X. So I have a few comments/questions: 1) Today, if you are not under the gas factory desktops, gnome/kde, you don't need HAL. I never used/needed HAL. Will xorg still allow users to not use HAL? Yes. Some platforms that Xorg is on do not support hal. But that said, there are lots of things in Gnome/KDE that just don't work without HAL, so more and more you will need it for correct operation. Is there any reason you have a problem using hal? Amusingly, GNOME is already seeing push to move *away* from HAL: http://mail.gnome.org/archives/desktop-devel-list/2008-November/msg00247.html they're just substituting it with devicekit, that does the same thing hal does but it's more modular and scalable. the problem with devicekit is that it's still young and hasn't been really tested in a distro. the first to do so should be fedora 11. well, anyway going with hal or devicekit it's not really important, the fact is that the introduction of these layers for the handling of peripherals give more freedom. just look at the evdev driver. i think that after its development the usability of keyboards and mouses has increased quite a lot. now i cannot see a reason to switch back to kbd + mouse instead of evdev. this is the same with the other hw info needed by xorg for configuration. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: problems with xorg on gentoo amd64
2008/10/29 Tassilo Horn [EMAIL PROTECTED]: Beso [EMAIL PROTECTED] writes: Hi! i'm crossposting to both xorg and gentoo amd64 mailing list to have more audience since the problem might be related to either gentoo or xorg itself. on sunday i've updated hal on gentoo and after reboot xorg stopped starting. the problem was that it cannot open the drm device. I had that problem, too. I work around it by loading the driver module explicitly in /etc/conf.d/modules. , | # i915 is my graphics card (intel) driver | modules=i915 ` Bye, Tassilo -- There are no such things as tornados. Chuck Norris just hates trailer parks. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg you were right. after manually loading drm and radeon driver before xorg xorg starts. it really seems that there is something wrong somewhere that prevents xorg to automatically load the required modules. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
