| My professional interests |
|
Computing Law Education Science and research |
| My leisure interests |
|
Martial arts Heritage railways Garden railways Motorcycles DIY |
| Downloads |
|
Linux downloads Windows downloads Java downloads Perl downloads Home automation downloads |
| About me |
|
Home & family My CV |
| Site info |
|
Contact the author Download policy Keyword index |
The machine
The X55 is branded as a Philips product but is, in fact, made by Twinhead in Taiwan. You won't find any information on it on any Philips Web site, so far as I know. In fact, it's hard to find any information about it at all. I bought it because I was looking for a very small laptop -- and at 1.8kg with a 12" screen it's about as small as decently-featured laptops get -- and it turned out that PC World was selling them at a substantial discount. The salesman told me that the reason for the reduction in price was that the X55 could not run Windows Vista (whatever that is), and PC World customers were demanding assurances that their machines could do this. So Microsoft has done me a favour here.The X55 boasts a 1.6GHz Intel Core 2 Duo processor -- a real dual-core CPU, relatively unusual in a laptop. It has 1Gb of RAM, a dual-head video display based on the Intel Mobile Graphics 945GM chip, a 100Gb hard disk, and a DVD read/write unit. The hard disk is a SATA unit, which is supported in Linux by the SCSI infrasructure -- something to bear in mind when compiling kernels. There is a built-in SD card reader, but I have no idea how it is connected to the rest of the machine, so I haven't been able to test it. There are wired and wireless (54 mbps) ethernet adapters on board.
Installation
The first problem is to make room for Linux on the hard disk, unless you want to trash Windows altogether. Although such a course of action has a certain appeal, I'm rather glad I didn't do this straight away, as I needed at least one OS working to download updates, etc. -- getting any network adapter working under Linux was a significant challenge from the start.The easiest (no-cost) way of resizing a Windows NT partition is, in my experience, to use
gparted -- the Gnome Partition Editor.
Of course, gparted runs under Gnome, which implies Linux,
and we don't have any Linux yet. gparted is available as a
bootable CDROM image, but the version I had -- only a few months old --
didn't work. It failed at the point of loading the ohci1394
(firewire) driver, which was not necessary for my task. But, try as
I might, I couldn't find out have to prevent the embedded Linux on the
CDROM from trying to load the driver. Happily, the latest (3.3.2)
gparted either didn't load the driver, or has a non-broken
driver, and it worked fine.
The X55 hard disk as supplied actually has two partitions -- a 5Gb vfat partition and the rest of the disk as NTFS. I think the vfat partition is for Windows recovery, as it seems to have a Windows installation on it. Perhaps it is for Windows hibernation as well. In any event, if you want to have a partition for Linux, a partition for sharing between Windows and Linux, and a partition for swap, you'll have to use
gparted to create five partitions, not four -- partition
three should be an extended partition which will contain partitions
four and five. This is because you can only have four primary
partitions on a hard disk of this type; but a single primary partition
can contain multiple logical partitions.
Having resized the disk, the next problem was getting the Fedora installer
to run. It booted, but hung during hardware detection. I couldn't find out
which particular hardware was defeating it (from later experience, I think it
was the network adapter), so I had to run the installer in `noprobe'
mode. This allowed the installer to run all the way to completion, but
left me with a certain amount of manual configuration post-install. But
this was the least of my problems, since the installed kernel wouldn't
boot, for several reasons. Apart from that little problem, the installation
itself was unproblematic.
The first reason for non-booting was that the installer defaulted to
installing a kernel with SMP support. This simply wouldn't even start
to boot. To fix this, I had to boot from the Fedora installer in
`rescue' mode, and manually install the non-SMP kernel from the RPMS.
I also had to use mkinitrd to create a new initial
RAMdisk image for the non-SMP kernel, since this is not supplied as
an installable RPM. Note that you're more-or-less constrained to use an
initial RAMdisk for booting this machine, because the hard disk is a SATA
device, and it needs a big chunk of the SCSI infrastructure to support
SATA. You could probably compile the SCSI stuff directly into the kernel,
and avoid using an initial RAMdisk, if you can figure out exactly
which bits you need. It hardly seems worth the effort.
The non-SMP kernel did load as far as running system initialization, but the boot failed when starting the
udev service.
This turned out to be the result of an unhelpful 8139too
module -- the driver for the built-in wired ethernet adapter.
This is the correct driver for the hardware, so at this stage
the only solution is another trip into rescue mode to move the
offending driver out of the module tree so it doesn't get loaded.
So, with these steps (preceded by a large amount of head-scratching
and Googling), I was able to get Linux to boot to an X session.
The FC5 installer configures the Vesa video driver for Xorg, which
works well enough at this stage. However, the Vesa driver doesn't
support the Xvideo extension, which is essential for such essential
work-related activities as playing movies. See below for more details.
Although Linux would boot after the steps described above, I was
still left with no workable network connection. I knew what changes
I needed to make to the kernel configuration to fix the
8139too driver (thanks to Google), but this required
recompilation of the kernel.
X
FC5 comes with an installer for the Xorg server and utilities, and this worked more-or-less as supplied. However, the default installation uses the Vesa driver, which is quite limited. The X55 graphics chip in an Intel Mobile Graphics 945GM device, notionally supported by thei810
driver in Xorg. From the preceeding horror stories, you probably won't be
surprised to find that this driver didn't work without a lot of effort. I had to
hunt around for a newer verion of the i810 driver, in addition to a newer
version of X server to use it with, but not so new that it interfered with
other bits of the X installation. In the end I had success with version
1.1.1.17 of the X server, and 1.6.0-2 of the i810. As an idea of how
fussy it is, version 1.6.0-1 did not work.
So now I have support for the XVideo (hardware scaling) extension, and direct rendering appears to work (but I haven't really tested it that much).
It is also possible, using the i810 driver, to enable the non-standard video modes of the built-in graphics driver. This might be quite important, since most of the modes supported by the Vesa driver assume a 4:3 screen, and the x55 has a screen that is nearer 16:9. A good fit to the resolution of the X55 screen is a resolution of 1280x800, which is supported by the video hardware. To get this resolution it is necessary to add it to the table of available resolutions in the video adapter BIOS. A utility called
915resolution (Google for distributors)
is readily available for this task.
For example, if we execute
915resolution 38 1280 800 24we create a new resolution mode of 1280x800 at 24 bpp. The number 38 is the index into the mode table of the BIOS, and this number is chosen simply to replace an unused mode. The final step is to add "1280x800" as a resolution setting in
xorg.conf. The effect of 915resolution is
transient, so the utility needs to be run (e.g., from an
rc script) at each boot.
The 945GM device supports dual-head operation, with the LCD display panel forming one
head and the external VGA output forming the other.
In ordinary, single-head operation --
what you get with the default X installation -- the external VGA output follows the built-in
LCD, including in refresh rate. This is less than satisfactory with a CRT monitor
connected to the VGA output, as the LCD panel will not
refresh at more than 60Hz, and this rate produces a terrible flicker on a CRT. So getting
dual head mode to
work is beneficial even if you want both displays to show the same thing.
Moreover, dual head operation allows us to use
`Xinerama' mode, in which the desktop is contiguous across the two displays.
This requires, in addition to a dual-head capable video adapter and driver,
a window manager which understands this mode of operation -- the Gnome window
mananger seems to handle it quite well.
I had some difficulty with dual head operation in general, and Xinerama in particular. In any dual-head mode, I found I had to disable acceleration and hardware cursors:
Option "SWCursor" "true" Option "NoAccel" "true"Without this, the X server crashed. There may, perhaps, be a less brutal way to overcome this problem than disabling acceleration, but I haven't been able to find it. The lack of acceleration does not create a significant problem for ordinary desktop operations, but it significantly upsets the all-important movie playback.
There is plenty of documentation on-line about getting Xinerama to work and, on the whole, getting the basic `wide desktop' wasn't difficult. The tricky part was allowing the two video sources to run in different resolutions. The LCD panel has 16:9 aspect ratio, while my CRT monitor is 4:3. Moreover, the CRT monitor is huge compared to the LCD panel, so using the same resolution for both is unsatisfactory. It took a lot of trial-and-error to find a combination of resolution settings that worked. In the end, I settled on 1280x800 at 16bpp for the LCD display, and 1280x1024 at 16bpp for the CRT. I wasn't able to get 24bpp on any screen in Xinerama mode, but this isn't a limitation of dual-head operation in itself -- it is specifically a Xinerama problem. It's possible, I guess, that the video adapter just doesn't have enough RAM to manage a virtual display in 24bpp when it is, after all, more that 2000x1000 pixels in size. Fortunately, the
xorg.conf file can accomodate a number of different head configurations
(`server layouts' as they called in the Xorg world),
so both the dual-head arrangement -- with its limitations -- and the single-head
arrangement can be specified, and the appropriate server layout selected on the command
line when launching the X session. Unfortunately, I don't believe that the GDM graphical
session manager can accomodate multiple server layouts in a single xorg.conf,
so I do an old-fashioned text login and then launch X, specifying whether I want single head
or dual head operation.
USB
Amazingly, it just worked.Sound
The audio adapter is an Intel `High Definition Audio' device. If hardware auto-detection has failed, and if you're using the ALSA audio infrastructure, you need to enable the driver inmodprobe.conf:
alias snd-card-0 snd-hda-intelAudio output worked without problems for me.
Wireless network
The X55 has a built in 54 mbps wireless ethernet adapter. This seems to be well supported by theipw3945 driver project which is
hosted at SourceForge. The driver requires a firmware image to download
to the adapter, and a monitoring agent. Both are available in binary-only
form from Intel, and instructions for obtaining them are included with
the driver source. For the firmware download to work smoothly, your
Linux implementation needs to have hotplug support configured -- but
in FC5 all I had to do was to copy the image to /lib/firmware.
There are complications about the order in which the management agent
starts with respect to the driver module loading; but I followed the
recommended procedure in the install instructions -- slaving the agent
startup to the module install in modprobe.conf -- and that
seems to work fine.
The
ipw3945 driver is only available as source, and requires
a properly-configured kernel source tree to build. So there's no point
even thinking about getting the wireless adapter working until you're
recompiled the kernel.
Power management
Needless to say, a machine like the X55 needs ACPI support in the kernel. I am using the standard ACPI that comes with kernel 2.6.20, although more recent versions may well be available as patches.To get suspend-to-RAM working at all I had to add the following kernel argument (this can be done in
grub.conf in FC5):
acpi_sleep=s3_bios,s3_modeBut this still left me the problem that an X session wouldn't resume after suspend -- the display came up blank and was stuck in that state. To make suspend-to-RAM work in an X session, I had to add
Options "VBERestore" "on"to the driver section of
xorg.conf, and comment out all
the vbetool commands in /etc/pm/functions-intel.
So far I have been unable to get suspend-to-disk working at all. The
state is written out to a swap partition as I would expect, but the
fact that there is a resumable image is ignored completely on next
boot. I suspect that this problem is related to the use of a SATA
hard disk -- perhaps the resume process starts before the driver for
SATA becomes available? There are other hibernation options available in
Linux, and possibly one of them would work. But I'm happy enough
with suspend-to-RAM.
The X55 does seem to run somewhat hotter than other laptops I have used but, to be fair, my other laptops are
much older and slower. With the machine completely idle apart from background processes and the X server,
the temperature gradually creeps up to about 61°C, at which point the fan comes on until it gets back
to 50°C. At full load -- both CPU cores at full capacity and the CPUs running at full clock speed -- the
temperature hovers around 60°C with the fan running at a modest speed. I have seen peaks of 64°C, by
by suddenly applying full load when the temperature is already at its normal highest point, but before the
fan cuts in.
These temperatures are within the design limits for the CPU, but it's worth bearing in mind that long-term fanless operation is not possible with this particular laptop. At idle, the fan runs for about ten seconds every minute or so. Interestingly, under Windows the fan runs all the time, but at a slower speed, which I guess is another way to achieve the same amount of cooling.
Wired network
The on-board wired ethernet adapter is a RealTek 8139, supported (in principle) by the kernel module8139too. However, the stock driver hung the machine, even
from the latest kernels. A bit of googling suggested that the fix might be to
add the following switches to the 8139 section kernel config and recompile:
CONFIG_8139TOO_PIO=y CONFIG_8139_OLD_RX_RESET=yThis proved, indeed, to be the case.
SMP issues
The X55 contains an Intel Core 2 Duo process, which is a true dual-core unit, and should benefit from SMP support in the Linux kernel. In fact, compiling the standard FC5 (version 2.6.15) kernel for SMP support did not seem to work at all, in the sense that the kernel would not even boot. 2.6.20 does boot and run properly with SMP support compiled in but the performance results were, well, underwhelming for day-to-day PC tasks. My CPU load benchmarks showed that the throughput with the SMP kernel, when given a single-threaded task, was about 15% lower than with the uniprocessor kernel, all other kernel options being the same. Of course, with two CPUs, even a 15% reduction per CPU still means that the total achievable throughput is 70% faster than single-CPU throughput.The problem is that, for most day-to-day computing operations, what you notice is the 15% reduction in single-CPU performance, because most desktop operations are effectively single-threaded. Animations (such as menus popping in and out) look particularly clunky. It's only when you're running multiple applications that you really notice the overall throughput increase. And even then, because there is only one disk, and one display driver, the total increase in throughput is unlikely to be 70%. For heavily IO-intensive operations, the throughput might even reduce.
Of course, these issues are limitations of SMP in general, not the X55 laptop in particular. What I can report is that SMP does work on the X55 (with 2.6.20 kernel), and performs much as expected.
Not tested
PCMCIA; built-in SD card reader; Firewire; modem.Conclusion
Most things work, but it was an uphill struggle to get to that state. The things that don't work (e.g., suspend to RAM) could most likely be made to work with sufficient effort, but I don't use them enough to warrant it.
| Search |
| Shameless plug |
 By the author of this site. Buy on-line from Amazon USA | UK |
| Editorial |
So you want to be a university lecturer? Read this first! Speak like your boss: new developments in managerese |
| Computing features |
|
File handling in the Linux kernel: an in-depth look at how Linux handles files, filesystems, and file I/O
All sorts of Linux stuff Confused about CLASSPATH? answers are here First steps in EJB using jBoss (recently revised for jBoss 3.2) |