Package Details: xorg-server-dev 1.18.3-1

Git Clone URL: https://aur.archlinux.org/xorg-server-dev.git (read-only)
Package Base: xorg-server-dev
Description: Xorg X server - Bleeding edge version
Upstream URL: http://xorg.freedesktop.org
Licenses: custom
Groups: xorg
Conflicts: glamor-egl, nvidia-utils<=331.20, xf86-video-modesetting, xorg-server
Provides: X-ABI-EXTENSION_VERSION=9.0, X-ABI-VIDEODRV_VERSION=20.0, X-ABI-XINPUT_VERSION=22.1, x-server, xorg-server
Replaces: glamor-egl, xf86-video-modesetting
Submitter: Det
Maintainer: Det
Last Packager: Det
Votes: 17
Popularity: 0.031926
First Submitted: 2010-06-27 07:53
Last Updated: 2016-04-06 13:39

Dependencies (59)

Required by (99)

Sources (4)

Latest Comments

Det commented on 2016-04-06 13:39

D'oh, mate.

shoober420 commented on 2016-04-05 22:54

This fails to build because the Firefox patch is already included in the offical X.Org package.

Det commented on 2016-02-21 13:42

Pastebin.

xDShot commented on 2015-10-16 15:31

Nevermind. I commented out 44 and 45 lines as bug was fixed times ago :)

xDShot commented on 2015-10-16 15:27

I can't complie it:

$ makepkg -s --skippgpcheck
==> Making package: xorg-server-dev 1.17.99.901-1 (Fri Oct 16 18:26:42 MSK 2015)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found xorg-server-1.17.99.901.tar.bz2
-> Found xorg-server-1.17.99.901.tar.bz2.sig
-> Found nvidia-drm-outputclass.conf
-> Found xvfb-run
-> Found xvfb-run.1
-> Found 0001-systemd-logind-do-not-rely-on-directed-signals.patch
-> Found 0001-glamor-make-current-in-prepare-paths.patch
-> Found 0001-os-make-sure-the-clientsWritable-fd_set-is-initializ.patch
==> WARNING: Skipping verification of source file PGP signatures.
==> Validating source files with sha256sums...
xorg-server-1.17.99.901.tar.bz2 ... Passed
xorg-server-1.17.99.901.tar.bz2.sig ... Skipped
nvidia-drm-outputclass.conf ... Passed
xvfb-run ... Passed
xvfb-run.1 ... Passed
0001-systemd-logind-do-not-rely-on-directed-signals.patch ... Passed
0001-glamor-make-current-in-prepare-paths.patch ... Passed
0001-os-make-sure-the-clientsWritable-fd_set-is-initializ.patch ... Passed
==> Extracting sources...
-> Extracting xorg-server-1.17.99.901.tar.bz2 with bsdtar
bsdtar: Failed to set default locale
==> Starting prepare()...
-> fix VT switching with kdbus; from upstream
patching file hw/xfree86/os-support/linux/systemd-logind.c
Hunk #1 succeeded at 525 (offset 18 lines).
-> fix FS#45009, merged upstream
patching file glamor/glamor_prepare.c
Reversed (or previously applied) patch detected! Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file glamor/glamor_prepare.c.rej
==> ERROR: A failure occurred in prepare().
Aborting...

How to fix this?

libcg commented on 2015-09-02 22:45

1.18 RC1 has been released.

Det commented on 2015-04-17 20:03

Well, I'm saying I'm not including them from [extra] anymore at all.

kyak commented on 2015-04-17 19:17

I don't follow you logic anymore, Det. If you include patches selectively, it would be great to know how you select them.

Det commented on 2015-04-15 17:02

I don't follow those patches anymore.

kyak commented on 2015-04-15 17:02

Det, really, you are missing something. https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xorg-server&id=bc648d563c8d6a6ffd8d6e647b5bced5220b9460

Det commented on 2015-04-14 17:05

You are weird.

kyak commented on 2015-04-14 17:02

Wow, Det, you really need to update!

Det commented on 2015-03-15 12:19

1.17.1-5: https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=57618be9b62606369249cefe6a02845c3e625341

Det commented on 2015-03-11 21:27

Fixed. Thanks.

mareex commented on 2015-03-11 21:26

==> Verifying source file signatures with gpg...
xorg-server-1.17.1.tar.bz2 ... Passed
==> Extracting sources...
-> Extracting xorg-server-1.17.1.tar.bz2 with bsdtar
==> Starting prepare()...
/tmp/yaourt-tmp-marcus/aur-xorg-server-dev/./PKGBUILD: line 35: cd: xorg-server-dev-1.17.1: No such file or directory
==> ERROR: A failure occurred in prepare().
Aborting...
==> ERROR: Makepkg was unable to build xorg-server-dev.
==> Restart building xorg-server-dev ? [y/N]
==> ----------------------------------------
==>


In line 35 change 'cd "${pkgbase}-${pkgver}"' to 'cd "${_pkgbase}-${pkgver}"'

Det commented on 2015-02-23 09:13

Came after I updated. By the way, it's not "3:0", it's "-3".

3:<version> stands for epoch, <version>-3 is the pkgrel.

kyak commented on 2015-02-23 09:08

Where is this? https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xorg-server&id=72ff8b398b1319b3201a16b12a23510e847672e0

3:0, Det :)

Det commented on 2015-02-22 16:27

No such thing?

kyak commented on 2015-02-22 14:59

2:0 ;)

Det commented on 2015-02-21 19:08

xorg-server-dev 1.17.1-3: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xorg-server&id=6cefa145e31452b2b232a2eae4f8028b5ae27a35

Det commented on 2015-02-12 05:02

Fixed.

adramalech commented on 2015-02-12 04:55

So I thought this line:
_ABI_EXTENSION="$(grep -Po "EXTENSION_V.*\(\K[^)]*" xserver/hw/xfree86/common/xf86Module.H | tr , . | tr -d ' ')"

was causing an error because of the capitalization of the file extension; however, it still seems to occur. I am seeing an error when using grep.

==> Entering fakeroot environment...
==> Starting package_xorg-server-dev()...
grep: xserver/hw/xfree86/common/xf86Module.h: No such file or directory
==> ERROR: A failure occurred in package_xorg-server-dev().
Aborting...
==> ERROR: Makepkg was unable to build xorg-server-dev.
==> Restart building xorg-server-common-dev ? [y/N]
==> -----------------------------------------------
==>

adramalech commented on 2015-02-12 04:24

There is an issue with this line:

_ABI_EXTENSION="$(grep -Po "EXTENSION_V.*\(\K[^)]*" xserver/hw/xfree86/common/xf86Module.H | tr , . | tr -d ' ')"

you need to change "xf86Module.H" to "xf86Module.h".

error:

==> Entering fakeroot environment...
==> Starting package_xorg-server-dev()...
grep: xserver/hw/xfree86/common/xf86Module.h: No such file or directory
==> ERROR: A failure occurred in package_xorg-server-dev().
Aborting...
==> ERROR: Makepkg was unable to build xorg-server-dev.
==> Restart building xorg-server-common-dev ? [y/N]

Det commented on 2015-01-15 10:58

To fix:

xorg-server-1.16.99.901.tar.bz2 ... FAILED (unknown public key DB221A6900000011)

Use:

$ gpg --recv-key DB221A6900000011

Or (for all AUR packages):

"keyserver-options auto-key-retrieve" in ~/.gnupg/gpg.conf

Det commented on 2014-07-31 14:43

You got me.

1.16.0-6:
- https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=124ecd69a4454d10bc5f8f472490df848a1b939f
- https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=3b612d304df483cea691c0287dcba99cf1bce116

kyak commented on 2014-07-31 14:23

You are so out of date, Det :)

Det commented on 2014-07-27 16:41

1.16.0-5:
- https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=1daadd88a35a874d5f430663428afde084d3414c
- https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=41c2fd6821239da22ff452d699a97634705a9227

