[SOLVED] CLFS X11 starts with fbdev but cant use any other driver

Keith Hedger · 06-22-2012, 10:27 AM

Right here's my problem I have build CLFS on an AMD64, all goes fine boots up etc, installed Xorg7 via the book, did a minimal install from this:
http://lists.x.org/archives/xorg-mod...er/000801.html
+some dependencies that were missing.
This is what was installed:

Code:

ed-1.4-1
freetype-2.4.4-1
expat-2.0.1-1
fontconfig-2.8.0-1
which-2.20-1
pciutils-3.1.7-1
xtrans-1.2.6-1
xproto-7.0.19-1
libXau-1.0.6-1
libXdmcp-1.1.0-1
libpthread-stubs-0.1-1
xextproto-7.1.2-1
xcb-proto-1.6-1
libxml2-2.7.8-1
libxml2-2.7.8-1
libxslt-1.1.26-1
libxcb-1.7-1
gperf-3.0.4-1
xcb-util-0.3.6-1
kbproto-1.0.5-1
inputproto-2.0.1-1
libX11-1.4.0-1
libXext-1.2.0-1
fontsproto-2.1.1-1
libFS-1.0.3-1
libICE-1.0.7-1
libSM-1.2.0-1
libXt-1.0.9-1
libXmu-1.1.0-1

libXpm-3.5.9-1
renderproto-0.11-1
libXrender-0.9.6-1
libfontenc-1.1.0-1
libXfont-1.4.3-1
fontcacheproto-0.1.3-1
libXfontcache-1.0.5-1
libXft-2.2.0-1
libXi-1.4.0-1
xineramaproto-1.2-1
libXinerama-1.1.1-1
randrproto-1.3.2-1
libXrandr-1.3.1-1
videoproto-2.3.1-1
libXv-1.0.6-1

liblbxutil-1.1.0-1
libxkbfile-1.0.7-1
compositeproto-0.4.2-1
fixesproto-4.1.2-1
libXfixes-4.0.5-1
libXcomposite-0.4.3-1
libXcursor-1.1.11-1

iceauth-1.0.4-1
rgb-1.0.4-1
sessreg-1.0.6-1
setxkbmap-1.2.0-1
smproxy-1.0.4-1
xauth-1.0.5-1
recordproto-1.14-1
libXtst-1.2.0-1
xdpyinfo-1.2.0-1

xev-1.1.0-1
xhost-1.0.4-1
xinit-1.3.0-1
xkbcomp-1.2.0-1
xkill-1.0.3-1
xlsatoms-1.1.0-1
xlsclients-1.1.1-1

xlsfonts-1.0.3-1
xmodmap-1.0.5-1
xprop-1.2.0-1

xrandr-1.3.4-1
xrdb-1.0.7-1
util-macros-1.11.0-1
xrefresh-1.0.4-1
xset-1.2.1-1

xsetmode-1.0.0-1
xsetpointer-1.0.1-1
libXaw-1.0.8-1
xsm-1.0.2-1
xvinfo-1.1.1-1
xwininfo-1.0.4-1

pixman-0.21.2-1
glproto-1.4.12-1

talloc-2.0.5-1
libdrm-2.4.22-1
dri2proto-2.3-1
damageproto-1.2.1-1
libXdamage-1.1.3-1

Mesa-7.9-1
xcmiscproto-1.2.1-1
bigreqsproto-1.1.1-1
scrnsaverproto-1.2.1-1
resourceproto-1.1.0-1

libpciaccess-0.12.0-1


xf86-video-vesa-2.3.0-1
xf86-video-fbdev-0.4.2-1
xf86-input-keyboard-1.5.0-1
xf86-input-evdev-2.5.99.901-1

mkfontscale-1.0.8-1
encodings-1.0.4-1
font-util-1.2.0-1
mkfontdir-1.0.6-1
bdftopcf-1.0.3-1
font-misc-misc-1.1.1-1
font-cursor-misc-1.0.3-1
xcursorgen-1.0.4-1
xcursor-themes-1.0.3-1
XML-Parser-2.40-1
intltool-0.40.6-1
xkeyboard-config-1.4-1
xterm-267-1

xf86-video-nv-2.1.18-1

xorg-server-1.9.2.901-1

No compile/install problems

Used Xorg to create a default xorg.conf file
Driver set to fbdev and X started with this comand

Code:

X -retro -config ~/xorg.conf.new

and X11 starts with a grey sgreen and an X cursor.
If I try any other driver ( nv,vesa,nvidia ) just get a black screen and hang and have to do ALT-SYSREG-B to reboot
I no the proper nvidia works on my mahine as I use it in slackware but although it installs in LFS I get the same black screen
Default xorg.conf:

Code:

