LevelsOfDetail

I decided to give the new Ubuntu beta a whirl on my X60. Recently I've heard a few anecdotal success stories of running Ubuntu on laptops, so it seemed worth a try.

I was concerned about running a beta installer on my work machine, so I decided to run the Edgy installer instead. I backed up my important files and used the built in NTFS resize functionality to make space (which, worked surprisingly well, considering my past experience with it). Once Edgy was installed, I used the update manager to pull in the new beta version (you can do so by running update-manager -d). The update took a while, as it had to download all the new packages, but the install completed without a hitch, and one reboot later, I was running Feisty.

First impression: looks mostly the same. Same brownish theme, and same ugly fonts in Firefox. I did get a bubble notification at start up that told me that I was using "restricted" drivers. A few clicks later, I was told that they were for my wireless chipset. Fine, whatever. I appreciate what they're trying to do here, but I don't think most end users really care. Feisty seems to make it very clear that "restricted" drivers are unsupported and may have problems that can't be fixed. Yet it seems ironic and somewhat pointless, since for most users, Ubuntu is going to have problems that aren't going to be fixed regardless of whether the at-fault component is open source or not.

Anyhow, I do applaud them for at least distributing the driver, and to make it work without any user intervention. It's a good start.

The one feature that was going to decide whether I was going to be able to use Linux regularly on this machine was suspend-to-RAM. The first time, I just I tried it as a normal user would (by hitting the sleep hotkey), and it worked! I was rather surprised, since I had heard all kinds of fun stuff about having to write custom scripts that unload and reload things as your machine goes into and out of sleep.

The feeling of "finally!" quickly faded, though, as the second and third attempts all failed in different ways. The first time, the wireless card disappeared. The second time, the screen wouldn't come back. The third time, I lost sound.

Well, so much for that. I tried a suspend-to-disk a few times, and that seemed to work. But I don't feel motivated enough to debug the hardware issues to make the sleep work. It's probably going to make me compile new kernel modules or god knows what.

That being said, it seemed that the whole sleep thing was very close to working. Much closer than any previous incarnation of Linux I had seen. Most of the special Thinkpad hotkeys worked, and it didn't seem like any of the apps freaked out about the machine going to sleep underneath them. The battery, as well as the CPU frequency scaling seemed to work fine.

Not everything was negative, there were a few "I wish Windows did this" moments. One was the support for the conventional "middle button scroll" feature of Thinkpads. Since many Thinkpads don't have touchpads, IBM had a feature where you press and hold the middle mouse button to turn the track point into a scroller. On Windows, it works fairly well, but you always run into apps that don't support it. It's as if the functionality is implemented a little too high up the stack. The most annoying effect is that the scroll functionality get's lost when using remote desktop client software. Both VNC and RDP clients will not properly send the scroll events to the remote end, which sucks.

On Linux, you can just use the "EmulateWheel" option in your xorg.conf file to turn on this exact feature. And it works at the X-server level, so it works with all apps that understand scroll events. This is certainly an improvement over Windows.

At the end of the afternoon, however, it doesn't make sense to run an OS that can't properly drive all of your hardware. I suspect that this might actually be the case for my desktop, so I will investigate that when the final release is available.

For now, on the Thinkpad, I'm much better off running Feisty in a VMware Workstation environment (especially with the new version which will have VMI support so things will be pretty fast).

As someone who's been using Linux in various forms for a while, I fully understand that it's not really Ubuntu or Canonical's fault that these things don't work. ACPI is really hard, and closed drivers make everything hard. But until the community figures out how to overcome these problems, Linux doesn't have a chance in the laptop space.

Maybe it'll happen like this: People will realize Vista blows. Linux will continue to catch up and eventually get good enough to be equivalent of the XP experience (on a few hardware configurations). Maybe a migration to it will become possible with some extra pieces like Parallels-like "coherence" except with a Linux host and an XP guest. People will start to see Linux as a potential alternative, and all of a sudden, companies that write Linux drivers that work will have an advantage.

