Summary of xorg -> 7.4 with nvidia driver without hal
portsuser at larseighner.com
Thu Feb 12 00:34:36 PST 2009
On Thu, 12 Feb 2009, Olivier SMEDTS wrote:
> 2009/2/12 Lars Eighner <portsuser at larseighner.com>:
>> Summary of experiences upgrading xorg -> 7.4 with nvidia-driver without hal
>> I have had many misadventures in upgrading to xorg 7.4 with nvidia-driver.
>> This is a summary of what worked. Most of these things are not original
>> but have been derived of things posted here and to the ports mailing list.
>> I have however tried to eliminate some of the stuff that seemed unnecessary
>> or did not help.
>> This assumes you have been more or less sucessfully been running xorg 7.3
>> with the nvidia driver with or without hal and want to upgrade to xorg 7.4
>> without hal.
>> 1. If you have previously built xorg with hal, beware of manually changing
>> /var/db/ports/xorg/options manually unless you know what you are doing. In
>> general the *value* of config flags is never tested, but only the existence
>> of the flags. So changing WITH_HAL=true is *not* likely to work. Instead,
>> this flag needs to be replaced by WITHOUT_HAL=true (that is *not* by
>> 2. If you did not rebuild libxcb and all its dependancies as advised in
>> UPGRADING 20090123 do not do so until you are ready to upgrade xorg. This
>> is merely a time-saving measure. The dependencies of libxcb include pretty
>> much everything x-related, so there is no point in doing it with the old
>> ports tree, if you are immediately going to build xorg with a newer ports
>> 3. Upgrade xorg. If you do this immediately after 2, there won't be much
>> to it.
>> 4. Rebuild nvidia-driver.
>> 5. Now the problem is, the nvidia-driver version of libwfb.so is broken.
>> When nvidia-driver built, it should have preserved the xorg lib as
>> XXX-libwfb... If you have done things in exactly this order, so you know the
>> backed up xorg lib is the right one, you can simply change the symbolic link
>> which is libwfb.so to the backed up (XXX-etc.) xorg lib. However, if you
>> have any doubts about the backed up lib being the right one do this:
>> a. force reinstallation of xorg-server, and
>> b. replace libglx.so in /usr/local/xorg/modules with a symbolic
>> link to libglx.so.1 (which is nvidia verson of this lib).
b. should read: replace libglx.so in /usr/local/xorg/modules/extensions with
a symbolic link to libglx.so.1 (which is the nvidia version of this lib).
note: if you do not have to do a., you don't need to do b.
>> 6. Add the line
>> option "AllowEmptyInput" "off"
>> to the server layout section of /etc/X11/xorg.conf. The whole section
>> should then look something like:
>> Section "ServerLayout"
>> Identifier "Layout0"
>> Screen 0 "Screen0" 0 0
>> InputDevice "Keyboard0" "CoreKeyboard"
>> InputDevice "Mouse0" "CorePointer"
>> option "AllowEmptyInput" "off"
>> Some reports suggest that this really belongs in a ServerFlags section,
>> but this seems to work.
>> 7. Verify that
>> is effective in /etc/rd.conf. Remember that rd.conf cascades on itself and
>> the default rd.conf, so that the *last* option entered wins. You can use
>> the configure option of /usr/sbin/sysinstall to be sure that moused works
>> and that a winning entry is in /etc/rd.conf, but just checking and editing
>> manually will also work.
> Good guide. Just a little note :
> "rd.conf" must be "rc.conf".
>> 8. reboot.
>> Reports are that you cannot load the new nvidia kernel module manually
>> with kldload (although this may have worked in the past).
>> 9. If the keyboard in X still does not work, you may have to force
>> reinstallation of xf86-input-keyboard. This worked for me after I had done
>> everything else and the mouse was working.
>> Lars Eighner
>> 8800 N IH35 APT 1191 AUSTIN TX 78753-5266
>> freebsd-ports at freebsd.org mailing list
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
8800 N IH35 APT 1191 AUSTIN TX 78753-5266
More information about the freebsd-ports