Debian on a Dell Latitude D620 - Notes
From GrinningMonkey
Editor's Note
As you read this page you'll note that it is very incoherent and disorganized. It is not well-written yet. I'm still building my laptop and trying various things to get it to work properly. I'm keeping my notes here for the time being. Once I get everything working I plan to install linux again from scratch.
Why a Dell?
I have a Toshiba Satellite A70. It is a couple of years old, and it is quite large and bulky, and it doesn't last terribly long on battery, but it has not been a bad laptop for me.
Until its charging circuity got alzheimer's. Now and then it forgets that the AC adapter is plugged in. Then the laptop runs on battery until it discharges almost completely. Then my low-battery alert goes off. At 02h00. This is annoying. More about this over here, including pictures of all my laptops, at The Laptop Succession Page.
The new laptop
My new laptop criteria were:
- Linux should work with most of the hardware (I don't care about n-in-1 card readers)
- nVidia graphics (nVidia is nice to Linux users)
- Decent size and weight
- Decent power consumption
I spent a few hours checking out the major brands of laptop. Why'd I choose the Dell? See The Laptop Succession Page (I'm trying to keep this page you're reading more dedicated to the Debian install process and less anecdotal, despite my verbose writing style). Use the Table of Contents at the top of the page to skip my writings and get to the part(s) you're REALLY interested in.
Determining linux support
http://www.linux-on-laptops.com is invaluable for this. Many helpful people have put up their experiences, HOWTOs, lspci dumps and other useful data on a metric boatload of laptop models.
I found a few entries at sites like http://www.linux-on-laptops.com/dell.html which indicate that getting Linux onto the D620 ought not to be too horrible. A key decision was to get the Intel Pro wireless option instead of the standard Dell one.
Final choice
The system specs for the machine I got:
* T2600 Dual Core 2.16GHz Centrino CPU, 2MB L2 Cache 667MHz FSB * 2.0GB, DDR2-667 SDRAM, 2 DIMMS * 100GB Hard Drive, 9.5MM, 7200RPM SATA * 14.1 inch Wide Screen WXGA+ LCD Panel (the 1440x900 one) * Normal keyboard, non-fingerprint-reader touchpad * 24X CD-RW/DVD w/ Cyberlink PowerDVD * 256MB NVIDIA Quadro NVS 110M * Intel PRO/Wireless 3945 802.11a/g Mini Card * 9-Cell battery and 90W AC adapter
When it arrived I used the BIOS, a Live CD and Windoz to confirm the hardware I ordered and to test things. I was unable to test the smartcard reader since I don't have a smartcard. Same with the IR port. Everything else worked. One oddity:
- The BIOS reports the video card as having 64MB RAM. Windows, however, says 256MB. I forgot to check in Linux. I don't know what's up with that; I can think of a few reasons:
- The BIOS can't 'see' the rest because it's allocated for the video card's direct use (3d rendering and stuff?)
- The system allocates some real RAM to the video. My Toshiba does this, but I didn't find any documentation indicating that the Dell does this (I will dig deeper in Linux once it's installed)
Pre-install: prepping the Windoz partition
Ew! Why Windoz? I wanted to keep the Windoz partition around for a few reasons:
- I paid for the damn thing (the laptop didn't have a No Windoz option)
- Downloading maps to my Garmin GPS needs Windoz. Same with upgrading firmware on my digicam, MP3 players, etc.
- X-Plane, my flight simulator, may run better in Windoz than in Linux
- When the laptop breaks, Dell support techies may have a checklist and/or diags that need Windoz
- When yutzes ask to borrow my 'puter I can give them the Windoz partition to play in so they have something familiar to use and they won't break anything important
Resizing the partition
- Boot a live CD or rescue CD with ntfsresize and fdisk (I used an Ubuntu Live CD)
-
fdisk /dev/sdaand note the current partition info. NB: Dell has its own stuff on the 1st primary partition. It's about 50MB. I think it's the diagnostics -
ntfsresize --info /dev/sda2to note the current NTFS size info (esp. how much is in use! I saw 7 bloody GB and decided that ~20GB for Windoz, ~80GB for the rest oughta be OK) -
ntfsresize --size 19GB /dev/sda2moves the data in the existing partition to the right place but doesn't change the partition itself -
fdisk /dev/sda:- Delete the #2 Windoz partition (nothing gets written to disk until you save and exit)
- Create a new #2 partition with the same start cylinder. NB: Make the new partition size slightly bigger than the NTFS volume size. I chose 19010MB
- While I'm in here I might as well create the partitions for Linux and swap. I chose 2GB for the swap
- At this point you can write the table and be done. I did something extra:
-
bc -land calculate ( (endcyl - startcyl) * unitsize ) confirmed my partition is 19.010GB - I tried the same calculation, reducing endcyl by 1. Surprise! Still bigger than 19GB! I re-set the partition table and saved around 8MB (yeah, not much compared to 100GB but why let it never be used?)
-
Testing in Windoz
- Booted back into Windoz. The startup was interrupted by a disk check. When it finished, Windoz said it found a "new device" and wanted to restart. OK, fine
- When it came back up again, I ran a scandisk (Start → My Computer → Disk Properties → Tools) with a bad sector scan. This confirms that Windoz can read all the way to the end of the disk
- I did a defrag for old-timey's sake
Installing Debian
I used this page from Christophe as a very helpful resource: http://math.umh.ac.be/an/D820/ The D820 has much the same hardware.
Pre-install prep
- Burned myself a debian testing ISO using the "Etch Beta 2" image from http://www.debian.org/devel/debian-installer/. I did not have a blank CD but found an old CD-RW. When I tried to blank and burn the CD-RW, cdrecord said that the Writer's minimum speed of 4 was too much for the CD-RW's maximum speed of 2. However, I --force'd it and it blanked and burned successfully.
CDROM weirdness
- As expected, the installer could not find the SATA CDROM
- Appending libata.atapi_enabled=1 to the kernel params did not help
- I don't have a memory stick, so I tried Christophe's instructions using my digicam as a USB Mass Storage device, but I couldn't get it to work, even following these instructions: http://d-i.alioth.debian.org/manual/en.i386/ch04s04.html
- I came across this page: http://wiki.debian.org/DebianInstaller/SataAtapiHowto which explains how to get the installer to see the CDROM
- (Had that not worked, I would have used PXEbooting with TFTP)
... at this point it was late and I was likely to be eaten by a grue if I don't go to bed.
Display weirdness
I had changed two option in the BIOS:
- Do not expand the screen
- Changed from "Docked" to "On-board" display
One of these caused odd issues such as text falling off the bottom of the screen and a small bar of odd-looking vertical lines at the top. I reverted these settings and that problem went away. I will further experiment with this later.
Networking for net-install
The Debian install continued the next day, starting with setting up my existing laptop (Toshiba) to be a gateway since there are no wireless drivers for the Intel Pro/3945 on the installer CD, and I didn't feel like taking the new laptop to the basement where there's a hub. The Toshiba<->Dell connection is 100Mb/s, the Toshiba<->gateway is 54Mb/s, the gateway<->internet is under 3Mb/s (and probably less for the specific mirror I'll be downloading through).
- Connected the two laptops with a standard Cat5 cable (hooray Dell for putting in autosensing crossover!)
- Brought up Toshiba's eth0 with 192.168.5.1 and enabled dhcpd
- Set up networking on Toshiba with
echo 1 > /proc/sys/net/ipv4/ip_forward; iptables -t nat -A POSTROUTING -o ath0 -j SNAT --to 192.168.1.10
Installing Debian
- Booted the netinstall CDROM, using
install26 BOOT_DEBUG=3and issuingecho options libata atapi_enabled=1 >> /etc/modprobe.confat the prompt followed by twoexits - Everything proceeded normally. I had done partitioning earlier while dealing with Windoz, so I just told it to use the right partition for swap and ext3
- Installed with options Desktop Environment, Laptop, Standard Sytem as I'm too lazy to manually pick every single package that gets installed. I would rather look through what DID get installed and then remove what I don't want. It chose 715 packages, so if that's too wasteful of space I'll go through it again and put less (or no) stuff on there.
Testing
Before recompiling and/or installing any custom stuff, I went through to see what works right out of the box:
- No CDROM
- The SATA CDROM is not detected. As expected, adding libata.atapi_enabled=1 to kernel commandline doesn't work for this kernel. Oddly enough, it didn't work for my new 2.6.16.19 kernel either.
- Only see 1GB of memory
- I have no idea WTF is up with this. grub sees 2GB but this kernel sees only 1GB
- Nipple drift
- The stupid track-point drifts around occasionally. It seems to be related to the driver as it changes behaviour between X sessions: in one session it may continually drift around and even partially stop responding (left and right but no up/down), while in another session it only drifts occasionally and corrects fairly quickly
Tweaking Debian
New kernel
- Debian has a way to make new kernels using kernel_package but I just grabbed the latest, 2.6.16.19 from ftp://ftp.kernel.org
- Copied /boot/config-2.6.15-1-whatever to /usr/src/linux/2.6.16.19/.config and did a
make oldconfigto answer any new questions - Did make menuconfig to go through all the options
- Set Processor Family to Pentium M which is what a Centrino is according to some stuff I found with a grep in Documentation/
- Enabled Symmetric Multi-Processing -- NB: This requires you to turn on Enhanced Real Time Clock Support which you will find hidden in Device Drivers → Character Devices
- Set High Memory Support to 4GB -- This is why I could only see 1GB of memory earlier
- Eventually I had to edit drivers/scsi/libata-core.c to change the bit int atapi_enabled = 0; to a 1. I don't know why this kernel would not accept the libata.atapi_enabled=1 option on the kernel command line. Maybe 'cause I made libata a module?
- Build a new initrd: install mkinitramfstools and do
mkinitramfs 2.6.16.19 -o initrd.img-2.6.16.19 - I built the cpufreq_{ondemand,userspace,etc} bits as modules. I had kernel panics using the conservative governor, but ondemand works great. I had to:
- Edit /etc/modules to add speedstep_centrino and cpufreq_ondemand (this causes the modules to be loaded)
- Install sysfsutils and then edit /etc/sysfs.conf to add devices/system/cpu/cpun/cpufreq/scaling_governor = ondemand for each n of 0,1 (these two lines actually cause the processors to use that governor)
- The monitor's backlight does not turn off at all when the lid is closed. My Toshiba is hard-wired to do that, which is nice for Operating Systems that can't handle ACPI. I had to set up an /etc/acpi/events/lid file which does su norm -c '/usr/bin/xset -display :0.0 dpms force on'. This is pretty hacky; it only works in X and only if I'm the X user. It also doesn't turn the screen back on when the lid is opened (in fact it tries to turn it off again d:). I will try and write a shellscript that (a) figures out who the X user is and (b) sends a 'force on' for lid closures and 'force off' for opens. Perhaps there is also a command to kill the screen in either X or textmode. vbetools perhaps.
... once again it is late at night and I must go to bed before the mogwai come looking for food. Left to do tomorrow:
Sound
I originally got sound working by installing the Conexant HSF modem drivers, which come with snd_hda_intel modules. I then discovered that HSF sucks (14.4k, no FAX, unless you pay) so I trashed it, got alsa-source (apt-get install alsa-source) and then build it from /usr/src/modules. This works fine. Another advantage with this approach is that when recompiling the kernel you don't have to rebuild / reuse the HSF crap.
Wireless
I got wireless working by using the http://ipw3945.sf.net package (used 1.0.12). This says to use ieee80211 v.1.1.11 or greater (used 1.1.14), and the kernel comes with 1.1.7. So downloaded http://ieee80211.sf.net as well. Installed both, wireless worked fine except for two things:
- It won't associate to the AP when I issue a 'restricted' (restricted tells wireless to use only encryption). I opened Bug 1086 for this issue. Without the 'restricted' parameter it works fine.
- The ieee80211 make code, when you go to build it, will remove existing ieee80211 code from your kernel. If you go to recompile your kernel after building ieee80211 you will get errors. I initially dealt with this by copying key ieee80211 components from the downloaded tarball to the kernel source tree. I emailed the guys at ieee80211 and was told that make patch_kernel will solve this, and to open Bug 1088 for the future.
DRI / Video
I couldn't get Direct Rendering to work with the default nv driver that comes with X. Instead I installed the drivers from nVidia directly (http://www.nvidia.com/object/unix.html). This worked fine except for one thing:
- The installation code put the X drivers/extensions in /usr/X11R6/modules/lib instead of /usr/lib/xorg so I had to move the files over.
Touchpad Tweaks
I ended up installing synclient via Debian package xserver-xorg-input-synaptics. These tools allowed me to try out different touchpad config options in real time. I will include my XOrg.conf file later. I also installed gsynaptics but it doesn't appear to be all that useful.
I still have trouble with tapping. I have to tap fairly slowly if I want to use the touchpad for clicking. I like to use the upper-right corner for middle button (paste) and I'm getting used to it.
UPDATE: I have a configuration which works quite nicely for me now. I'll upload my full xorg.conf file at some point, but in the meantime here's my synclient -l output for the ALPS Glidepoint on a Dell Latitude D620. The only fishy thing about it is when you do a double-tap, you can do the double-tap as quickly as you want but it will not *register* until after MaxDoubleTapTime. So you can do a very quick double-tap, and then wait a quarter-second for the word you highlighted to highlight.
harp {norm} [15:50:04] <~> synclient -l
Parameter settings:
LeftEdge = 130
RightEdge = 940
TopEdge = 170
BottomEdge = 700
FingerLow = 14
FingerHigh = 15
MaxTapTime = 200
MaxTapMove = 2
MaxDoubleTapTime = 250
SingleTapTimeout = 180
ClickTime = 10
FastTaps = 1
EmulateMidButtonTime = 75
VertScrollDelta = 25
HorizScrollDelta = 25
VertEdgeScroll = 1
HorizEdgeScroll = 1
VertTwoFingerScroll = 0
HorizTwoFingerScroll = 0
MinSpeed = 0.09
MaxSpeed = 0.8
AccelFactor = 0.3
EdgeMotionMinZ = 30
EdgeMotionMaxZ = 160
EdgeMotionMinSpeed = 1
EdgeMotionMaxSpeed = 400
EdgeMotionUseAlways = 0
UpDownScrolling = 1
LeftRightScrolling = 1
UpDownRepeat = 1
LeftRightRepeat = 1
ScrollButtonRepeat = 100
TouchpadOff = 0
GuestMouseOff = 0
LockedDrags = 0
RTCornerButton = 2
RBCornerButton = 3
LTCornerButton = 0
LBCornerButton = 0
TapButton1 = 1
TapButton2 = 2
TapButton3 = 3
CircularScrolling = 1
CircScrollDelta = 0.1
CircScrollTrigger = 2
CircularPad = 0
PalmDetect = 1
PalmMinWidth = 10
PalmMinZ = 200
CoastingSpeed = 0
PressureMotionMinZ = 30
PressureMotionMaxZ = 160
PressureMotionMinFactor = 1
PressureMotionMaxFactor = 1
Suspend to RAM / DISK
I am the kind of laptop user who ALWAYS suspends. My uptime is usually months because I only need to restart when (a) I've had a serious crash (usually due to my own bad code or bad usage), or (b) I upgrade the kernel or something. In an ideal world, I want to be able to do both STR and STD.
STR:
- Much faster than STD
- The power usage is so low that the laptop can live for quite a few days suspended in STR
STD:
- Fully powered down, so you can boot other OSes or change the battery or leave it for months
As it stands, I have STR working. This has some disadvantages:
- Need to have an AC outlet nearby to change the battery
- Cannot boot to another OS
- Session could die if I left the laptop alone for a long time, or would not have much STR time left if I ran out of battery and Suspended to RAM with, say, 2% left (how long would STR last on 2% charge? I wonder.... could be a long time? Hours? A day?)
Suspend-to-RAM and Suspend-to-DISK are proving to be the most difficult to set up. I'm making notes for everything I try because there are variable results.
- There was a point where I would get operation not permitted from doing
echo -n {mem|disk} > /sys/power/stateI think this was because for some reason the kernel's make menuconfig didn't give me a SWSUSP configuration option, so it didn't get built with it...? Maybe as a result of the 'make oldconfig' from the original Debian kernel? - So far, in every configuration that has worked, resuming results in:
- CPU#1 is in performance mode where it was in ondemand before suspending (this is the CPU that gets shut down for the suspend, so no surprise that it's put back into the default mode upon resume)
- IRQ 185 gets disabled upon restart
- X has a display-slowness issue which:
- Is not apparent from glxgears -printfps
- Can be seen by running something that would normally scroll by quickly ls / -R or cat /var/log/messages
- More CPU is taken up and CTRL+C is less responsive during these incidents
Here's the results of my testing so far:
| Kernel | RAM | DISK (swsusp) | DISK (suspend2) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Text | nv (/sys/power/state) | nv (hibernate) | nvidia (/sys/power/state) | nvidia (hibernate) | Text | nv (/sys/power/state) | nv (hibernate) | nvidia (/sys/power/state) | nvidia (hibernate) | Text | nv (/sys/power/state) | nv (hibernate) | nvidia (/sys/power/state) | nvidia (hibernate) | |
| 2.6.16.19 | Y-1 RamText | N-1 RamNVplain | N-1 RamNVhib | Y-3 RamNVIDIAplain | Y-3 RamNVIDIAhib | Y-2 s1Text | N-2 s1NVplain | N-2 s1NVhib | N-3 s1NVIDIAplain | N-3 s1NVIDIAhib | Y-2 s2Text | N-5 s2NVplain | N-6 s2NVhib | N-7 s2NVIDIAplain | N-7 s2NVIDIAhib |
| 2.6.16.23 | Y-1 RamText | N-2 RamNVplain | Y-4 RamNVhib | Y-3 RamNVIDIAplain | Y-3 RamNVIDIAhib | Y-2 s1Text | N-2 s1NVplain | Y-4 s1NVhib | N-3 s1NVIDIAplain | N-3 s1NVIDIAhib | Y-2 s2Text | N-5 s2NVplain | Y-4 s2NVhib | N-7 s2NVIDIAplain | N-7 s2NVIDIAhib |
| 2.6.17.3 | N-4 RamText | N-4 RamNVplain | N-4 RamNVhib | N-4 RamNVIDIAplain | N-4 RamNVIDIAhib | Y-2 s1Text | Y-4 s1NVplain | Y-4 s1NVhib | N-3 s1NVIDIAplain | N-3 s1NVIDIAhib | X s2Text | X s2NVplain | X s2NVhib | X s2NVIDIAplain | X s2NVIDIAhib |
- Y-1
- Text-mode resumes but requires
vbetool postto get display back. Message re: IRQ 185 shows up. - Y-2
- Text mode resumes fine. Normal screen, etc.
- Y-3
- Suspends OK, resumes OK. X runs slowly. Text VTs are blank: backlight on, responds to commands, just can't see what you type.
- Y-4
- Suspends OK, resumes OK. X may/may not run slowly. Text VTs work.
- Y-5
- Suspends OK, resumes OK. X runs fast. Text VTs work.
- N-1
- Suspends OK, but shows blank screen when resuming ... neither graphical nor text VTs.
vbetool posthas no effect. Non-responsive, suspect video issues? - N-2
- Suspend fails: hangs immediately after taking CPU1 offline
- N-3
- Suspend fails: hangs immediately after shrinking memory
- N-4
- Textmode suspend OK, but resumefails w/ blank screen. Suspect SATA-HDD init. issues?
- N-5
- Suspends OK, resume fails -- it says "resuming", reads from disk, but then is not responsive (although hitting pwrbtn causes proper shutdown)
- N-6
- Suspend fails: Hangs after Initiating software suspend cycle
- N-7
- Suspend fails: appears to write to disk, blanks screen, does not finish. pwrbtn (sometimes) causes a shutdown as expected. When using 'hibernate', it seems to hang right after doing atomic copy
- X
- Would not suspend: Error loading compressor
NOTES kernel 2.6.16.19
RAM
- Suspend-to-RAM works from textmode
- Blank screen, responsive
- Requires
vbetool postand the screen is expanded afterward - Disables IRQ #185 after a couple of seconds post-resume (appears to be related to [yenta_socket])
- Suspend-to-RAM does not work from X-nv driver using plain echo mem > /sys/power/state nor hibernate -F /etc/hibernate/ram.conf
- Goes down fine
- Resumes with blank screen (switching VTs has no effect)
- Responds OK after resume (at least, the pwrbtn causes a shutdown...)
- At one point got a weird beep noise and then it went non-responsive
- Suspend-to-RAM works from X-nvidia driver using plain echo mem > /sys/power/state
- X runs slowly
- Text VTs are not *visible* but are *active* (I can type in them, just can't see anything d:) (might be solveable with vbetool)
- If I shutdown X, unload
rmmod nvidia agpgartand restart X, then it isn't slow anymore
DISK swsusp
- Suspend-to-DISK works from textmode
- Normal screen w/ prompt
- Disables IRQ #185 after a couple of seconds post-resume
- Suspend-to-DISK might works from X-nv driver using plain echo disk > /sys/power/state
- fail/success = (1/3)
- Suspend-to-DISK works from X-nv driver using hibernate (perhaps 'cause it switches to textmode?)
- I can't tell if X displays slowly or not since it has no GLX stuff loaded up in the first place
- Have access to text VTs
- Suspend-to-DISK does not work from X-nvidia driver using echo disk > /sys/power/state nor with hibernate
- Hangs while suspending
DISK suspend2 2.2.5 for 2.6.16.9
- Suspend-to-DISK works from textmode
- Normal screen w/ prompt
- Disables IRQ #185 after a couple of seconds post-resume
NOTES kernel 2.6.16.23
RAM
- Suspend-to-RAM works from textmode
- Blank screen, responsive
- Requires
vbetool postand the screen is expanded afterward - Disables IRQ #185 after a couple of seconds post-resume (appears to be related to [yenta_socket])
- Suspend-to-RAM might work from X-nv driver using plain echo mem > /sys/power/state
- fail/success (3/1)
- Hangs after bringing CPU down sometimes (right after it takes CPU1 offline)
- Suspend-to-RAM works from X-nv driver using hibernate -F /etc/hibernate/ram.conf
- Can see VTs
- No IRQ 185 error!!
- Suspend-to-RAM works from X-nvidia driver using echo mem > /sys/power/state
- Text VTs are not *visible* but are *active* (I can type in them, just can't see anything d:) (might be solveable with vbetool)
- X exhibits its slowness symptoms
- (just like with 2.6.16.19, really)
- Suspend-to-RAM works from X-nvidia driver using hibernate -F /etc/hibernate/ram.conf
- Text VTs are not *visible* but are *active* (I can type in them, just can't see anything d:) (might be solveable with vbetool)
- X exhibits its slowness symptoms
- (just like with 2.6.16.19, really)
DISK swsusp
- Suspend-to-DISK works from textmode
- No IRQ 185 error
- Normal screen
- Suspend-to-DISK might work from X-nv using echo -n disk /sys/power/state
- Hangs after taking CPU1 offline
- Sometimes works -- wait for a minute after loading X and it seems to work?
- When it works, text VTs work
- X exhibits its usual slowness
- Suspend-to-DISK works from X-nv using hibernate
- Text VTs accessible
- X runs slowly
- Suspend-to-DISK does not work from X-nvidia using echo -n disk /sys/power/state
- Takes the CPUs offline fine, but hangs sometime after doing Shrinking memory
- Suspend-to-DISK ?? from X-nvidia using hibernate
- Takes the CPUs offline fine, but hangs sometime after doing Shrinking memory
NOTES kernel 2.6.17.3
RAM
- Suspend-to-RAM does not work from textmode w/ kernel 2.6.17.3
- Goes down, but does not come back up
- Blank screen, nonresponsive
- Suspect SCSI HDD init. issues
DISK swsusp
- Suspend-to-DISK works from textmode w/ kernel 2.6.17.3 using swsusp
- Normal screen w/ prompt
- Suspend-to-DISK rarely works from X w/ kernel 2.6.17.3 using swsusp
- Only worked once or twice after first booting a different kernel and/or possibly suspending in textmode first - cannot reproduce
- Pauses while suspending otherwise (suspect nVidia driver issue)
- Display runs slowly in X thereafter (i.e.
ls / -Rdisplays slowly) when it does (rarely) work
- Managed to get it to suspend to disk just once but that one time it came back up with fast X and full text VTs
- Not reproducible
DISK suspend2
- Haven't tried yet
More on Suspend-to-RAM slowness
I have noted above that when I resume from Suspend-to-RAM with the nVidia driver, X runs slowly. I have done some experimentation and I've come to this conclusion:
- Scrolling text, such as with
ls / -Rorman bashand moving up/down the page, is dog-ass slow- But only after Suspend-to-RAM
- And only in gnome-terminal
- And only on CPU1, the 2nd CPU (thanks to gkrellm for helping discover that one!)
- Other things like glxgears -printfps and scrolling text in xterm are just as fast after STR even when running on CPU1
- The gnome-ternminal slow-scrolling-text issue goes away if I restart X
- But only if I
rmmod nvidia; modprobe nvidiabetween stopping and restarting X
- But only if I
My final, working solution (plus a happy note about battery and AC adapter)
I am using Suspend-to-RAM as my suspend method. I hope that one day I will be able to use Suspend-to-DISK. The laptop should be able to survive for a few days while suspended. Certainly enough time to commute from work to home, or for a road trip.
The bad news:
- Laptop may die if left un-plugged-in for a long time
- Can't change the battery while suspended
- Can't run another OS in between suspends as with STD
The good news:
- Suspend and resumes quickly
- You can monitor the battery's state without turning the computer on thanks to its built-in power meter
- You CAN change the battery, suspended or not, IF the AC adapter is plugged in at the time (I tested this and it runs off of AC with batt unplugged)
So what does that mean? In the situation where I need to use the laptop on battery for an extended period of time, I can use up most of one battery, find a plug, swap to a charged battery, unplug and keep going. The only place where this plan doesn't work well is if there is no plug nearby (car, airplane).
Notes about the TrackPoint nipple thingie
This thing is annoying. Don't get me wrong, I love the nipple. Like most fast-paced technical users, I prefer that I don't have to move my hands away from the keyboard to use the mouse.
But this Dell nipple is sucky. I've used three or four IBM Thinkpads in my career, and they have all had good nipples. The rarely drifted, and they always corrected within a couple of seconds of drifting.
Dell, on the other hand, is known for crappy nipple behaviour. There have been numerous discussions on web forums about this behaviour on Dells in particular. The pointer drifts quickly to one corner or the other with no warning, and it often goes away for half a minute before it corrects itself. During which time the touchpad doesn't work.
It seems to happen most often when the computer is cold, i.e. when first started up. It tends to stabilize after the machine's been on a bit, but not always.
I have noticed that Linux sees the Trackstick and the Touchpad as separate mouse devices. I tried using xsetpointer to change the mouse pointer when the nipple went wild. It certainly caused the nipple to stop moving the cursor. I tried setting the Touchpad as the CorePointer in Xorg and completely disabling the trackstick. Again, the nipple stopped moving the cursor.
However, the problem is that whenever the Trackstick goes wild, the Touchpad gets disabled. So the cursor doesn't go flying off to a corner, but neither can I move it via the touchpad.
I have since completely disabled the Trackstick. I followed the instructions at Dell's website for removing the keyboard. I found that there are four conductors on a separate blue ribbon that lead to the track stick. These wires feed into the same plastic connector that the keyboard's ribbon cable uses. (I shoulda taken pictures, but I didn't have my camera at the time and I'm not taking it apart again)
So the big plastic connector has all the conductors for both the keyboard and the little nipple, but fortunately they're set apart from the rest. All of the connection points on the female side of the connector (the female connector is on the laptop itself; the male connector is part of the removable keyboard) are along the outer edge of the connector. I cut a small piece of paper and folded it so that it rested along the edge of the female connector, covering the contacts for the nipple. Then I plugged the connector back in, reassembled the laptop, and all is well.