Det commented on 2014-07-25 19:33

1.16.0-3[1][2]: Added 'glamor-upstream-fix.patch'[3] / 'nvidia-drm-outputclass.conf'[4] / 'xorg-server-dev.install'[5] and got rid of 'autoconfig-nvidia.patch'[6]

[1] = https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xorg-server&id=e9273e2f0313a4fdcccf54eb6a10efe98e5ae00c
[2] = https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xorg-server&id=803eb4a56b5e4a8b46d7d6c6d33fc52316b27589
[3] = https://projects.archlinux.org/svntogit/packages.git/tree/trunk/glamor-upstream-fix.patch?h=packages/xorg-server
[4] = https://projects.archlinux.org/svntogit/packages.git/tree/trunk/nvidia-drm-outputclass.conf?h=packages/xorg-server
[5] = https://projects.archlinux.org/svntogit/packages.git/tree/trunk/xorg-server.install?h=packages/xorg-server
[6] = https://projects.archlinux.org/svntogit/packages.git/tree/trunk/autoconfig-nvidia.patch?h=packages/xorg-server&id=9b220d59d7b68ae4ff6344e2f976f8b1a98dede1

Det commented on 2014-07-19 14:57

1.16.0-2: Added 'xorg-server-xwayland-dev' and got rid of '10-quirks.conf'[1] and 'CVE-2013-6424.diff'[2].

[1] = https://projects.archlinux.org/svntogit/packages.git/tree/trunk/10-quirks.conf?h=packages/xorg-server&id=9b220d59d7b68ae4ff6344e2f976f8b1a98dede1
[2] = https://bugs.archlinux.org/task/38401

Det commented on 2014-06-20 18:22

Package group = Different packages that are grouped together due to similarity - for a simpler/quicker installation (e.g. 'gnome', 'gnome-extra', 'kde', 'libreoffice', 'xorg', 'xorg-drivers'). Doesn't force installing all members of the group. See: https://wiki.archlinux.org/index.php/Pacman#Installing_package_groups and https://www.archlinux.org/groups/x86_64/

Meta package = A dummy package that only depends on other packages. Allows pacman to automatically install new members to the meta package (as opposed to package groups), but doesn't allow removing any locally without removing the meta package (after which new members won't be installed). See: https://wiki.archlinux.org/index.php/KDE_Packages#Using_Meta-Packages

Split package = When software has unnecessary parts that are not required by everybody (e.g. documentation and/or both gtk2 and gtk3 version), it can be split, so that the sources and the build() function don't need to be duplicated. Some parts may still depend on each other.

I don't know why libglamor.so isn't built with --enable-glamor, but you can try installing either glamor-egl or glamor-egl-git with the double -d flag (ignores dependecy checks) and --force (overwrites existing files) (pacman -Sdd --force glamor-egl / pacman -Udd --force glamor-egl-git*).

Thanks for the xwayland-git tip.

thx1138 commented on 2014-06-20 17:03

> This turned out to be a bug in Yaourt
Thanks for checking that. It looks to be fixed now, thanks to your bug report.

> Things like aurget and pacaur work just fine
Aha! I hadn't known about those.

> I'm assuming you haven't encountered a lot of split packages,
"group-package", "meta-package", "split-package" - yeah, it's a challenge. The documentation seems pretty scattered.

I've run into another problem, though, with a failing Xorg server, after the build. The only thing I can think that changed was an upgrade to "linux 3.15.1-1", which would change the radeon module, here running an "RV710 [Radeon HD 4350/4550]".

First, running "Xorg", there is a complaint about no "libglamor.so.0", because glamor-egl has been replaced by xorg-server-dev,
[ 54046.640] (EE) Failed to load /usr/lib/xorg/modules/drivers/radeon_drv.so: libglamor.so.0: cannot open shared object file: No such file or directory

Installing the old glamor-egl package is not allowed by xorg-server-dev, and rebuilding xf86-video-ati does not work,
checking for LIBGLAMOR... no
configure: error: Package requirements (glamor >= 0.6.0) were not met:
No package 'glamor' found

so I intalled "xf86-video-ati-git". But then, again running "Xorg", I get
[ 44731.119] (EE) RADEON(0): [drm] failed to set drm interface version.
[ 44731.119] (EE) RADEON(0): Kernel modesetting setup failed

Taking a wild guess, installing "xf86-video-modesetting-git", makes no difference, producing the same error.

Any thoughts?

Also, perhaps xorg-server-dev should be made to conflict with xwayland-git, since otherwise, after a long build, the xorg-server-dev install fails, if xwayland-git is installed, instead of xwayland-git simply being removed automatically.

James

thx1138 commented on 2014-06-20 16:57

> This turned out to be a bug in Yaourt
Thanks for checking that. It looks to be fixed now, thanks to your bug report.

> Things like aurget and pacaur work just fine
Aha! I hadn't known about those.

> I'm assuming you haven't encountered a lot of split packages,
"group-package", "meta-package", "split-package" - yeah, it's a challenge. The documentation seems pretty scattered.

I've run into another problem, though, with a failing Xorg server build. The only thing I can think that changed was an upgrade to "linux 3.15.1-1", which would change the radeon module, here running an "RV710 [Radeon HD 4350/4550]".

First, there is a complaint about no "libglamor.so.0", because glamor-egl has been replaced by xorg-server-dev,
[ 54046.640] (EE) Failed to load /usr/lib/xorg/modules/drivers/radeon_drv.so: libglamor.so.0: cannot open shared object file: No such file or directory

Installing the old glamor-egl package is not allowed by xorg-server-dev, and rebuilding xf86-video-ati does not work,
checking for LIBGLAMOR... no
configure: error: Package requirements (glamor >= 0.6.0) were not met:
No package 'glamor' found

so I intalled "xf86-video-ati-git". But then, I get
[ 44731.119] (EE) RADEON(0): [drm] failed to set drm interface version.
[ 44731.119] (EE) RADEON(0): Kernel modesetting setup failed

Taking a wild guess, installing "xf86-video-modesetting-git", makes no difference, producing the same error.

Any thoughts?

Also, perhaps xorg-server-dev should be made to conflict with xwayland-git, since otherwise, after a long build, the xorg-server-dev install fails, if xwayland-git is installed, instead of xwayland-git simply being removed automatically.

James

desaparecido commented on 2014-06-20 06:15

Comment by desaparecido
2014-06-20 06:14
Hi, thanks for the package :) I successfully builded the packages with libepoxy (1.2) from AUR. After install the packages I didn't have my X session started :(
I use mesa-git repo with [testing] enable. My GPU is a Radeon HD7970 and I want test it because "usually" the're a lot of improvements in this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=68524

I can't take the time to see how to resolve because was late the last night but only like question, it's needed to build mesa stuffs after installed this Xorg version ?

thanks :-)

desaparecido commented on 2014-06-20 06:14

Hi, thanks for the package :) I successfully builded the packages with libepoxy (1.2) from AUR. After install the packages I didn't have my X session started :(
I use mesa-git repo with [testing] enable. My GPU is a Radeon HD7970 and I want test it because "usually" the're a lot of improvements in this bug:
https://bugs.kde.org/show_bug.cgi?id=336079

I can't take the time to see how to resolve because was late the last night but only like question, it's needed to build mesa stuffs after installed this Xorg version ?

thanks :-)

Det commented on 2014-06-17 11:50

This turned out to be a bug in Yaourt: https://github.com/archlinuxfr/yaourt/issues/38

Things like aurget and pacaur work just fine: https://aur.archlinux.org/packages/aurget/, https://aur.archlinux.org/packages/pacaur/

Det commented on 2014-06-17 07:47