Section "ServerLayout"
	Identifier     "X.org Configured"
	Screen      0  "Screen0" 0 0
	InputDevice    "Mouse0" "CorePointer"
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
	ModulePath   "/usr/lib64/xorg/modules"
	FontPath     "/usr/share/fonts/X11/misc/"
	FontPath     "/usr/share/fonts/X11/TTF/"
	FontPath     "/usr/share/fonts/X11/OTF/"
	FontPath     "/usr/share/fonts/X11/Type1/"
	FontPath     "/usr/share/fonts/X11/100dpi/"
	FontPath     "/usr/share/fonts/X11/75dpi/"
EndSection

Section "Module"
	Load  "extmod"
	Load  "record"
	Load  "dbe"
	Load  "glx"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
EndSection

Section "InputDevice"
	Identifier  "Mouse0"
	Driver      "mouse"
	Option	    "Protocol" "auto"
	Option	    "Device" "/dev/input/mice"
	Option	    "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
	#DisplaySize	  410   260	# mm
	Identifier   "Monitor0"
	VendorName   "GSM"
	ModelName    ""
#	HorizSync    30.0 - 83.0
#	VertRefresh  56.0 - 75.0
    HorizSync       28.0 - 33.0
    VertRefresh     43.0 - 72.0

	Option	    "DPMS"
EndSection

Section "Device"
        ### Available Driver options are:-
        ### Values: <i>: integer, <f>: float, <bool>: "True"/"False",
        ### <string>: "String", <freq>: "<f> Hz/kHz/MHz",
        ### <percent>: "<f>%"
        ### [arg]: arg optional
        #Option     "SWcursor"           	# [<bool>]
        #Option     "HWcursor"           	# [<bool>]
        #Option     "NoAccel"            	# [<bool>]
        #Option     "ShadowFB"           	# [<bool>]
        #Option     "UseFBDev"           	# [<bool>]
        #Option     "Rotate"             	# [<str>]
        #Option     "VideoKey"           	# <i>
        #Option     "FlatPanel"          	# [<bool>]
        #Option     "FPDither"           	# [<bool>]
        #Option     "CrtcNumber"         	# <i>
        #Option     "FPScale"            	# [<bool>]
        #Option     "FPTweak"            	# <i>
        #Option     "DualHead"           	# [<bool>]
	Identifier  "Card0"
	Driver      "nv"
	BusID       "PCI:0:5:0"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Card0"
	Monitor    "Monitor0"
	SubSection "Display"
		Viewport   0 0
		Depth     1
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     4
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     8
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     15
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     16
	EndSubSection
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

I've attached the working and not working logs.

I'm stumped I've googled my @$$ off and gone over the xorg chapter in the book at least four times I've tried reinstallaing the server and copying xorg.conf files that I know work with my system, I've tried using my kernel from slackware to boot LFS to see if it was a kernel problem but always the same problem fbdev works nothing else seems to.

HELP!!

business_kid · 06-23-2012, 06:40 AM

Try ls /usr/lib(64)/libGL* and see where the symlinks are pointed. Things like libGL.so should point at libGL.so.1.2(?) if it's using Mesa libs(for nv), but point at libGL.so.<nvidia version> if it's a proprietary driver is there. That's a show stopper Post

glxinfo |grep render

Keith Hedger · 06-23-2012, 07:20 AM

Thanks for the tips, to start

Code:

root@SlackHolly:/-> ls /usr/lib64/libGL*
/usr/lib64/libGL.la    /usr/lib64/libGL.so.295.59  /usr/lib64/libGLU.so.1.3.070900  /usr/lib64/libGLw.so.1.0.0
/usr/lib64/libGL.so    /usr/lib64/libGLU.so        /usr/lib64/libGLw.so
/usr/lib64/libGL.so.1  /usr/lib64/libGLU.so.1      /usr/lib64/libGLw.so.1

glxinfo is not installed.

I may have found the reason late last night, I decided to install all the library's and protos from the Xorg7 section of the books and rebuild mesa and I noticed that the 'dri' folder installed by mesa was in /usr/lib64 and NOT in /usr/lib64/xorg/modules which is where the configure command in the xorg-server section looks so I symlinked and reinstalled xorg-server and the nvidia driver and presto! a working X, I don't see anything in the mesalib configure section to tell it where to install the 'dri' folder, have I missed something?

I now just want to go back and remove the extra libs and see if that was part of the problem I will post back.

business_kid · 06-24-2012, 04:38 AM

Sorry. My bad. Minding a patient here at the same time

ls -l /usr/lib(64)/libGL*

lets you see where the symlinks point.I forgot the '-l'.

Just looking
libGL.so.295.59 libGLU.so.1.3.070900

if both of them are in use, it's a problem. Here's my output, with no proprietary blob in sight, using Mesa & oss. What are you using?
.

