You are not logged in.
Could someone make a PKGBUILD for this and put it in the AUR? XOrg 6.9 RC2 is stable enough that Mandriva already uses it, and has a bunch of improvements over 6.8.2 (e.g. faster compositing), so this is something I and probably others would definitly like to see.
Offline
here you go. I hope it's alright. The PKGBUILD is based on the official one, and it works for me at least.
Offline
Thanks!
(Why must the binary be only for Pentium M? )
Offline
Thanks!
(Why must the binary be only for Pentium M? )
It's Pentium M optimized, but I fail to see why it shouldn't work with other i686 family CPU's.
Microshaft delenda est
Offline
scarecrow's right. I'm sure it works on anything better than a pIII. The reason it's P-M optimized is just because I like to have my own packages like that for my laptop. I made the repo public in case anyone was interested.
What CPU are you on, Jones?
Offline
Oh, I thought you were doing -march=pentium-m, as opposed to -mtune=pentium-m. -march makes a program incompatible with other architectures.
(K7 here, a socket 462 Sempron.)
Offline
no, you were right. I do -march=pentium-m. But as far as I understand, -march makes the binary incompatible with lower CPUs. E.g. Arch official binaries are compiled with -march=i686, but they work just fine on PIIIs & PIVs.
That said, I've no clue about K7s. I'll need to get back about that.
Offline
Pentium M is pretty different from K7, so the packages would probably be fuxx0red on my box.
(And this, folks, is why I'm against extensive optimization: it makes binary package incompatible between machines with similar architectures!)
Offline
(And this, folks, is why I'm against extensive optimization: it makes binary package incompatible between machines with similar architectures!)
Look; I wasn't originally intending anyone else to use my binaries. I'm not gonna go through the whole discussion again, but you might want to re-read this thread: http://bbs.archlinux.org/viewtopic.php? … highlight=.
I would normally follow pattern (like phrakture does here: http://bbs.archlinux.org/viewtopic.php? … highlight=), and ask you to do your own work and compile the package, if you want it done differently. But instead, since I'm such a nice bloke, I'll compile it for you with standard i686 flags (i.e. with the defaults from makepkg.conf), and I'll give you a link to it. (Obviously I won't put it in my p-m repo). How about that, huh?
Offline
As you can read here:
http://www.archlinux.org/blog/2005/11/0 … archlinux/
We will switch to 7.0 libraries soon, but keep the 6.8 server. I think a 6.9 server will go to unstable once I have time to make a package for that. The reason for keeping the 6.8 server is that the binary driver interface has been changed again, so nvidia and ATi users will have a screwed setup when upgrading to 6.9.
Offline
Alright; go get the ordinary i686-pkg here: http://www.naderehvandi.net/arch/xorg-1 … pkg.tar.gz
I haven't tested it though ;-)
Offline
Sorry man, I wasn't asking you to do that... Thanks anyway though.
Offline
It's no problem. Others might want it as well...
Anyway, when JGC makes a pkg for unstable, it's probably gonna be the safest bet to go with. I'll keep this package on my server until then. Enjoy
Offline
at least with NVIDIA drivers i can say that 6.9RC2 has been running stable since at least a week or so.
* GeForce 4 MX 4000 PCI
* GeForce FX Go5200 AGP
* GeForce FX 5200 AGP
* GeForce FX 6200 AGP
all of them have been working perfectly. oh, i didn't see any speed improvements.
I recognize that while theory and practice are, in theory, the same, they are, in practice, different. -Mark Mitchell
Offline
Oh? Not with compositing?
Offline
I for one experience rather drastic speed increases with xcompmgr. But as far as I understand, the nvidia drivers use hardware acceleration to render shadows and translucency. As I'm using the i810 drivers, those things are done in software mode. And the rendering speed of them in software mode has indeed increased.
Offline
Xorg6.9RC2 here, too and the nvidia driver works perfectly.
Is it safe to assume that nvidia has updated their driver with the new API then?
I should point out that I highly doubt that a distributor like Madriva would have shipped Xorg 6.9RC0 in their last version if it didn't work with nvidia's and ati's drivers.
Offline
Oh? Not with compositing?
don't really think i should waste precious cpu cycles on this.
I recognize that while theory and practice are, in theory, the same, they are, in practice, different. -Mark Mitchell
Offline
Hmm... I tried xcompmgr, and found that it was as slow as ever. :? No speed increase with composite at all.
Offline
Hmm... I tried xcompmgr, and found that it was as slow as ever. :? No speed increase with composite at all.
Hmm.. that's too bad. What's you gfx-adapter?
Offline
VIA Unichrome KM400, 64 MB shared DDR333, AGPDMA enabled.
(Hmm... I think part of the problem was that the RENDER extension was off. I heard someone say that RENDER is enabled by default, but judging from XOrg's log that is not the case.)
Offline
Oh. How about after turning it on? Was there a boost?
Offline
Too late, installed XOrg 6.8.2 again.
However, there does seem to be some improvement in 6.8.2 if I explicitly enable RENDER.
(This is really weird... RENDER is supposed to be enabled by default.)
Offline
indeed; RENDER should be initialized by default:
[stavrosg@gondolin bmpx-build]$ grep RENDER /var/log/Xorg.0.log
(**) NVIDIA(0): Enabling experimental RENDER acceleration
(II) Initializing built-in extension RENDER
[stavrosg@gondolin bmpx-build]$ grep -i render /etc/X11/xorg.conf
Option "RenderAccel" "true"
[stavrosg@gondolin bmpx-build]$
(xorg 6.9RC2)
Offline
Right you are.
With RENDER enabled explicitly:
[proteus@localhost ~]$ grep RENDER /var/log/Xorg.0.log.old
(**) Extension "RENDER" is enabled
(II) Initializing built-in extension RENDER
Without:
[proteus@localhost ~]$ grep RENDER /var/log/Xorg.0.log
(II) Initializing built-in extension RENDER
Offline