# Does X11 work better with i386 than amd64?



## robspop (Nov 2, 2011)

I am experimenting with FreeBSD at the moment and have three installations that I am trying things out with.

My first was on a laptop (Thinkpad X61) using 9.0 Beta 3 i386. Basically, all went well, no problems other than those arising from my own ignorance. I have both KDE and XFCE running, which they both did "out of the box" simply by following the instructions in the handbook.

My second installation was on a desktop PC. This time I used the newly available 9.0 RC1, amd64 version. I laid out the disk partitions (GPT) rather than just accepting the installer default, but otherwise exactly followed the standard installation steps as before. When I got to starting X, this time it did not work: the hald and dbus entries in rc.conf did not lead to either mouse or keyboard working. I created an xorg.conf file and used that to disable autodetect and then they did work, but that was not the end of the problem. KDE exhibits all kinds of strange behaviour. For example, kdm does not work because it looks for X in /usr/bin instead of /usr/local/bin. More oddly, Konsole occasionally works but mostly disappears again. I can only have one workspace because the pager will not remain on the toolbar: it disappears the instant it is added.

I posted a query about this in this forum. It got moved from Xorg to KDE and I have had no response. However, I think the problem is at a more fundamental level. XFCE on this system will not run at all, and that cannot be a KDE problem.

Finally, I have now tried installing 9.0 RC1 amd 64 on the Thinkpad, and I have found exactly the same issues as with the desktop: the mouse and keyboard do not work without the xorg.conf file (and even with it only an external USB mouse will work, not the built-in pointer). I also cannot have multiple workspaces or a pager. 

The only difference, in the case of the Thinkpad, is the use of the amd64 version, so perhaps it would be safer to just stick to i386? The PC does have an AMD64 CPU and I have read of people successfully using the amd64 version of FreeBSD (earlier release) on a Thinkpad X61.


----------



## wblock@ (Nov 3, 2011)

xorg should operate identically on i386 or amd64.  Too many things mentioned to address them all...  Touchpads might be PS/2 devices that need moused enabled to work.  To avoid problems with hal, best to turn that option off in the xorg-server port.


----------



## robspop (Nov 3, 2011)

I realise there are too many problems listed in my original post, but I included them as examples in case any sparked recognition in a reader. There are in fact further examples of what I would regard as unexpected behaviour.

A propos the mouse specifically, it DOES work when I use a i386 image and DOES NOT work when I use an amd64 image where almost everything else is identical (it is the same laptop, I am just swapping HDDs).  

I have so many FreeBSDs running because I am looking for a long-term alternative to Solaris, so testing in various different environments. I have been trying Linux for a while but so far I like the feel of FreeBSD much more. One of my Linux experiences was that it all seemed more "flakey" in the 64bit versions. Maybe this is true of FreeBSD also?


----------



## KNOStic (Nov 3, 2011)

Hey guys ... I know this one since it tripped me up as well. The problem with Xorg is that HAL is dying because of a missing library. HAL wants /lib/libcam.so.5 but it's been replaced by /lib/libcam.so.6 in the distribution and thus ".5" no longer exists. Breaks HAL in 64. All you need to do is get to the /lib directory using a second console (Ctrl+alt+F2 or such), then:
[CMD=""]cd /lib[/CMD]

then either link a new libcam.so.5 to the existing libcam.so.6 ... or take the cheap way out like I did for now and just:
[CMD=""]cp libcam.so.6 libcam.so.5[/CMD]

... since making a mess in this build won't be permanent and I'm sure a future build will link HAL to the correct library down the road. Been there, done that, this is why on the 64. BSD is remarkably stable normally between 32's and 64's ... this is just one of a few temporary aberrations as things get built for the final.

Reflect, repent, reboot and all should be well.


----------



## kpa (Nov 3, 2011)

Please don't do that. The right procedure is to delete old programs and libraries with `# make delete-old` and `# make delete-old-libs` after doing `# make installworld` in single user mode and then rebuild ports that depend on libcam.so.*. This issue has nothing to do with i386 vs. amd64, you would have seen the same problem on i386 as well.


----------



## KNOStic (Nov 3, 2011)

kpa said:
			
		

> Please don't do that. The right procedure is to delete old programs and libraries with `# make delete-old` and `# make delete-old-libs` after doing `# make installworld` in single user mode and then rebuild ports that depend on libcam.so.*. This issue has nothing to do with i386 vs. amd64, you would have seen the same problem on i386 as well.


Thanks for the proper method. In my case, I installed AMD64-9.0-RC1 from the ISO and grabbed all packages using pkg_add -r and that's how they came down. Had no old or new to replace with, so since this was just a trial build for me, that was the fastest way to get to a desktop. I wouldn't do such a thing on an actual production machine, but it got the issue out of the way quickly without having to play with source which of course at this time is always subject to change until they hang the "release" shingle out ...


----------