I'm assuming you haven't encountered a lot of split packages, but they all share the same PKGBUILD, even though the resulting packages are different (that's what a split package means - a single PKGBUILD describes multiple packages. We have a totally different meaning for the term "package group").

Now, I'm not sure whether this is a bug in the AUR tools or the AUR itself, but split packages shouldn't indeed be tried to update "separately", when the same PKGBUILD does it for all.

thx1138 commented on 2014-06-17 06:07

Hmm - something is not right with the "PKGBUILD", combining multiple packages. All these packages in "pkgname" have the same PKGBUILD file, but are distinct packages, and are seen as distinct packages by "pacman".

When there is an update, and the update is applied with "yaourt -Syua", then "n^2" packages built, and "n^2 - n" of those tedious builds are a redundant waste of time.

I assume that you are trying to create a pacman "package group". The documentation for pacman groups is really terrible. My expectation is that the members of a group or a "meta-group" are not, themselves, "versioned", so that, once they are installed, they are never meant to be re-installed due to some change in version. Then, each of the _members_ of the group or meta-group would be versioned, and those members would be simple standard pacman packages.

So, I'm thinking that these packages need to be split-up, into simple packages having a shared "group" designation, or/and a meta-group package should be created to reference the members of the meta-group. You can have both a "group" and a "meta-group", if you like.

For a pacman group, the PKGBUILD for each member package would have an entry of "Groups some-shared-group-name".

If instead, or if in addition, there were to be a meta-group, there would have to be an explicit PKGBUILD file for just that meta-group, where "Each split package uses a corresponding packaging function with name package_foo(), where foo is the name of the split package." There should be _no_ build instructions in the meta-group PKGBUILD file! There is sparse documentation at:
https://www.archlinux.org/pacman/PKGBUILD.5.html, "Package Splitting".

You can see an example at:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kde-meta

James

Det commented on 2014-06-12 21:36

Done. Just tell me, if libepoxy (1.2) isn't enough.

intgr commented on 2014-06-12 17:41

Now that Glamor has been merged into xorg-server, should this package be built with builtin Glamor support?

I added --enable-glamor to the configure line and 'glamor-egl' to xorg-server-dev provides= and conflicts= lines, and things seem to work fine. This fixes a bug with Radeon drivers: https://bugs.freedesktop.org/show_bug.cgi?id=79756

Det commented on 2014-04-16 08:31

Not just maybe, we should do that.

jdbrown commented on 2014-04-16 07:15

fontsproto 2.1.3 and xproto 7.0.26 were recently released and it seems that the code can be built against them. Maybe we can change the dependencies back to the official ones.

jdbrown commented on 2014-04-16 07:15

fontsproto 2.1.3 and xproto 7.0.26 were recently released and it seems that the code can be built against them. Maybe the dependencies back to the official ones.

edtoml commented on 2014-04-14 00:42

For everyones info. The tarball for 1.15.99.902 is missing headers needed to compile glamor. changing the PKGBUILD to use git and appling fixes from https://bugs.freedesktop.org/show_bug.cgi?id=64297 enabling glamor and removing glamor-egl before installing the new xserver along with xf86-video-ati-git xf86-input-evdev-git xf86-video-modesetting-git & xf86-video-fbdev-git gives a working install here. On my r7 260x (see bugs.freedesktop.org/show_bug.cgi?id=75992 if you have one) it runs the uniengine tropical benchmark 20% faster than 1.15.

Det commented on 2014-04-13 15:08

Guess so. You don't have to quote the whole thing, though.

r08 commented on 2014-04-13 14:52

@Det
Comment by Det
2014-04-10 09:48
Everybody's suddenly so interested in this.

Yes because if you read the news, xorg-server 1.15.99.902 has some kickass features, bug fixes, and performance enhancements. So everyone is eager to test these. =D

kozzi commented on 2014-04-11 16:08

edtoml:

there are some missing files, I have make my own packages for this xorg-server(+latest mesa and latest llvm) and it is amazing. All bugs with slow radeonsi are gone.

Det commented on 2014-04-10 09:48

Everybody's suddenly so interested in this.

jdbrown commented on 2014-04-10 09:45

The xwayland ddx mainlined recently works with --enable-xwayland flag (requires libepoxy-git, tested with weston 1.4.91). However, starting Xorg will make the screen go blank and the machine totally unresponsive on my (VMWare virtual) machine. Any ideas why?

edtoml commented on 2014-04-09 21:07

This does not work when the PGKBUILD is modified to add
--enable-glamor
which should build the version of glamor now in the xorg tree.

Its getting errors with includes and probably also needs a provides glamor-egl

(trying to test this glamor version for bug 64297)

edtoml commented on 2014-04-09 21:04

This does not seem to work when --enable-glamor is added to use the version that is now in the xorg tree. It gets errors with includes and probably need a provides glamor-egl

Det commented on 2014-04-09 17:15

Yeah, okay. It's just that they used to include those updated version clauses in the configuration step.

r08 commented on 2014-04-09 17:13

@Det based on the 2 compile errors I got during build. After installing these 2 protos everything build fine

Det commented on 2014-04-09 16:09

Thanks for going through with this.

But how did you know it was those two protos?

r08 commented on 2014-04-09 15:09

Guys if you're having build errors with this package make sure you have the bleeding-edge libraries.
Det has library packages from Git here:
https://aur.archlinux.org/packages/?K=Det&SeB=m

This particular version-1.15.99.902-1 needs fontsproto-git, xproto-git installed.

Det this PKGBUILD has an issue around lines 119-121:
mv: cannot move ‘/home/$USER/$BUILDDIR/xorg-server-dev/pkg/xorg-server-dev/usr/share/X11/xorg.conf.d/’ to ‘/home/$USER/$BUILDDIR/xorg-server-dev/pkg/xorg-server-dev/etc/X11/xorg.conf.d’: Directory not empty

I think it's best if you follow the official PKGBUILD way if installing these config files:
install -m755 -d "${pkgdir}/etc/X11"
mv "${pkgdir}/usr/share/X11/xorg.conf.d" "${pkgdir}/etc/X11/"
install -m644 "${srcdir}/10-quirks.conf" "${pkgdir}/etc/X11/xorg.conf.d/"

r08 commented on 2014-04-09 05:50

Build fail

In file included from ../include/misc.h:78:0,
from atom.c:55:
/usr/include/X11/Xdefs.h:105:10: error: expected ')' before 'OSTimePtr'
OSTimePtr /* pTimeout */,
^
In file included from atom.c:57:0:
../include/dix.h:224:54: error: expected ')' before 'WakeupHandlerProcPtr'
WakeupHandlerProcPtr
^
../include/dix.h:230:52: error: expected ')' before 'WakeupHandlerProcPtr'
WakeupHandlerProcPtr
^
atom.c: In function 'MakeAtom':
atom.c:126:26: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual]
free((char *) nd->string);
^
atom.c: In function 'FreeAtom':
atom.c:181:14: warning: cast discards '__attribute__((const))' qualifier from pointer target type [-Wcast-qual]
free((char *) patom->string);
^
make[2]: *** [atom.lo] Error 1
make[2]: Leaving directory `/home/jos/src/xorg/xserver-60014a4a98ff924ae7f6840781f768c1cc93bbab/dix'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/jos/src/xorg/xserver-60014a4a98ff924ae7f6840781f768c1cc93bbab/dix'
make: *** [all-recursive] Error 1

Det commented on 2014-02-25 06:48

Doesn't compile with the current dependencies, but at least I've cleaned up the PKGBUILD quite a bit.

MuPuF commented on 2013-11-10 17:16

It also requires "xextproto-git" but this isn't enough either:
../../os/.libs/libos.a(io.o): In function `ReadFdFromClient':
io.c:(.text+0x13c): undefined reference to `_XSERVTransRecvFd'
../../os/.libs/libos.a(io.o): In function `WriteFdToClient':
io.c:(.text+0x7b9): undefined reference to `_XSERVTransSendFd'

I'll stop here for now.

MuPuF commented on 2013-11-10 17:04

Please add libxshmfence to the dependencies.

Det commented on 2013-03-09 15:56

1.14.0-2, pull the [extra]/trunk fixes:
* https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=ac6c6cffb8a2285699f6f244e5809bcf05bd3a4b
* https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=c58a60a413fe46611c87078bdf3edb1b44ef27c6

Det commented on 2013-03-09 15:55

1.14.0-2, pull the [extra] fixes:
* https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=ac6c6cffb8a2285699f6f244e5809bcf05bd3a4b
* https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=c58a60a413fe46611c87078bdf3edb1b44ef27c6

Det commented on 2013-02-14 11:23

1.14 RC2: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.announce/1902

Det commented on 2012-12-19 22:07

1.14 RC1 is finally here: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.announce/1836

Kinda disappointing that the merge window was closed, though (at least for now).

Det commented on 2012-11-09 01:01

"Update to current git snapshot from server-1.13 branch, backport patch from git master to utilize the new pixman glyph cache": https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=fb63d6b030137baf0f1bbfce4bf63a65928687b7

Det commented on 2012-09-07 18:36

The ABI dependencies are finally being pushed through: https://projects.archlinux.org/svntogit/packages.git/commit/trunk/PKGBUILD?h=packages/xorg-server&id=1afb31e54e9dd7da41a27e9f4d1c655f97bdcbef

Det commented on 2012-09-05 22:09

Back to stable: http://lists.x.org/archives/xorg-announce/2012-September/002068.html

We'll see how long it's gonna take for it to show up in [testing].

Det commented on 2012-08-21 22:40

RC5. The final one: http://lists.x.org/archives/xorg-announce/2012-August/002059.html

Det commented on 2012-08-09 11:39

RC4: http://lists.x.org/archives/xorg-announce/2012-August/002052.html

Det commented on 2012-07-27 10:00

1.12.99.903 (1.13 RC3).

No changelog yet (http://lists.freedesktop.org/archives/xorg-announce/2012-July/), though, but the changes can be seen in git: http://cgit.freedesktop.org/xorg/xserver/

Det commented on 2012-07-27 10:00

1.12.99.903 (1.13 RC3)

No changelog yet (http://lists.freedesktop.org/archives/xorg-announce/2012-July/), though, but the changes can be seen in git: http://cgit.freedesktop.org/xorg/xserver/

Det commented on 2012-07-23 16:41

By the way, it's fixed in RC2.

Det commented on 2012-07-23 16:41

By the way, the it's fixed in RC2.

Det commented on 2012-07-12 10:13

aaight man, i understand you're having a trouble with this package, ain't that right?

i just added this here you know '-git' prefix to the 'randrproto' dependency man, aight?

there's still sometin' wrong there, tho, cuz it just won't build, you know what i'm sayin'?: http://pastebin.com/mxZa0Rfm

the same issue arises with 'xorg-server-git' so it's some dependency gettin' on my nerves, man

anywayz, peace out homeboy

jyaworski commented on 2012-07-11 17:58

Got the following on configure:

configure: error: Package requirements (fixesproto >= 5.0 damageproto >= 1.1 xcmiscproto >= 1.2.0 xtrans >= 1.2.2 bigreqsproto >= 1.1.0 xproto >= 7.0.22 randrproto >= 1.4.0 renderproto >= 0.11 xextproto >= 7.1.99 inputproto >= 2.1.99.6 kbproto >= 1.0.3 fontsproto pixman-1 >= 0.21.8 videoproto compositeproto >= 0.4 recordproto >= 1.13.99.1 scrnsaverproto >= 1.1 resourceproto >= 1.2.0 xf86driproto >= 2.1.0 glproto >= 1.4.15 dri >= 7.8.0 xineramaproto xkbfile pixman-1 >= 0.21.8 xfont >= 1.4.2 xau xdmcp) were not met:

Requested 'randrproto >= 1.4.0' but version of RandrProto is 1.3.2

Det commented on 2012-07-11 17:10

1.13 RC1 is finally here: http://www.spinics.net/lists/xorg/msg54314.html

Det commented on 2012-06-15 10:26

1.12.2.901 (1.12.3 RC1): http://lists.freedesktop.org/archives/xorg-announce/2012-June/001982.html

Nothing really interesting. Just some tiny bug fixes.

Det commented on 2012-05-30 15:21

The final is again identical to the previous RC.

Det commented on 2012-05-13 12:58

1.12.1.901-2: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xorg-server&id=0ea1f227a3f31489b48b83f648916e08a7094da1

Just some fixes from Git included.

Det commented on 2012-04-15 11:27

1.12.1: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.announce/1660

No changes since RC2 (decluding EXA_Fall_back_earlier_and_more_thoroughly_from_exaGlyphsV2.diff: https://bugs.freedesktop.org/show_bug.cgi?id=47266).

Det commented on 2012-04-10 12:19

1.12.0.902 (1.12.1 RC2): http://old.nabble.com/-ANNOUNCE--xorg-server-1.12.0.901-%281.12.1-RC1%29-tt33605693.html#a33605693

No special nvidia or evdev recommendations. The ones from [extra] work just fine.

Det commented on 2012-04-10 12:19

1.12.0.902 (1.12.1 RC2): http://old.nabble.com/-ANNOUNCE--xorg-server-1.12.0.901-%281.12.1-RC1%29-tt33605693.html#a33605693

No special nvidia or evdev recommendations. The ones from [extra] are enough.

Det commented on 2012-04-10 12:19

1.12.0.902 (1.12.1 RC1): http://old.nabble.com/-ANNOUNCE--xorg-server-1.12.0.901-%281.12.1-RC1%29-tt33605693.html#a33605693

No special nvidia or evdev recommendations. The ones from [extra] are enough.

Det commented on 2011-11-22 09:13

1.11.99.1 (1.12 development release 1): http://www.spinics.net/lists/xorg/msg53284.html

Works just fine with the latest Nvidia driver (290.10) with -ignoreABI. Needed 'inputproto-git' and 'libpciacces-git' as new dependencies. I probably recommend using 'xf86-input-evdev-git' too (for Input ABI v14), though.

Det commented on 2011-11-19 22:14

1.11.2-3: "- Fix segmentation fault due to race conditions in Record extension (FS#24653) - Update git-fixes, add commit that fixes segfault-on-exit - Add patch to fix passive grabs with XI2 clients":
http://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xorg-server&id=3dd3e886dfa1aec5bbd1bc90a9625514a12d99b9

Det commented on 2011-11-07 13:52

1.11.2-2: Added latest upstream fixes.

Det commented on 2011-07-04 04:06

Yes, as I already said the _input_ ABI is 13 ("...an unsupported input driver ABI version (have 13.0, need < 13.0)"), while the video ABI is that 11.

The evdev package available on the repos should have the input ABI of 12 but it still worked for me. If you're not using something else you could try giving a shot with the git version (xf86-input-evdev-git) [1], which should work just fine as it uses the version 13 input ABI. The build's really fast anyway, it's just a single <50kB .so file (comes up in seconds).

But still, the new X server doesn't look good (whether it be because of the Nvidia driver or the server itself) so I recommend you to use either the X server available on the repos (which is 1.10.2) or 1.10.3 RC2 (1.10.2.902), which uses the same ABIs as the repo's server but includes some of the fixes you get with 1.11 RC1. I even use 1.10.3 RC2 myself since that's the best choice for me ATM (just changed the pkgver to '1.10.2.902' and the first md5sum line to '4f6823101715b363b936a50421898680').

[1] = http://aur.archlinux.org/packages.php?ID=41665

E: also, I'm not sure but the text "This server has a video driver ABI version of 11.0 that this driver does not officially support." might still come up even if you used the 280.04 Nvidia driver since the support for X server 1.11 (video ABI 11) is only preliminary and not supposed to work as it should.

Det commented on 2011-07-04 04:02

Yes, as I already said the _input_ ABI is 13 ("...an unsupported input driver ABI version (have 13.0, need < 13.0)"), while the video ABI is that 11.

The evdev package available on the repos should have the input ABI of 12 but it still worked for me. If you're not using something else you could try giving a shot with the git version (xf86-input-evdev-git) [1], which should work just fine as it uses the version 13 input ABI. The build's really fast anyway, it's just a single <50kB .so file (comes up in seconds).

But still, the new X server doesn't look good (whether it be because of the Nvidia driver or the server itself) so I recommend you to use either the X server available on the repos (which is 1.10.2) or 1.10.3 RC2 (1.10.2.902), which uses the same ABIs as the repo's server but includes some of the fixes you get with 1.11 RC1. I even use 1.10.3 RC2 myself since that's the best choice for me ATM (just changed the pkgver to '1.10.2.902' and the first md5sum line to '4f6823101715b363b936a50421898680').

[1] = http://aur.archlinux.org/packages.php?ID=41665

karabaja4 commented on 2011-07-03 20:37

Little help with this please:

================ WARNING WARNING WARNING WARNING ================
This server has a video driver ABI version of 11.0 that this
driver does not officially support. Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
=================================================================
(WW) NVIDIA: The driver will continue to load, but may behave strangely.
(WW) NVIDIA: This driver was compiled against the X.Org server SDK from git commit b6c7b9b2f39e970cedb6bc1e073f901e28cb0fa3 and may not be compatible with the final version of this SDK.
(WW) NVIDIA: This server has an unsupported input driver ABI version (have 13.0, need < 13.0). The driver will continue to load, but may behave strangely.
(WW) module ABI major version (12) doesn't match the server's version (13)

and my xorg doesn't load (kinda freezes), that's using 280.04 nvidia binary driver?

Det commented on 2011-07-01 22:31

And of course, the input ABI of the new X server is v13 - the _video_ ABI is v11.

Det commented on 2011-06-30 17:37

Actually, don't bother. The new X server _sucks_. Or at least it does so with the latest nvidia driver (transparency issues, content of other windows is displayed in others, etc.).

Det commented on 2011-06-30 08:20

Finally. The nvidia driver 280.04 supports the new ABI, thus it supports the new X server 1.11 series.

Det commented on 2011-06-01 22:05

A lot of juicy changes with 1.11 RC1. All the 'extra patches' from [extra]'s xorg-server are included (in the sources) (with the exception of the 'die-ugly-pattern' fix).

Changelog: http://www.spinics.net/lists/xorg/msg52652.html

E: but of course, remember that if your video driver's ABI hasn't been bumped to this (13.0), you won't be able to use it. Nvidia driver 275.09's ABI is 12.0 and it didn't work even with force-loading.

Det commented on 2011-06-01 22:01

A lot of juicy fixes with 1.11 RC1. All the 'extra patches' from [extra]'s xorg-server are included (in the sources) (with the exception of the 'die-ugly-pattern' fix).

Changelog: http://www.spinics.net/lists/xorg/msg52652.html

Det commented on 2011-05-30 21:15

Synced with [extra]'s(/[testing]'s) xorg-server changes:

[extra]: Add latest fixes from upstream 1.10 branch
Patch autoconfig to use nouveau/nv/nvidia instead of only nv

([testing]: Build with mesa and resourceproto from testing)

Det commented on 2011-05-29 09:27

1.10.2: http://lists.freedesktop.org/pipermail/xorg/2011-May/053143.html

Det commented on 2011-05-21 07:37

1.10.1.902 (1.10.2 RC2): http://www.mail-archive.com/xorg@lists.freedesktop.org/msg14243.html

Det commented on 2011-05-07 15:44

1.10.1.901 (1.10.2 RC1). Release notes for the excited: http://www.mail-archive.com/xorg@lists.freedesktop.org/msg14173.html

Det commented on 2011-04-11 19:07

Added the patches from [extra]'s xorg-server. The log states the changes as following (http://projects.archlinux.org/svntogit/packages.git/commit/xorg-server/trunk/PKGBUILD?id=4a68d852f50e8d120f0cc25f445ec399e779d2cf):

"[..] add patches from xserver-next, add pointer barrier support"

Again, I encourage people to rather use [extra]'s xorg-server whenever they got the same version I have here - such as now. If you want to optimize your Xorg server by that 1-3% and/or modify the features then that's of course your choice.

Det commented on 2011-02-26 10:46

1.10 released. Only minor differences since RC3 (http://www.spinics.net/lists/xorg/msg52105.html):
"Since RC3, we've had a few build fixes made, and one regression fixed (a crasher on sparc and other architectures)."

Det commented on 2011-02-25 09:47

1.10 RC3 (1.9.99.903) released (randrproto dependency removed completely): http://www.listware.net/201102/xorg-general/89927-announce-xorg-server-1999903.html. They bumped the video driver ABI _again_ (10.0) so even the latest beta Nvidia drivers (270.29) are out of question (they support up to 9.0).

Det commented on 2011-02-20 08:34

Seems like an issue with randrproto. The guy who responded to this report said it's a regression: http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/19002

E: taken from here it seems randr is a builtin extension: http://lists.x.org/archives/xorg/2008-September/038468.html - as adviced I tried to set "noRRExtension" to "TRUE" in 'xorg-server/os/utils.c' to disable randr support but it didn't work. We'll just need to wait until randrproto gets fixed.

Det commented on 2011-02-19 22:37

Seems like an issue with randrproto. The guy who responded to this report said it's a regression: http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/19002

E: taken from here it seems randr is a builting extension: http://lists.x.org/archives/xorg/2008-September/038468.html - as adviced I tried to set "noRRExtension" to "TRUE" in 'xorg-server/os/utils.c' to disable randr support but it didn't work. We'll just need to wait until randrproto gets fixed.

Det commented on 2011-02-19 22:20

Seems like an issue with randrproto. The guy who responded to this report said it's a regression: http://comments.gmane.org/gmane.comp.freedesktop.xorg.devel/19002

Vi0L0 commented on 2011-02-19 21:44

i cannot compile it, i checked everything like own pkgbuilds and compiling from sources, i even tried compiling on fresh system via virtual machine with 1 cpu ;P, nothing, still same error:

rrcrtc.c: In function ‘RRConvertCrtcConfig’:
rrcrtc.c:1512:27: error: ‘RR_CurrentScanoutPixmap’ undeclared (first use in this function)
rrcrtc.c:1512:27: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [rrcrtc.lo] Error 1

why oh why? :(

Det commented on 2011-01-09 13:19

@mushroomboy, don't install packages straight with 'makepkg' and you'll notice how wonderfully the AUR tool you're using (whether it'd be packer, yaourt (ugh), bauerbill, clyde or whatever) fetches/installs the required (make) dependencies (xextproto-/randrproto-git) that I uploaded here in the AUR and defined in the PKGBUILD :).

I've got no idea about that "something else is wrong" part as this package worked here before and still did when I just tried it (not that it _actually_ worked (since I got Nvidia driver), but it _builds_). Maybe it's just because you use yaourt or something? -Please don't. It's buggy, old, barely maintained, still lacks some AUR functionality and, quite frankly, happens to be just a piece of crap. So (you really really should) stop using it immediately (or at least stop complaining about the problems _it_ has (there should be quite a lot of them) and not _my packages_).

In addition unless your video driver supports Xorg Server 1.10RC1 (Catalyst and Nvidia drivers, even the latest ones don't) you shouldn't even concider using this package (yet).

Det commented on 2011-01-09 13:18

@mushroomboy, don't install packages straight with 'makepkg' and you'll notice how wonderfully the AUR tool you're using (whether it'd be packer, yaourt (ugh), bauerbill, clyde or whatever) fetches/installs the required (make) dependencies (xextproto-/randrproto-git) that I uploaded here in the AUR and defined in the PKGBUILD :).

I've got no idea about that "something else is wrong" part as this package worked here before and still did when I just tried it (not that it _actually_ worked (since I got Nvidia driver), but it _builds_). Maybe it's just because you use yaourt or something? -Please don't. It's buggy, old, barely maintained, still lacks some AUR functionality and, quite frankly, happens to be just a piece of crap. So (you really really should) stop using it immediately (or at least stop complaining about the problems _it_ has (there should be quite a lot of them) and not _my packages_).

In addition unless your video driver supports Xorg Server 1.10RC1 (Catalyst and Nvidia drivers, even the latest ones don't) you shouldn't even concider using this package yet.

Det commented on 2011-01-09 13:18

@mushroomboy, don't install packages straight with 'makepkg' and you'll notice how wonderfully the AUR tool you're using (whether it'd be packer, yaourt (ugh), bauerbill, clyde or whatever) fetches/installs the required (make) dependencies (xextproto-/randrproto-git) that I uploaded here in the AUR and defined in the PKGBUILD :).

I've got no idea about that "something else is wrong" part as this package worked here before and still does when I just tried it (not that it _actually_ worked (since I got Nvidia driver), but it _builds_). Maybe it's just because you use yaourt or something? -Please don't. It's buggy, old, barely maintained, still lacks some AUR functionality and, quite frankly, happens to be just a piece of crap. So (you really really should) stop using it immediately (or at least stop complaining about the problems _it_ has (there should be quite a lot of them) and not _my packages_).

In addition unless your video driver supports Xorg Server 1.10RC1 (Catalyst and Nvidia drivers, even the latest ones don't) you shouldn't even concider using this package yet.

Anonymous comment on 2011-01-09 10:57

xextproto-git randrproto-git are required

[update]

something else is wrong with the pkgbuild, I could build the src itself with ./configure and just make and everything works fine but when I try it with the pkgbuild it fails.

Det commented on 2010-12-10 17:02

SYNOPSIS (to combine two long posts): I've now uploaded all that *proto stuff here in AUR (used in the build) as Git versions. I've also since fixed the non-working *proto packages that all got the same "validation" error.

Until the new xext-/ranrdproto's will be released this package uses their git versions (since the new Xorg server (1.10 RC1) requires 'randrproto>=1.4.0' and 'xextproto>=7.1.99').

I've just now also fixed this one (the server itself) as in the end it also got the same "validation" error.

E: Just remember that because of the new ABIs there is currently no working driver for the new Xorg server. I just confirmed here with the Nvidia driver (260.19.26) that even the "-ignoreABI" flag doesn't help.

Det commented on 2010-12-10 16:57

SYNOPSIS (to combine two long posts): I've now uploaded all that *proto stuff here in AUR (used in the build) as Git versions. I've also since fixed the non-working *proto packages that all got the same "validation" error.

Until the new xext-/ranrdproto's will be released this package uses their git versions (since the new Xorg server (1.10 RC1) requires 'randrproto>=1.4.0' and 'xextproto>=7.1.99').

I've just now also fixed the this one (the Xorg server itself) as in the end it also got the same "validation" error.

E: Just remember that because of the new ABIs there is currently no working driver for the new Xorg server. I just confirmed here with the Nvidia driver (260.19.26) that even the "-ignoreABI" flag doesn't help.

Det commented on 2010-12-10 16:16

SYNOPSIS (to combine two long posts): I've now uploaded all that *proto stuff here in AUR (used in the build) as Git versions. I've also since fixed the non-working *proto packages that all got the same "validation" error.

Until the new xext-/ranrdproto's will be released this package uses their git versions (since the new Xorg server (1.10 RC1) requires 'randrproto>=1.4.0' and 'xextproto>=7.1.99').

I've just now also fixed the this one (the Xorg server itself) as in the end it also got the same "validation" error.

Det commented on 2010-12-10 16:15

SYNOPSIS (to combine two long posts): I've now uploaded all that *proto stuff here in AUR (used in the build) as Git versions. I've also since fixed the non-working *proto packages that all got the same "validation" error.

Until the new xext-/ranrdproto's will be released this package uses their git versions since the new Xorg server (1.10 RC1) requires 'randrproto>=1.4.0' and 'xextproto>=7.1.99'.

I've just now also fixed the same validation error this one gets in the build (the Xorg server itself).

Det commented on 2010-12-10 16:15

SYNOPSIS (to combine two long posts): I've now uploaded all that *proto stuff here in AUR (used in the build) as Git versions. I've also since fixed the non-working *proto packages that all got the same "validation" error.

Until new xext-/ranrdproto's will be released this package uses their git versions since the new Xorg server (1.10 RC1) requires 'randrproto>=1.4.0' and 'xextproto>=7.1.99'.

I've just now also fixed the same validation error this one gets in the build (the Xorg server itself).

Det commented on 2010-12-10 16:14

SYNOPSIS (to combine two long posts): I've now uploaded all that *proto stuff here in AUR (used in the build) as Git versions. I've also since fixed the non-working *proto packages that all get the same "validation" error.

Until new xext-/ranrdproto's will be released this package uses their git versions since the new Xorg server (1.10 RC1) requires 'randrproto>=1.4.0' and 'xextproto>=7.1.99'.

I've just now also fixed the same validation error this one gets in the build (the Xorg server itself).

Det commented on 2010-12-10 16:14

Synapsis (to combine two long posts): I've now uploaded all that *proto stuff here in AUR (used in the build) as Git versions. I've also since fixed the non-working *proto packages that all get the same "validation" error.

Until new xext-/ranrdproto's will be released this package uses their git versions since the new Xorg server (1.10 RC1) requires 'randrproto>=1.4.0' and 'xextproto>=7.1.99'.

I've just now also fixed the same validation error this one gets in the build (the Xorg server itself).1

Det commented on 2010-12-07 21:32

UPDATE: I've now uploaded randrproto-git and xextproto-git (along with a lot of other *proto stuff) but sadly, as it seems, xextproto-git doesn't compile at the moment. Actually a few hours ago every other of these packages I uploaded did but now a lot of them are beginning to get the same error too.

So maybe those commits will be reverted or a new workaround implemented. Who knows..

Det commented on 2010-12-07 09:33

NOTE: 1.10 RC1 doesn't build until randrproto and xextproto in the repos will be updated (until the new ones will be released).

I've left the "old" 1.9.3 RC2 pkgver & md5sums to the PKGBUILD in case somebody wants to still use the absolute latest bleeding edge xorg-server ;). Just remember that your AUR helper (whatever it is) will constantly be updating this package because of the higher pkgver.

Det commented on 2010-12-07 09:31

1.10.0 RC1 doesn't build until randrproto and xextproto in the repos will be updated (until the new ones will be released).

I've left the "old" 1.9.3 RC2 pkgver & md5sums to the PKGBUILD in case somebody wants to still use the absolute latest bleeding edge xorg-server ;). Just remember that your AUR helper (whatever it is) will constantly be updating this package because of the higher pkgver.

Det commented on 2010-11-21 13:39

Forgot to mention that this package is now split the same way as [extra]'s/[testing]'s xorg-server. Credit goes here: https://bugs.archlinux.org/task/16394#comment68053

Det commented on 2010-11-01 00:11

Nothing really interesting with 1.9.2 but a release is a release: http://www.pubbs.net/201010/xorg/50321-announce-xorg-server-192.html

Det commented on 2010-10-15 21:41

Moving on. RC2: http://web.archiveorange.com/archive/v/Ky751RGcl9N37o5ybEC6

Det commented on 2010-10-14 07:43

Synced with [testing]'s xorg-server. Log: Add last patch from git, fixes mouse issues in SDL games

Det commented on 2010-10-02 05:46

1.9.1 RC1 released. You can read the change log here: http://www.listware.net/201010/xorg-general/2391-announce-xorg-server-190901.html

Det commented on 2010-09-03 16:03

Same happened again, Glib2 2.25.15 was released a coupple of days ago.. though it's gonna hit [extra] soon, which might make glib2-newest unnecessary.

Det commented on 2010-08-24 19:20

A partial sync with [Testing]'s xorg-server (now splitted into several packages). You probably should get that instead of this one - we are no Gentoo, you know.

(You can) Read about the decisions made with the new release in here: http://mailman.archlinux.org/pipermail/aur-general/2010-August/010196.html

Det commented on 2010-08-24 19:20

Partial sync with [Testing]'s xorg-server (now splitted into several packages). You probably should get that instead of this one - we are no Gentoo, you know.

(You can) Read about the decisions made with the new release in here: http://mailman.archlinux.org/pipermail/aur-general/2010-August/010196.html

Det commented on 2010-08-24 16:32

A partial sync with [Testing]'s xorg-server. The conflicts=() line I won't _at least yet_ remove, and even if I did, 'xorg-server' would stay there. The [Testing]'s xorg-server is also splitted into several packages. You probably should get that instead of this one - we are no Gentoo, you know.

(You can) Read about the decisions made with the new release in here: http://mailman.archlinux.org/pipermail/aur-general/2010-August/010196.html

Det commented on 2010-08-24 16:32

A partial sync with [Testing]'s xorg-server. The conflicts=() line I won't _at least yet_ remove, and even if I did, 'xorg-server' would stay there. The [Testing]'s xorg-server is also splitted into several packages. You probably should get that instead of this one - we are no Gentoo, you know.

(You can) Read about it here: http://mailman.archlinux.org/pipermail/aur-general/2010-August/010196.html

Det commented on 2010-08-24 16:27

Sync with [Testing]'s xorg-server (the dependencies I haven't _at least yet_ removed though). You probably should get that instead of this one - we are no Gentoo, you know.

Det commented on 2010-08-24 15:52

Sync with [Testing]'s xorg-server. You probably should get that instead of this one - we are no Gentoo, you know.

Det commented on 2010-08-22 08:04

So, for those Nvidia proprietary driver users (you made the right choice) you should know that there's no 'official' support for the xorg video ABI v8 in the Nvidia 256.44 drivers so you must use the -ignoreABI flag to fire up Xorg-server 1.9 as either "startx/xinit -- -ignoreABI" or create e.g. a "10-ServerFlags.conf" in /etc/X11/xorg.conf.d/ with this content: http://aur.pastebin.com/QVzcDztg

Det commented on 2010-08-13 21:49

a

Det commented on 2010-08-13 21:49

f

Det commented on 2010-08-12 20:04

You know, only a specific version of a package can be provided (neither is it a good practice to provide xorg-server 1.7 with 1.9) so a stupid "xorg-server=${pkgver}" is just fine.

As a sidenote, I shortend the "libgl included" make-/dependencies lines with ${(make)depends[*]} variable so that they include everything the "no-libgl" lines do. The downside is that the "Dependencies" list you see at this page screws up.. but who cares.

Det commented on 2010-08-12 20:03

You know, only a specific version of a package can be provided (neither is it a good practice to provide xorg-server 1.7 with 1.9) so a stupid "xorg-server=${pkgver}" is just fine.

As a sidenote, I shortend the "libgl included" make-/dependencies lines with ${(make)depends[*]} variable so that they include everything the "no-libgl" lines do. The downside is that the "Dependencies" list you see at this page screws up.. but who cares.

Det commented on 2010-08-12 19:48

You know, only a specific version of a package can be provided (neither is it a good practice to provide xorg-server 1.7 with 1.9) so a stupid "xorg-server=${pkgver}" is just fine.

As a sidenote, I shortend the "libgl included" make-/dependencies lines with ${(make)depends[*]} variable so that they include everything the "no-libgl" lines do. The downside is that the "Dependencies" list you see at this page screws up.. but who cares.

Det commented on 2010-08-12 19:46

You know, only a specific version of a package can be provided (neither is it a good practice to provide xorg-server 1.7 with 1.9) so a stupid "xorg-server=1.8.99.905" is just fine.

As a sidenote, I shortend the "libgl included" make-/dependencies lines with ${(make)depends[*]} variable so that they include everything the "no-libgl" lines do. The downside is that the "Dependencies" list you see at this page screws up.. but who cares.

Anonymous comment on 2010-08-12 08:54

Maybe you should modify the "provides" entry as "xorg-server>=1.7.3" to allow xf86-video-intel-git to build with your package

Det commented on 2010-08-01 10:24

The Nvidia driver 256.44 pre-release driver has been released. So if you are an Nvidia user and insist on using/toying/whatever with this package (xorg-server 1.9) you can either choose Nouveau or the proprietary Nvidia driver and the git versions of the (xf86-input-)mouse/keyboard drivers (can be found here in AUR).

For the (über) Evdev driver another Git package would need to be created but I don't think anybody cared even if I did it :).

Det commented on 2010-08-01 10:24

The Nvidia driver 256.44 pre-release driver has been released. So if you are an Nvidia user and insist on using/toying/whatever with this package (xorg-server 1.9) you can either choose Nouveau or the proprietary Nvidia driver and the git versions of the (xf86-input-)mouse/keyboard drivers (can be found here in AUR).

For the (über) Evdev driver another git package would need to be created but I don't think anybody cared even if I did it :).

Det commented on 2010-08-01 10:24

The Nvidia driver 256.44 pre-release driver has been released. So if you are an Nvidia user and insist on using/toying/whatever with this package (xorg-server 1.9) you can either choose Nouveau or the proprietary Nvidia driver and the git versions of the (xf86-input-)mouse/keyboard drivers (can be found here in AUR).

For the Evdev driver another git package would need to be created but I don't think anybody cared even if I did it :).

Det commented on 2010-08-01 10:23

The Nvidia driver 256.44 pre-release driver has been released. So if you are an Nvidia user and insist on using/toying/whatever with this package (xorg-server 1.9) you can either choose Nouveau or the proprietary Nvidia driver and the git versions of the (xf86-input-)mouse/keyboard drivers (can be found here in AUR).

For the evdev driver another git package would need to be created but I don't think anybody cared even if I did it :).

Det commented on 2010-08-01 10:23

The Nvidia driver 256.44 pre-release driver has been released. So if you are an Nvidia user and insist on using/toying/whatever with this package (xorg-server 1.9) you can either choose Nouveau or Nvidia (the proprietary) driver and the git versions of the (xf86-input-)mouse/keyboard drivers (can be found here in AUR).

For the evdev driver another git package would need to be created but I don't think anybody cared even if I did it :).

Det commented on 2010-08-01 10:22

The Nvidia driver 256.44 pre-release driver has been released. So if you an Nvidia user and insist on using/toying/whatever with this package (xorg-server 1.9) you can either choose Nouveau or Nvidia (the proprietary) driver and the git versions of the (xf86-input-)mouse/keyboard drivers (can be found here in AUR).

For the evdev driver another git package would need to be created but I don't think anybody cared even if I did it :).

Det commented on 2010-07-18 12:56

Yeah, not just the video ABI moved from 7 to 8 but also the 'input' (or whatever it was) ABI moved from 9 to 11 so you do indeed need the git versions from those too (learned this yesterday).

Also you may want to use (xf86-input-)evdev instead of (xf86-input-)keyboard/mouse for the sake of simplicity and input hotplugging.. but that's your choice. Just remember to remove (or comment) the touchpad "InputClass" part in your (/etc/X11/xorg.conf.d)10-evdev.conf (you can check our stunning Wiki for more info).

Det commented on 2010-07-18 12:54

Yeah, not just the video ABI moved from 7 to 8 but also the 'input' (or whatever it was) ABI moved from 9 to 11 so you do indeed need the git versions from those too (learned this yesterday).

Also you may want to use (xf86-input-)evdev instead of (xf86-input-)keyboard/mouse because that's the 'new & improved' method.. but that's your choice. Just remove (or comment) the touchpad "InputClass" part in your (/etc/X11/xorg.conf.d)10-evdev.conf (you can check our stunning Wiki for more info).

Det commented on 2010-07-18 12:47

Yeah, not just the video ABI moved from 7 to 8 but also the 'input' (or whatever it was) ABI moved from 9 to 11 so you do indeed need the git versions from those too (learned this yesterday).

Also you may want to use (xf86-input-)evdev instead of (xf86-input-)keyboard/mouse. Our Wiki is luckily stunning.

cb474 commented on 2010-07-18 06:28

Thanks for the explanation Det. I figured out that I had to install xorg-server-dev first and then install xf86-video-intel second (and edit its pkgbuild so it saw xorg-server-dev as a dependency), because xf86-video-intel builds against whatever version of xorg-server is already installed. But after that I still couldn't get past the GDM login screen. I don't know if xorg was locking up or just the keyboard and mouse weren't working. Perhaps I need the git versions of xf86-input-keyboard, xf86-input-mouse, and xf86-input-snypatics also?

Det commented on 2010-07-16 13:45

Fixed the build. I'm not exactly sure what was wrong but it's not anymore.

Det commented on 2010-07-16 10:39

More minor tweaks.

Det commented on 2010-07-14 08:36

As long as you get your driver from Git, it will most likely work.

It's the proprietary drivers (Nvidia and Catalyst) that need those significant changes.

Yeah, and you don't need to install anything else than the 'Git video driver' for Xorg server 1.9 RC4+. Unless of course if you wouldn't have libgl or a providing package (nvidia-utils or catalyst) installed (e.g. with new install of Arch) as I made a variable to the PKGBUILD ('screwlibgl=1') that by default assumes you have one and therefore removes libgl from (make)dependencies. Hence you wouldn't need to uninstall the conflicting proprietary drivers when building this package to have them installed again afterwards (because they already provide libgl themselves).

Det commented on 2010-07-13 14:31

As long as the driver is open source and you get it from Git, it will most likely work.

It's the proprietary drivers that need those significant changes.

Yeah, and you don't need to install anything if else than the 'Git driver' and this package if you already have ligl (as you most likely do) as I made a variable that by default assumes you have it installed and thus you don't need to uninstall nvidia-utils nor catalyst when building this package (the proprietary drivers) because they already provide libgl.

cb474 commented on 2010-07-13 03:00

If I want to try running this are there other packages I need to install? After I installed this xorg pacakge, GDM fails to start. I have the git version of xf86-video-intel. Will that work with this version of xorg or is the intel driver not supporting it yet?

Det commented on 2010-07-09 23:49

Minor grammatical pedantism. No need to bump the pkgrel.

Det commented on 2010-07-03 17:39

Don't use the new RC(4) until your video driver starts supporting it: http://lists.freedesktop.org/archives/xorg/2010-July/050640.html

Det commented on 2010-07-02 17:57

New Nvidia driver users:
http://lists.freedesktop.org/archives/xorg/2010-July/050641.html

Det commented on 2010-07-02 17:16

The 1.9RC4 doesn't work with Nvidia driver. The reason is not with the xorg-server's mi overlay support, as I thought it was. Here's my question and the answer I got in the mailing list:
http://lists.freedesktop.org/archives/xorg/2010-July/050641.html

Det commented on 2010-07-02 17:16

The 1.9RC4 doesn't work with Nvidia driver. The reason is not with the xorg-server's mi overlay support, as I thought it was. Here's my question in the mailing list:
http://lists.freedesktop.org/archives/xorg/2010-July/050641.html

Det commented on 2010-07-02 17:15

The 1.9RC4 doesn't work with Nvidia, the reason is not with the mi overlay, as I thought it was. Here's my question in the mailing list:
http://lists.freedesktop.org/archives/xorg/2010-July/050641.html

Det commented on 2010-07-02 16:19

As 1.9 RC2, Xorg server RC4 doesn't support the 'mi overlay' that Nvidia driver uses and reports it like this when starting X (start, xinit, dm, whatever):
dlopen: /usr/lib/xorg/modules/drivers/nvidia_drv.so: undefined symbol: WindowTable

More reading:
http://www.phoronix.com/scan.php?page=news_item&px=ODM1Nw
http://lists.freedesktop.org/archives/xorg/2010-June/050547.html

There was no sign of the 'mi overlay' support conversation in here, though (so I started one):
http://lists.freedesktop.org/archives/xorg/2010-July/

Det commented on 2010-07-02 15:58

As 1.9 RC2, Xorg server RC4 doesn't support the 'mi overlay' that Nvidia driver uses and reports it like this when starting X (start, xinit, dm, whatever):
dlopen: /usr/lib/xorg/modules/drivers/nvidia_drv.so: undefined symbol: WindowTable

More reading:
http://www.phoronix.com/scan.php?page=news_item&px=ODM1Nw
http://lists.freedesktop.org/archives/xorg/2010-June/050547.html

No sign of the 'mi overlay' support conversation in here, though:
http://lists.freedesktop.org/archives/xorg/2010-July/

Det commented on 2010-07-02 15:58

As 1.9 RC2, RC4 doesn't support the 'mi overlay' that Nvidia driver uses and reports it like this when starting X (start, xinit, dm, whatever):
dlopen: /usr/lib/xorg/modules/drivers/nvidia_drv.so: undefined symbol: WindowTable

More reading:
http://www.phoronix.com/scan.php?page=news_item&px=ODM1Nw
http://lists.freedesktop.org/archives/xorg/2010-June/050547.html

No sign of the 'mi overlay' support conversation in here, though:
http://lists.freedesktop.org/archives/xorg/2010-July/

Det commented on 2010-07-02 06:39

Bump to 1.9 RC4.

Det commented on 2010-07-02 06:31

Bump to 1.9 RC4.

Det commented on 2010-07-02 06:29

Bump to RC4.

Det commented on 2010-06-29 20:02

Added the package() function.

Det commented on 2010-06-29 13:25

Could you disown this package :)? I only don't have my packages adopted so that anybody can update them (thunderbird-beta, vlc-dev and this one) and now I'd be about to (not to a newer version of course, though).

Det commented on 2010-06-29 13:25

Could you disown this package :)? I only don't have my packages adopted so that anybody can update them (thunderbird-beta, vlc-dev and this one) and now I'd be about to (not a newer version of course, though).

Det commented on 2010-06-29 13:24

Could you disown this package :)? I only don't have my packages adopted so that anybody can update them (thunderbird-beta, vlc-dev and this one) and now I'd be about to (the PKGBUILD).

Det commented on 2010-06-29 13:15

Could you disown this package :)? I only don't have my packages adopted so that anybody can update them and now I'd be about to.

Det commented on 2010-06-29 13:13

Added the package() function and a variable whether you already have a package providing libgl, those being catalyst and nvidia driver (enabled by default - notice this if somehow you would install this package without libgl or nvidia/catalyst driver).

Det commented on 2010-06-29 13:12

Added the package() function and a variable whether you already have a package providing libgl, those being catalyst and nvidia driver (enabled by default - notice this if somehow you would install this package without libgl or nvidia and catalyst driver).

Det commented on 2010-06-29 13:12

Added the package() function and a variable whether you already have a package providing libgl, those being catalyst or nvidia driver (enabled by default - notice this if somehow you would install this package without libgl or nvidia and catalyst driver).

Det commented on 2010-06-29 13:12

Added the package() function and a variable whether you already have a package providing libgl, catalyst or nvidia driver (enabled by default - notice this if somehow you would install this package without libgl or nvidia and catalyst driver).

Det commented on 2010-06-27 08:05

Libgl is of course needed to be either removed from dependencies or installed after removing nvidia, ati driver, etc.

But I mean that's only if you don't have either libgl, nvidia, ati driver, etc.

Det commented on 2010-06-27 07:54

Xorg-server 1.9 RC3. The one in [extra] is surprisingly 1.8.2 RC2 but I want to have the absolute bleeding edge one.