On Mon, 2008-09-01 at 01:07 +0200, Xavier wrote:

On Sun, Aug 31, 2008 at 8:37 PM, Jan de Groot wrote:

...

Xorg-server 1.5RC6 (1.4.99.906) enters tesing. This version of xorg-server includes input hotplugging using hal, better EXA support and less memory usage. Note that this version requires an upgrade of all videodrivers. All videodrivers shipped with X.Org have been rebuilt to reflect this change. Nvidia drivers don't seem to need a rebuild, while AMD's catalyst drivers don't support the new X.Org version. Fglrx users should not upgrade to this version.

Please give this version of X.Org an extensive test run and report bugs.

I don't think any of the following are really bugs, at least they didn't cause me any troubles, so I am just giving feedbacks here.

1) As reported in FS#11357, Xorg failed to start because of RgbPath option which is no longer valid. And this is the main change I saw when I generated a new config with Xorg -configure.

This is something I noticed also. As the error you get is clear about it, I don't consider it a bug. The xorg-server package ships without a config, so anything in that file which doesn't work is a configuration error, not a packaging error.

2) I did not have evdev installed initially, and my keyboard settings worked fine. I saw a lot of warnings in Xorg.0.log about evdev missing so I tried to install it. After that, it seems my keyboard and mouse section in xorg.conf are ignored, it apparently uses evdev by default. I simply picked the keyboard layout in gnome gui, but I am not sure how it selects it, is it equivalent to setxkbmap? Otherwise the right way to configure it is to edit some hal config file?

Yes, this is configured from /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi. Copy it to /etc/hal/fdi/policy and modify it, or delete the file completely to disable hotplugging. There seems to be a flag to disable input hotplugging from xorg.conf, but I don't remember which option it was.

3) I am using the intel driver and get a strange warning when running glxinfo or glxgears : Failed to initialize TTM buffer manager. Falling back to classic. And glxgears seems pretty slow. But I tried an opengl game (bzflags), and it ran amazingly well. I am pretty sure it ran much better than last time I tried.

glxgears is not a benchmark. The reason why you're seeing only 67.500 fps constantly in glxgears is enabling vsync in the intel driver to fix tearing. This change was done somewhere between mesa 7.1rc3 and 7.1rc4. I git bisected it and found a commit that enables vsync by default. Disabling vsync from ~/.drirc will give 700'ish framerates again.

I found a report about the same TTM message, except I did not see any crash : http://bugs.freedesktop.org/show_bug.cgi?id=13922

7.1rc3 drivers can crash with a segfault after giving this message. 7.1 final doesn't segfault anymore. The reason you're seeing this message is because 7.1 drivers contain TTM code. TTM is deprecated before it was finished. The mesa drivers support it, but it's not available in libdrm, the kernel modules and the 2D drivers. That's why you get the message. Just wait for kernel 2.6.28, mesa 7.2, libdrm 2.4.0 and xf86-video-intel 2.5.0 and we'll have GEM, which is intels alternative for TTM.

4) also some new scary intel warnings in the log (repeated twice) : (WW) intel(0): ESR is 0x00000001, instruction error (WW) intel(0): Existing errors found in hardware state.

Don't know what it does, but there's loads of weird warnings in Xorg.log, as long as they're warnings and things continue to work, ignore them :)

On Mon, Sep 1, 2008 at 2:23 AM, Allan McRae wrote:

After upgrading, X failed to start with a message about libpciaccess. Installing that fixed the problem... Is this a missing dep somewhere?

The dep is not missing, so this might be a pacman bug.. http://bugs.archlinux.org/task/11367 To anyone who did not upgrade yet to the latest xorg-server (currently in testing) : Please check that when you upgrade, libpciaccess is indeed in the target list. If anyone sees that it is missing, canceling the operation and running it again with --debug would be very helpful.

On Tue, Sep 2, 2008 at 5:01 PM, Xavier wrote:

And just for clarification, this looks like a very special bug which appears only under some special circumstances. That is why it is very difficult to reproduce. And that is why I had to ask everyone if they can check whether it is reproducible on their system.

In other words, it will go fine for most people. We are only interested by the few cases where it does not go fine :)

Ok, I think you can forget about this problem, it is likely just an user (developer?) mistake which was already made before : http://archlinux.org/pipermail/pacman-dev/2008-March/011491.html That is, don't use the -d flag which skips all the dependency checking, otherwise you are asking for troubles.

On Thu, 2008-09-04 at 23:02 -0500, Dan McGee wrote:

I am having problems with nvidia, specifically the nvidia-96xx driver:

(II) LoadModule: "nvidia" (II) Loading /usr/lib/xorg/modules/drivers//nvidia_drv.so dlopen: /usr/lib/xorg/modules/drivers//nvidia_drv.so: undefined symbol: AllocateScreenPrivateIndex (EE) Failed to load /usr/lib/xorg/modules/drivers//nvidia_drv.so (II) UnloadModule: "nvidia" (EE) Failed to load module "nvidia" (loader failed, 7)

A recompile of the driver didn't seem to help anything. I'm booted up with the nv driver now, which works OK, but not nearly as good (and only 2D) as the closed-source driver unfortunately.

Any thoughts on this? I know so little about X/graphics drivers.

Yes, nvidia doesn't support xorg-server 1.5 in their legacy drivers yet. For now it means switching to the free drivers. The status is the same for ATI users who are using catalyst now. To use xorg-server 1.5 they will have to switch to xf86-video-ati or radeonhd.