Or maybe some big hardware PC manufacturer will finally try to get off the sinking Vista ship, and release a limited line that is tested to run with Linux, and has a hardware configuration that is as Linux-friendly as it can be. Who knows. Maybe it'll be Dell. Someone the size of Dell might be able to use it's influence to convince suppliers of hardware components to even write drivers, or at least release specs.

Before I go, a few miscellaneous observations about Feisty:

• Still uses freetype 2.2.1. Not sure if there's a reason. 2.3.1 seems to work fine for me at work, and works better with some fonts.
• The default font settings are "grayscale" smoothing and "medium" hinting. It looks pretty good for GTK apps, but for some reason Firefox looks pretty ugly.
• ThinkWiki is a pretty useful site that has a lot of random details about running Linux on Thinkpads. You can solve some of the smaller problems by reading those pages, but it doesn't seem like it will help you solve big problems like getting suspend-to-RAM working.
• Battery life under Linux seemed pretty good. At full charge, the readout was at about 5.5 hours, and it didn't seem to drain particularly quickly or anything.
• Firefox still doesn't support GTK input methods out of the box. You still have to set up your GTK_IM_MODULE env variable to point to something

Further reading of the ThinkWiki led to this page which details installing Feisty onto a T60. While the hardware isn't exactly the same, the symptoms described on that page (especially with regards to problems with suspend to RAM) sounded familiar, so I tried their suggested fixes, which seem to work.

So now my X60 suspends and resumes pretty reliably. But issues remain.

Joining a WEP-based wifi network seems to take forever, and sometimes just never works at all. I've also seen instances where the network manager seems to forget that I have a wired ethernet card (which is always detected correctly on startup).

The last little bit I'd want to work before I could switch was the hard drive shock protection system. To my surprise, it looks like a lot of code has already been written for it. ThinkWiki has this page about it.

Unfortunately, while Feisty seems to come with the required kernel module, none of the userland utilities worked. They have a fancy gl-based utility that graphically shows the tilt of your laptop, which showed nothing, as well as a command line utility that continually prints readouts from the accelerometer, which also produced no useful output.

I upgraded to the new Feisty kernel, 20-14, and lo and behold, my accelerometer readout started working. I can now run hdaps-pivot to get values as well as hdaps-gl to see a rotating GL rendring of my laptop.

That's cool. Wait, no it's not.

It turns out, although now it can read out values from the accelerometer, that's all it does. To get actual hard disk protection, you need a userspace daemon, and a kernel patch. Which leads you to this page.

To paraphrase, the patch is out there, it's for an older kernel, and it's too intrusive for Ubuntu guys to feel comfortable including it.

Fantastic.

I guess the old bit of wisdom is still true: if you really want to use Linux, you'd better be ready to compile anything yourself.

Maybe someday I'll get around to patching my kernel. I found out about apt-build, which looks like it might make the process of doing so just a tiny bit less painful.

Just in case anyone was wondering, at least I'm not the only one that is annoyed by fonts on Ubuntu .

As described by that bug report, the most annoying aspect of it is that different applications seem to behave differently. And other reports claim that settings change even if only have a blank .fonts.conf..

Anyhow, I think I've finally managed to cook something up that works pretty well.

The first thing to note is that, apps that render using the Xft library appear to have problems with the hintmedium hintsyle setting that Ubuntu defaults to. The most prominent of these apps in a standard Gnome-based Ubuntu desktop are Firefox and gnome-terminal (gnome-terminal uses Xft for performance reasons, apparently). Doing anything that causes these apps to try to render in the medium hinting style causes them to use the "slight" style instead, causing inconsistency among your apps.

The solution to this is to simply use "full" hinting for everything. That is accomplished by putting the following bit in your ~/.fonts.conf.

  <match target="font">
    <edit name="hintstyle">
      <const>hintfull</const>
    </edit>
  </match>

This essentially means turn on "full hinting" for every font.

Now, that's not really necessarily what you want. A case that commonly comes up for me is that I actually don't want Japanese fonts to be hinted. But I choose to disable that selectively. I can do that with something like:

  <match target="font">
    <test name="family" qual="any">
      <string>UmePlus P Gothic</string>
    </test>
    <edit name="hinting">
      <bool>false</bool>
    </edit>
  </match>

