Section index, approximately in order of appearance in the main table:
To use all the accelerated graphic features of the ATI Mobility Radeon X1400 graphics chip, you need to obtain ATI's proprietary fglrx driver.
Download it from www.ati.com. Use Firefox; this site is so kewl that it gives Opera-9.20 indigestion. Follow the link in the top nav bar to Drivers & Software. In the table of listboxes select (in order) Linux x86 (or x86_64 if that's what you installed); Mobility Radeon; X1400; Go.
As this is written, the current version is 8.36.5 dated 2007-04-18.
Hit the ATI Driver Installer
link to download the file, named
something.run. I renamed it to ati-driver.run.
Installation has to be done as root. For the first attempt I did these steps:
Unfortunately the package build failed and I couldn't find the log file for why. I'm suspicious about the AMD64 architecture, but the 64-bit instructions aren't shut off; there just aren't any system libraries that use them (on a i586 installation), and this driver should not be bothered by that../ati-driver.run --check ./ati-driver.run --listpkg ./ati-driver.run --buildpkg SuSE/SUSE102-AMD64
For the second attempt I did ./ati-driver.run --install
. It
pops a GUI with a cute penguin logo. I tried to choose Generate Distro
Specific Driver Package
, which would have given me a RPM, but all the
package choices were grayed out.
Third try's a charm. I did ./ati-driver.run --install
again,
but chose Install Driver
. It built the driver, but there was one
error message, unable to find atiogl_a_dri.so . . .
Nonetheless it did install the driver, as
/lib/modules/2.6.18.8-0.3-default/kernel/drivers/char/drm/fglrx.ko
Updates directory:I recommend to copy (or move)
this file into a
separate directory. At the top level, i.e. /lib/modules/2.6.18.8-0.3-default,
create a directory (or symlink to a directory) called updates
. Any
drivers in it will supplement or override same-named drivers in the distro.
After the inevitable kernel security patches, move the updates directory into
the new kernel's toplevel directory, or make a new symlink there. fglrx.ko, at
least, will work with the patched kernel.
The fglrx.ko driver depends on ati-agp.ko, but not in a way that modprobe can recognize. I created a file /etc/modprobe.d/ati.J that gets the agp module loaded and unloaded in coordination with both the radeon and fglrx modules. Here it is:
# When radeon is installed, install ati-agp first. install radeon /sbin/modprobe ati-agp ; /sbin/modprobe --ignore-install radeon remove radeon /sbin/modprobe -r --ignore-remove radeon ; /sbin/modprobe -r ati-agp # Ditto for fglrx (ATI FireGL module) install fglrx /sbin/modprobe ati-agp ; /sbin/modprobe --ignore-install fglrx remove fglrx /sbin/modprobe -r --ignore-remove fglrx ; /sbin/modprobe -r ati-agp # intel_agp is not wanted since ati_agp is supposed to be used. install intel-agp /bin/true
Now that the modules are all set, run depmod -a
to update the
module cross-reference files.
I ran aticonfig --initial
. It made a backup of /etc/X11/xorg.conf
but never actually wrote the altered version with the ATI device section.
Instead I copied xorg.conf from the old machine, which has a Radeon M300.
Here is the relevant section; many of the options are obviously defaults
and probably could be omitted.
Section "Device"
Identifier "Device[0]"
BoardName "Radeon Mobility X1400"
VendorName "ATI"
BusID "PCI:1:0:0" # vendor=1002, device=7145
# Driver "radeon" # Generic xorg driver
Driver "fglrx"
Screen 0
Option "backingstore" "true"
Option "AllowGLXWithComposite" "true"
# These options were provided by fglrxconfig
# === disable/enable XAA/DRI ===
Option "no_accel" "no"
Option "no_dri" "no"
# === misc DRI settings ===
Option "mtrr" "off" # Disable DRI MTRR, use driver's own MTRR code
# === Screen Management ===
Option "DesktopSetup" "(null)"
Option "HSync2" "unspecified"
Option "VRefresh2" "unspecified"
Option "ScreenOverlap" "0"
Option "GammaCorrectionI" "0x06419064"
Option "GammaCorrectionII" "0x06419064"
# === OpenGL specific profiles/settings ===
Option "Capabilities" "0x00000000"
Option "CapabilitiesEx" "0x00000000"
# === Video Overlay for the Xv extension ===
Option "VideoOverlay" "on"
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "off"
# === Center Mode (Laptops only) ===
Option "CenterMode" "off"
# === Pseudo Color Visuals (8-bit visuals) ===
Option "PseudoColorVisuals" "off"
# === QBS Management ===
Option "Stereo" "off"
Option "StereoSyncEnable" "1"
# === FSAA Management ===
Option "FSAAEnable" "no"
Option "FSAAScale" "1"
Option "FSAADisableGamma" "no"
Option "FSAACustomizeMSPos" "no"
Option "FSAAMSPosX0" "0.000000"
Option "FSAAMSPosY0" "0.000000"
Option "FSAAMSPosX1" "0.000000"
Option "FSAAMSPosY1" "0.000000"
Option "FSAAMSPosX2" "0.000000"
Option "FSAAMSPosY2" "0.000000"
Option "FSAAMSPosX3" "0.000000"
Option "FSAAMSPosY3" "0.000000"
Option "FSAAMSPosX4" "0.000000"
Option "FSAAMSPosY4" "0.000000"
Option "FSAAMSPosX5" "0.000000"
Option "FSAAMSPosY5" "0.000000"
# === Misc Options ===
Option "UseFastTLS" "0"
Option "BlockSignalsOnLock" "on"
Option "UseInternalAGPGART" "yes"
Option "ForceGenericCPU" "no"
EndSection
The recommended modeline for this screen (at 122 MHz) is:
You specify the modes in the Monitor section; here's the whole thing:Section "Modes" Identifier "Modes[0]" Modeline "1680x1050" 122.0 1680 1712 1776 1904 1050 1051 1054 1066 EndSection
# The monitor's ID string is bogus, so I faked it. Section "Monitor" Option "CalcAlgorithm" "CheckDesktopGeometry" DisplaySize 333 208 #The following is a lie to produce a resolution of exactly 100 dpi. # DisplaySize 427 267 HorizSync 32-75 Identifier "Monitor[0]" # Mfgr Q@L, Model 57, Serno 0 ModelName "1600X LAPTOP DISPLAY PANEL" VendorName "DELL" VertRefresh 40-78 UseModes "Modes[0]" Option "DPMS" EndSection
Gotcha! The fonts have moved from /usr/X11R6/lib/X11/fonts to /usr/share/fonts, and the X-server will not start if it has no fonts, so if you're copying your old xorg.conf you need to adjust the font path.
While you're at it, make sure that your scalable fonts have the needed fonts.dir and fonts.scale files. These should be generated automatically but for me they were missing. (Insert instructions here.)
Module intel_agp.ko will have been loaded based on the PCI ID of the builtin Intel accelerated graphics chip, and it can't be unloaded. You need to reboot to get ati_agp.ko. But you can do basic tests with intel_agp, like checking that the X-server will start.
With all of these steps finished, the X-server will start and will
do accelerated (3D) graphics using the proprietary driver. You can do a
before and after
test with glxgears, but I've preserved the old
MESA demos from SuSE 8.2, and I find that fire
still works and gives
the graphics chip a much more demanding workout. There's a new fire
in the latest MESA package; see /etc/xscreensaver/glforestfire.xml.
Here is a stanza for xorg.conf that treats the touchpad as a generic mouse.
# DEBUG to get the touchpad sort of working... Take all defaults. Section "InputDevice" Driver "synaptics" Identifier "Mouse[3]" Option "InputFashion" "Mouse" Option "Name" "SynPS/2 Synaptics TouchPad" Option "Vendor" "Synaptics" EndSection
The following excerpt is from Samsung's spec page on their website.
| Capacity | 80 Gb |
| Buffer | 8 Mb |
| Interface | SATA II (up to 1.5 Gb/sec) |
| Seek times: | min. 2 msec, average 12 msec, max 22 msec |
| Latency | 5.6 msec (average) |
| Rotation | 5400 rpm |
| Non-recoverable read errors | 1 sector in 1e14 bits (2.5e10 sectors) |
| Start-stop | 6e5 cycles |
| Temperature | 5 .. 55 deg C (operating) |
| Power | 0.2 W (sleep), 0.6 W (idle), 2.0 W (read/write) |
| Mass | 99 grams |
Features include:
The start-stop spec of 6e5 cycles can't be achieved by drives that let the heads land on the platters; this must be a modern ramp-loading system, although Samsung doesn't say so in cold print. If you started and stopped the drive every 10 minutes, then 6e5 cycles would happen after 100,000 hours or 11 years. This lifetime is very hard to measure and likely the given spec is a lower bound.
Here are the disc partitions that I used:
| Device | Format | Size Gbytes | In Use Gbytes | Description | |
|---|---|---|---|---|---|
| Old machine | |||||
| /dev/sda1 | vfat | 0.058 | Dell Diagnostics | ||
| /dev/sda2 | ntfs | 5.7 | 5.4 | Windows XP | |
| /dev/sda3 | ext3 | 7.5 | 4.9 | Root | |
| /dev/sda4 | Extended Partitions | ||||
| /dev/sda5 | swap | 1.0 | Swap | ||
| /dev/sda6 | ext3 | 26 | 9.4 | Home | |
| New machine as delivered, with Windows | |||||
| /dev/sda1 | vfat | 0.055 | Dell Diagnostics | ||
| /dev/sda2 | ntfs | 69.4 | 4.9 | Windows XP | |
| /dev/sda3 | Extended Partitions | ||||
| /dev/sda5 | CP/M | 3.0 | Dell Restore | ||
| /dev/sda6 | unknown | 1.9 | Dell Media Direct | ||
| New machine, Linux partitions | |||||
| /dev/sda1 | vfat | 0.055 | Dell Diagnostics | ||
| /dev/sda2 | ext3 | 15.5 | 12.2 | Special Projects | |
| /dev/sda3 | ext3 | 15.5 | 4.6 | Root | |
| /dev/sda4 | Extended Partitions | ||||
| /dev/sda6 | swap | 2.0 | Swap | ||
| /dev/sda5 | ext3 | 42.4 | 10.2 | Home | |
I compared the speed of the internal hard disc with an IBM-Hitachi
Deathstar
180Gb desktop drive in a Prolific Technology external
enclosure, which has both Firewire and USB-2.0 ports. Times given are elapsed.
The CPU time was less than 0.1 of elapsed, that is, I/O was the limiting
factor. In all cases 4.7 Gb of data (4.85e9 bytes) was handled; mbuf caching
was irrelevant since the data size exceeded memory size by almost 5x. But
unknown factors caused as much as ±12% variation on repeated
measurements. The Deathstar clearly is at least twice as fast as the laptop
drive. Since the original data was recently copied onto the /home partition by
a similar pair of tar commands, the pattern of seeking must have been nearly
identical on both drives.
| Command | Time seconds | Speed byte/sec | Speed bit/sec | Description | |
|---|---|---|---|---|---|
| Internal disc | |||||
| tar cfC /dev/null / home | 27.4 | Read directories only? | |||
| tar cfC - / home | sum | 430.4 | 1.13e7 | 9.02e7 | Read all | |
| tar cfC - / home | sum | 570.2 | 8.51e6 | 6.81e7 | Same after reboot | |
| Firewire | |||||
| tar cfC - / home | tar xpfC - /mnt | 551.5 | Copy to drive | |||
| tar cfC - /mnt home | sum | 228.3 | 2.13e7 | 1.70e8 | Read all | |
| USB-2.0 | |||||
| tar cfC - / home | tar xpfC - /mnt | 471.8 | Copy to drive | |||
| tar cfC - /mnt home | sum | 277.9 | 1.75e7 | 1.40e8 | Read all | |
The hotplug system successfully mounted the external drive, giving permission to the logged-in user, both when it had an ext2 filesystem and NTFS (readonly), and communicating with both Firewire and USB-2.0.
To get Bluetooth working required quite a bit of digging in forums. Here are my notes. Starting point: the Dell 355 card is based on the Broadcom BCM2045 chipset.
Hype probably from Broadcom reprinted in this industry rag. The BCM2045 is the next generation in their "Blutonium" line. It has more integration and lower external component count. It includes a scheme to (partially?) avoid transmitting at the same time/frequency as 802.11 competitors using the spectrum. Supports Bluetooth 1.2 with EDR (in 2004; I think this ended up as version 2.0).
This patch in drivers/bluetooth/hci_usb.c (dated 2007-04-11) adds the HCI_WRONG_SCO_MTU flag to 0a5c:2101 Broadcom BCM2045. Interesting if you're using a HSP/HFP headset for voice phone calls, but that isn't my issue.
This Ubuntu bug has a
link to a forum
thread which allegedly fixes the problem. You need to do hciconfig hci0
reset
after boot, or after resuming from RAM or disc. (Note, USB is
unloaded on suspend and reloaded on resume, so it will happen.) Some people
report that it doesn't help, others are good. (Suspicion that non-help people
aren't doing pairing right; their timeout or I/O error is gone.) Kernel patch
added (for Ubuntu Feisty, kernel 2.6.20) to do the reset when the device is
initially probed. [This was the last reference on the 4th page of a Google
search.]
To cure this problem I hacked /etc/init.d/bluetooth to do the reset (and to be more modular and to run a2dpd). It needs to have that name since (in SuSE) /lib/udev/bluetooth.sh execs it upon coldplug (boot time) or if a non-built-in dongle is hotplugged. My script wants parameters in /etc/sysconfig/bluetooth.J, which is where configuration parameters are normally stored in SuSE.
The Bluetooth device contacts the laptop, but communication is not
established. Why? Syslogs and hcidump
revealed that the device
was requesting a passkey. The prior version would either use the default
code (typically 0000) configured in /etc/bluetooth/hcid.conf, or would
exec bluepincat
which would take it from /etc/bluetooth/pin.
This scheme clearly gives less than optimum security. In the version on SuSE 10.2, bluez-utils-3.7, hcid has been improved to always use dbus to request a passkey. The bluetooth control GUI of one's Desktop Environment should be listening for the dbus message, assuming that one has a Desktop Environment and that it includes such a GUI and that the GUI is up to date on the messaging. None of which are true for me.
Here's the procedure that worked for me:
hcitool dev -- Checks that your Bluetooth protocol stack
is running and that the dongle is working. It should show the interface
ID, typically hci0, and its MAC address, which you may or may not need
later.
Put the device in pairing mode; consult the device's manual for how to do this.
hcitool scan -- It should report the MAC address and
the description of the device that is trying to pair. Sometimes it detects
irrelevant devices such as neighbors' cellphones; ignore those.
passkey-agent 0000 11:22:33:44:55:66 & -- Make the
passkey available to hcitool over the system dbus. Run the agent in the
background so you can do the subsequent step. Fill in the MAC address of
the device you are pairing with, and the passkey, which you get from
these sources:
hcitool cc 11:22:33:44:55:66 (as root) -- cc
means create connection
; fill in the MAC address of the partner you
are creating the connection with. In this step the client and master
create an encrypted connection, and then the client sends the passkey to
prove its identity.
Now your device is paired. My wireless headphone automatically makes a connection, or some devices may have to be power cycled to get them to connect.
For me the modem is only a fallback if I'm stuck in a hotel with no broadband, so I normally keep the driver unloaded, and I haven't put a lot of effort into setting it up on the new machine, but I did do a little investigation.
I used this
modem detector to get support recommendations. It is a softmodem
,
meaning that the driver, executing on the main CPU, creates or interprets the
sound stream which represents the bits being transferred. The modem should be
controlled by the
Linuxant hsfmodem driver. It can be downloaded for free, but it will only
go up to 14.4 kbaud until you purchase a license key, at which point it will do
56 Kbaud with FAX.
Dell has recently started offering Linux (Ubuntu) on their machines, including decent support, including the Linuxant modem, not requiring a license key for full feature operation including FAX. This forum posting has a URL for getting the driver. It is a Debian package (since Ubuntu is based on Debian), and SuSE users will need to do some fiddling to get it onto the machine -- which I haven't actually done yet.
Here is the xorg.conf section for the external mouse. You may need to adjust the protocol and buttons if you have a different kind of mouse.
You will also need to add these lines in the respective sections (only the one added line is shown):# External USB or PS/2 mouse, or wireless Karaoke controller used as mouse. Section "InputDevice" Identifier "Mouse[2]" Driver "mouse" Option "Buttons" "7" Option "Device" "/dev/input/mice" Option "InputFashion" "Mouse" Option "Name" "USB-Mouse;ExplorerPS/2 on USB" Option "Protocol" "ExplorerPS/2" Option "ZAxisMapping" "4 5" EndSection
Section "ServerFlags" Option "AllowMouseOpenFail" Section "ServerLayout" InputDevice "Mouse[2]" "SendCoreEvents"
I borrowed a Kill-a-Watt
power meter from a co-worker. You plug it
into the wall outlet and plug the equipment into it, and it continuously
displays the power being drawn. Here are my measurements; all powers in watts:
| Activity | Laptop | Desktop |
|---|---|---|
| Power off | 0 | 2 |
| Off, charging battery | 43 | -- |
| Doing nothing | 32 | 76 |
| 100% of 1 CPU | 45 | 95 |
| 100% of both CPUs | 54 | 107 |
| Graphics test | 48 | 98 |
| Monitor | 11 est'd | 42 |
The desktop machine is a Dell Dimension E520, Intel Core 2 Duo T6300 at 1.86 GHz (very similar to what's on the laptop). Its monitor is a Dell 2007WFP flat panel, and the power for the monitor is not included in the CPU measurements. For the laptop, of course the monitor power was included. In all cases the screen was set to full brightness. Its power was estimated by subtracting from the idle power (32 watts) the power with the lamp off in screensaver mode (25 watts).
Since the old machine is still working (except for screen problems), a special backup is not needed. Rely on the regular backup.
Check and record identity and serial numbers of all parts.
Boot it up in Windows. Configure UTC timezone. Find out MAC addresses.
Server configuration: add new machine's wired and wireless MAC addresses to firewall's MAC filter, and configure the DHCP fixed address.
Do the subsystem checkout on Windows.
Review BIOS Setup options. (I changed the boot sequence, left the rest as-is.) Setup says it can boot from any of floppy, internal hard disc, CD, USB storage, or (wired) NIC.
Run Dell Diagnostics on everything. Done; passed.
Run Linux memory tester overnight (memtest86) off the CD. No errors. About 15 mins. per complete pass.
Test if the SuSE rescue system and installer will boot. Yes, they do.
Write down the existing partitioning and plan Linux partitions.
Install OpenSuSE Linux v10.2, kicking Windows off the machine.
The SuSE installer knows
that an Intel Core 2 Duo CPU can address
over 4 Gb of memory (64 Gb, I believe), and therefore needs the x86_64
architecture. But this machine has only 1 Gb memory. While some specialized
software may or may not get a speed boost from the 64 bit instructions, my own
testing on scientific computation (matrices) shows that, comparing a complete
x86_64 vs. i586 installation on the same dual-processor Xeon machine, and with
the test software compiled and optimized natively on each one, x86_64 is about
1% slower than i586, probably because 64 bit addresses have to be stacked and
restored to registers, versus 32 bits on i586. Thus it's my policy to install
the i586 architecture unless the machine has over 4 GB of memory.
The SuSE 10.2 installer lets you choose the architecture: hit the F6 key on the initial screen. The gray background indicates which of the two choices you are going with. SuSE 10.1 did not do this. To force it to install i586 the trick was to boot from the CD, which only has i586, rather than from the DVD which has both.
You will also want to use the F3 key to choose a bigger screen than the default 800x600px. The closest choice is 1400x1050px, although you really want the native resolution of 1680x1050px.
For me, the installation took about 30 minutes. Key installation choices:
Set the timezone to PST-PDT with UTC in the clock.
For the basic selection I pick the graphical system without KDE or Gnome (although this probably is not the most common choice). I have my own package manager, so my best strategy is to pick the shortest generic list and to add wanted packages later. However, it's a good idea to manually add the x11-xorg-driver-video package so it can try the xorg radeon driver.
See the partition section for my pre-planned partition layout.
In the second phase after the reboot, it will want to sync with the ZENworks server, which of course I don't have. In SuSE 10.2 there's an abort button so you don't have to wait through the 30 second timeout.
assign the machine's fixed IP address.
Decline the network test
, which includes an online update
from SuSE's overloaded servers. When SuSE's installer finishes, get
all your wanted packages installed, and all the unwanted packages off
the machine, and then do the online update.
The last step is to copy the home directories from the old machine using wired Ethernet.
Check if, with xorg-x11-drivers-video package installed, sax2 can change the video device away from the stupid framebuffer.
Check if the xorg Radeon driver works and how much DRI it supports, if any.
fglrx: Figure out how to set power management mode 2. This slows down the chip to a max of 135 MHz dot clock, reduces the supply voltage, enables sleep mode, and uses the thermal diode to detect cooling failures. Definitely this would save some power in battery operation.
Compose key is ineffective in X-windows (and console?) This used to work. Also I want UTF-8 extended characters, not ISO-8859-1.
Can I determine the actual speed of my memory, 667MHz or 533MHz?
Playing entertainment DVD: need to install libdvdcss and a decent player.
Wireless (Intel 3945ABG): Separate invocation of ipw3945d policy daemon is a gross kludge. There has to be a sanitary way to make this happen.
PCMCIA: Need to test this on Linux. [Can't, wrong format.]
Get the Linuxant modem driver from Dell and install it.
Battery: Need to do a standard battery life test.
Custom boot logo from SuSE 10.1 doesn't work on SuSE 10.2.