Quote:

bash-4.1$ ls -l /usr/lib64/libGL*
lrwxrwxrwx 1 root root 10 Dec 29 16:21 /usr/lib64/libGL.so -> libGL.so.1
lrwxrwxrwx 1 root root 12 Dec 29 16:21 /usr/lib64/libGL.so.1 -> libGL.so.1.2
-rwxr-xr-x 1 root root 527296 Apr 8 2011 /usr/lib64/libGL.so.1.2
-rw-r--r-- 1 root root 657308 Nov 4 2010 /usr/lib64/libGLEW.a
lrwxrwxrwx 1 root root 16 Dec 27 13:04 /usr/lib64/libGLEW.so -> libGLEW.so.1.5.7
lrwxrwxrwx 1 root root 16 Dec 27 13:04 /usr/lib64/libGLEW.so.1.5 -> libGLEW.so.1.5.7
-rw-r--r-- 1 root root 389992 Nov 4 2010 /usr/lib64/libGLEW.so.1.5.7
lrwxrwxrwx 1 root root 11 Dec 29 16:21 /usr/lib64/libGLU.so -> libGLU.so.1
lrwxrwxrwx 1 root root 20 Dec 29 16:21 /usr/lib64/libGLU.so.1 -> libGLU.so.1.3.071000
-rwxr-xr-x 1 root root 453232 Apr 8 2011 /usr/lib64/libGLU.so.1.3.071000
lrwxrwxrwx 1 root root 11 Dec 29 16:21 /usr/lib64/libGLw.so -> libGLw.so.1
lrwxrwxrwx 1 root root 15 Dec 29 16:21 /usr/lib64/libGLw.so.1 -> libGLw.so.1.0.0
-rwxr-xr-x 1 root root 16712 Apr 8 2011 /usr/lib64/libGLw.so.1.0.0

Keith Hedger · 06-24-2012, 06:50 AM

Quote:

Originally Posted by business_kid

Sorry. My bad. Minding a patient here at the same time

ls -l /usr/lib(64)/libGL*

lets you see where the symlinks point.I forgot the '-l'.

Just looking
libGL.so.295.59 libGLU.so.1.3.070900

if both of them are in use, it's a problem. Here's my output, with no proprietary blob in sight, using Mesa & oss. What are you using?
.

Accidentally hosed my LFS install so I am rebuilding now when I get back to the point where mesa is installed I'll let you know, ho hum.

stoat · 06-24-2012, 07:38 AM

Quote:

Originally Posted by Keith Hedger

Accidentally hosed my LFS install so I am rebuilding now...

Consider creating a tarball backup of your LFS partition after every big section, or before starting a new big section. At the point where you are, it takes about a minute to create or restore from a tarball.

Keith Hedger · 06-24-2012, 08:19 AM

Quote:

Originally Posted by stoat

Consider creating a tarball backup of your LFS partition after every big section, or before starting a new big section. At the point where you are, it takes about a minute to create or restore from a tarball.

Yeah already done that just rebuilding the xorg bit.

Keith Hedger · 06-26-2012, 02:46 PM

Well I've finally sorted the problem after having re-installed xorg a couple of times and finally done a complete rebuild from scratch ( mostly scripted and package managed so not a real problem to just let it run ).

I decided to go with a full library/proto install as they don't take much room and will probably save me grief in the future.

It is definitely a problem with the configure options for mesalib and xorg-server given here: http://cblfs.cross-lfs.org/index.php/Xorg7/MesaLib and here: http://cblfs.cross-lfs.org/index.php/Xorg7/Xserver

The configure for xorgserver has this option --with-dri-driver-path="${XORG_PREFIX}/lib/xorg/modules/dri" which is fine but the corresponding option is not given for mesalib which should be --with-dri-driverdir=/usr/lib${LIBDIRSUFFIX}/xorg/modules/dri --enable-xcb ( xcb is not enabled by default ), where LIBDIRSUFFIX=64 for x86_64 or "" for 32Bit, this puts the dri folder into xorg/modules linstead of /usr/lib.

Also to install the proprietary nvidia driver ( I know I know it's not open source ), you need to use the eglibc-2.15-r16526-dl_dep_fix-1.patch when building the final eglib.

Thanks for the suggestions and I hope this may help someone else.

On to gtk and Xcfe - Oh Joy!

business_kid · 06-27-2012, 04:21 AM

Post the corrections to the appropriate LFS list so they can fix the book.

Keith Hedger · 06-27-2012, 05:38 AM

Quote:

Originally Posted by business_kid

Post the corrections to the appropriate LFS list so they can fix the book.

I don't want to sign up for yet another mailing list for such a small ( but annoying! ) bug, so if anyone else reading this is already signed up please pass it on. Thanks.