It has to follow the previous block (because the edits get evaluated in order).

DPI settings

The other part that causes major problems in font rendering is the screen DPI setting. There are numerous places that this value can be set, and having different values in different places causes different apps to render fonts in different ways.

The first thing to do is to make sure your settings are consistent. For my laptop, I decided that I wanted to use a DPI setting of 72. (It's a 12 inch 1024x768). Here are the places I had to put this number in:

1. In gnome-font-properties. Go in to the "details" screen and set the DPI to your desired value.
2. In ~/.fonts.conf. Add the following bit:

      <match target="font">
       <edit name="dpi">
         <double>72</double>
       </edit>
     </match>
   

   This "edit" tag can be combined into the same "match" blog as the previous hintstyle setting if you prefer.
   



3. Finally, the hardest one to find was for Firefox 2.0. Unfortunately, beginning in 2.0, Firefox no longer has a UI checkbox that determines whether the browser respects the system DPI setting when determining font sizes. Asside from this, the actual internal option that controls this value has changed three times from 1.0, to 1.5, and now 2.0. The magical value layout.css.dpi is described here. Set it to 72 using the the URL "about:config" in your browser

With these three settings, every app that I use regularly now has consistent font sizes and hinting settings.

I'm still not really sure why Ubuntu defaults to the "medium" hinting style, given the existence of these bugs. Maybe it was something introduced late in the cycle and nobody noticed.

Another interesting undocumented setting is MOZ_DISABLE_PANGO. This environment variable controls whether Firefox uses the pango module to render its text. It's meaning is negative, so if you want pango rendering, you say MOZ_DISABLE_PANGO=0. On Ubuntu, this value is set in the firefox wrapper script depening on your locale, since pango is required to render some of the more complex scripts. It is not turned on by default, because there are some performance issues and it breaks MathML rendering (who cares). I also found that it has some minor text rendering bugs, but with pango, Firefox does seem to respect the gnome font properties' hinting settings.

And a last note, if you do decide to use MOZ_DISABLE_PANGO=0, then make sure you set the layout.css.dpi value appropriately. For some reason, using pango makes the DPI calculation go really wonky. In my case every font was rendered much smaller than in other apps.

So apparently Microsoft came out with a patch to fix the horrendous Outlook 2007 performance problems.

In this article, there is a choice quote from Jessica Arnold, the Outlook program manager:

In the long run, she said the company is "definitely investigating" whether to re-architect Outlook’s use of .PST files for local storage, as some users have requested. But she also warned that users shouldn’t view their active .PST files as long-term storage for e-mail.

"Outlook wasn’t designed to be a file dump; it was meant to be a communications tool," she said. "There is that fine line, but we don’t necessarily want to optimize the software for people that store their e-mail in the same .PST file for 10 years."

Umm yea. Nobody would ever store 10 years worth of email would they? And sure no company would ever release a desktop search product that in combination with storing 10 years of email would be extremely useful, would they?

This statement isn't too far from Bill Gates' infamous "640K is all we need" comment, but seems to indicate a tendency for Microsoft to underestimate it's users.

The most infuriating part of the whole thing is, well if we're not supposed to use PST files, then what are we supposed to use? And I'm going to slap you if you say Local Folders.

Still no hard drive protection, but everything else seems pretty good. Suspend and resume works, and joining wi-fi networks seems reliable as well. I've got pretty much the best font settings I can hope for with this amount of work.

One thing I noticed was that because the X60's screen doesn't have the greatest viewing angle, the quality of fonts varies greatly depending on how you look at the screen. Things look particularly crappy if you looking at the screen from below (relative to perpendicular).

I thought maybe a gamma calibration would help, but then realized it was impossible since the calibration pattern looked different from every angle that I looked at it.

Oh well.

So maybe the only thing left to do is get a SSD drive. That makes hard drive protection support irrelelavant.

I've been always kind of planning on running Linux on my desktop again, given that I now have pretty much unlimited access to vmware software ;-).

I had been running Windows for a while now, mainly because I couldn't get Ubuntu Edgy to install (jmicron driver bug). With the release of Feisty Fawn, that changed, and now I have a fully installed Feisty Desktop.

Great. Now time to install workstation. I know Workstation 6 is almost out, but I decided to go with 5.5.3 (trying to stay conservative with my home machine).

Immediately I hit the problem of not being able to build the vmmon kernel driver, same output as this VMware community discussion post. The reply on that post suggest's using the famous any-any patch. So I grab that and run it, and while my vmmon then builds, when I go to run a VM, I'm told that I have a vmmon version mismatch.

This probably just means that the any-any patch hasn't been updated to work with the Feisty kernel. Great, am I stuck?

Feisty comes with vmware-player packages (if you enable the multiverse) They appear to have the version number of 1.0.2, so something from the Workstation 5.5.x series should work. I asked Phil, and he mentioned that the Ubuntu provided vmmon modules should work fine with WS 5.5.3.

Sweet. Except that the standard install step of running vmware-config.pl always tries to build vmmon, and fails, so how am I supposed to install?

<BEGIN TOTALLY UNSUPPORTED HACK. PERFORM AT YOUR OWN RISK>

There are a few required steps:

• Install Feisty's kernel modules.


• Symlink the modules into the place that 5.5.3's startup scripts expect them


• Hack vmware-config.pl so that it doesn't try to build vmmon and vmnet

First step is easy:

% sudo apt-get install vmware-player-kernel-modules

Second step is relatively easy too:

% cd /lib/modules/2.6.20-15-generic
% sudo mkdir misc
% cd misc
% sudo ln -s ../vmware-player/vmmon.ko vmmon.o
% sudo ln -s ../vmware-player/vmnet.ko vmnet.o

Just a few notes: 2.6.20-15 is what Feisty released with. If you're reading this by the time that Feisty has released an update kernel, then use the directory that it appropriate for your kernel.

Also, make sure that your module symlinks have the extension .o instead of .ko. This is what the /etc/init.d/vmware script looks for.

Finally, the last step is to modify your vmware-config.pl. Here's the diff for my modified version:

--- vmware-config.pl.backup     2007-04-21 18:05:58.000000000 -0700
+++ vmware-config.pl    2007-04-21 18:14:33.000000000 -0700
@@ -3649,9 +3649,9 @@
 
 # Configuration related to the monitor
 sub configure_mon {
-  if (configure_module('vmmon') eq 'no') {
-    module_error();
-  }
+  #if (configure_module('vmmon') eq 'no') {
+  #  module_error();
+  #}
 
   if (-e '/dev/.devfs' || -e '/dev/.udev.tdb' || -e '/dev/.udevdb' ) {
     # Either the devfs" or "udev" filesystem is mounted on the "/dev" directory,
@@ -8955,7 +8955,7 @@
     configure_mon();
     configure_pp();
     configure_net();
-    build_vmnet();
+    #build_vmnet();
   }
 
   # Create the directory for the UNIX domain sockets

Essentially you just have to comment out a few lines as the diff indicates. Then run vmware-config.pl as you normally would and you should be good to go.

</TOTAL HACK>

Well, it looks like my little tutorial on setting up WS 5.5.3 on Feisty was pretty popular.

Unfortunately, (or fortunately perhaps, I don't know) I've upgraded my Workstation to an RC release of WS6.

The reason? Printing.

There's not special install trick here. Once WS6 is released, you should be able to just use the standard tar installer to get it on to a Feisty system.

I recently bought a Canon Pixma iP6700D printer. I was using it under XP just fine, and assumed it would work fine under WS 5.5.3, but any access to the printer would cause a BSOD in the guest.

While looking around for alternatives, I actually found TurboPrint which appears to be a set of commercial drivers for photo printers for use under linux. Didn't try it myself quite yet, but I'm fairly interested.

Anyhow, upgrading to WS6 fixes the BSOD issue. That's important enough to me to deal with the slight riskiness of running a release candidate build.