On Mon, 2008-09-01 at 01:07 +0200, Xavier wrote:
> On Sun, Aug 31, 2008 at 8:37 PM, Jan de Groot <firstname.lastname@example.org> wrote:
> > Xorg-server 1.5RC6 (220.127.116.116) 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 :
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,