Linux on the Panasonic CF-Y5

Setup August 1, 2006; last updated April 25, 2007

The Panasonic CF-Y5 (the laptops in the CF-R/T/W/Y series are sometimes called a "Let's Note" or "Toughbook") is currently produced only for the Japanese market, but can be bought from companies that specialize in providing just such products for the US, European, and other markets. (Such companies include Dynamism, GeekStuff4u, Kemplar, etc.) I bought mine from GeekStuff4u, in part because it was the only supplier I could find that would sell it to me "naked" -- without an installed copy of Windows. (Of course, that choice means that I cannot test components under Windows.)

The CF-Y5 provides a super tough (said to withstand a 3ft drop and a 100lb pressure test -- I obviously did not test those claims!), super light (3.3lbs with battery), 14.1" laptop with built-in DVD R/W and very long battery life (I am seeing 5 hours on constant wireless, 6-7 hours without wireless, but with a lot of disk activity, and nearly 8 hours with wireless off and the DVD de-powered through the BIOS). The Y5 is the latest iteration and comes with an ultra-low voltage Core Duo processor (mine is a L2300), a spill-proof keyboard (another feature I did not test!), faster memory, etc.; it also has a convenient hardware switch (a slider on the front edge) to turn off and on the wireless device. Here are the main components in mine (latest versions ship with an L2500, up to 120GB disk, and up to 2GB main memory). If you want to change the disk, consult the excellent photographic step-by-step description from Markus Fraenz (it's for a CF-Y2, but the case design of the CF-Y5 is very similar).

Because the machine is for the Japanese market, the standard keyboard for export is the Japanese International keyboard, which has more keys on it than the standard US keyboard and puts a number of punctuation marks and other non-alphanumeric characters in different places. I touch type, so I just ignore what's written on the punctuation keys ;-) The extra keys mean that the space bar is noticeably smaller than what I am accustomed to on US-market laptops -- it took me a couple of hours to get accustomed to it.

Below are tips on how to get things working under Debian. Since it took me some effort to set it up (not a lot more than for my several past Dells, NECs, and Sharps, all of which were also bleeding-edge in their time ;-), I thought I would share the experience.

Here is the status in a nutshell. Green means working out of the box, purple means easily done, but with some downloaded software not packaged under Debian, orange means working with some issues, and red means not supported. (Note that, when I write "Out of the box", I do not mean that the stock kernel in the distro will do it, just that it only takes compiling a new kernel to have it working.) It is quite a tribute to the Linux community that pretty much everything works -- the only red is for the (nearly useless) standby state, which, for all I know, may not exist under this BIOS anyway, and the two oranges denoting issues are both related to the peculiarities of the Intel 9xx integrated graphics chip family.

Item Status
Dual-Core Support out of the box
Sleeping to Disk works using the suspend2 package (easy to use, but requires kernel patch)
Sleeping to Memory sleep from X works out of the box, but with varying issues on resumption
Standby not supported
ACPI Events out of the box
Frequency Management out of the box
Video works, but with a few issues; and clean switching between screen and external monitor/projector remains to be accomplished
Hotkeys works, but requires installing PCC-ACPI driver
Ethernet out of the box
DVD R/W out of the box
Touchpad out of the box
Sound out of the box with kernel 2.6.20 and later, but speakers may not work under every kernel/ALSA combo
Wireless works, but requires installing the IPW3945 driver
PCMCIA out of the box
SD Card out of the box with kernel 2.6.20 and later
Modem works with sl-modem package

I currently (April 2007) run kernel 2.6.20; here is the .config file for it. I had to download and install the following packages so far:

All proved easy to install and run.

Dual-Core Support

The distribution kernel may or may not support it, but any of the recent 2.6 kernels will support it with the appropriate configuration. Starting with 2.6.20 kernels, there is an option for "Core 2" chips, which is not the correct choice for this machine -- the processor, although dual-core, is effectively a Pentium M.

Sleeping to Disk

Note that I tested only suspend2, which is not part of the kernel (the kernel does have the original suspend, which, for all I know, may work fine). In order to get sleeping to disk, you must enable it in the kernel, which requires you to get the patch for suspend2 from, to patch the kernel, and to recompile it -- the site has very detailed and helpful instructions. You also need to install the hibernate package (from the Debian distribution or from that same site) to get helpful scripts. Use "hibernate" rather than echo to /sys/power/state to get the hibernation started. (Note that I only used the hibernation by writing to the swap device; it should be possible to hibernate under suspend2 by writing to a file in the regular filesystem, but I was not able to configure that option properly.) Going into, as well as waking up from, hibernation takes less than 15s, even with X running.

Hibernation via suspend2 works fine, but the resumption may have a display glitch, depending on the video driver -- see below for that. With the xf86-video-intel driver from Xorg (Debian package version 2.0.0, rather than the 1.6.5 and 1.7.2 that come with the regular Xorg 7.2 releases), there is no problem at all. With the drivers that are still named i810, I can get suspend to and resume from disk (swap device) with X running, 915resolution rerun, the wireless connection reestablished without missing a beat, but the X display is somewhat messed up (presumably because the 915resolution rerun comes too late, after the restoration of the X states) and the display, while legible, is distorted.

There is a cute icon on F10 (a very small "z" and a multiple disk platter ;-) for sleeping to disk; you can use it through the hotkeys mapping.

Sleeping to Memory

In order to get sleeping to memory working, you must enable "Hotplug CPU" in compiling your kernel (CONFIG_HOTPLUG_CPU=y). (Big thanks to David Shaohua, an Intel ACPI maintainer, for pointing this out: the ACPI subsystem needs to be able to "unplug" one of the CPUs in order to initiate the sleep sequence.)

Now, /sys/power/state will show two possible states, disk and mem -- it does not identify a state standby. (Note that this is new starting with -- under, it showed only the mem state!)

The usual command
echo -n "mem" > /sys/power/state
will put your machine in sleep-to-memory mode; sliding the power button will wake up the machine; both are very fast (3-4s in each direction). It works with no precautions at all (I am not using any script to shut down and restart various applications and daemons), but I do have audio and pcmcia (and of course, wireless and modem, but for those it's not a choice) compiled as kernel modules rather than built-in.

Curiously, the backlight does not come back on when the cycling is done from console, but it does when done from X (Xorg, in this case), although even then the consoles are not usable. Under the older, non-modesetting driver (still named i810, rather than intel), the display was fine on resumption, except for a small artifact (about 1/3 of a line, 1 pixel high, of variable location, that displays some other area of the buffer) -- no explanation for that, but see the final notes below. Under the newest driver, xf86-video-intel (Debian package 2.0.0), however, the display is distorted -- the driver still thinks it's 1400x1050, but the scaling is wrong (it seems to use about 3 horizontal pixels on the screen for every 2 pixels it's supposed to display, so you do not see the full screen). No explanation for that for now -- especially since the same driver switch that caused this problem with sleep-to-memory fixed the one with sleep-to-disk... It could be that some of the other drivers and daemons need to be shut down and restarted in the suspend script -- the hibernate script does that for sleep-to-disk.

There is a cute icon on F7 (a very small "z" and a memory chip ;-) for sleeping to memory; you can use it through the hotkeys mapping, but I use the ACPI lid event (see below for these events) to put my machine to sleep and wake it up.

ACPI Events

Supported without problem in a new kernel. Since standby is not available I set up the lid event to turn off the screen (and nothing else), and the button event to shut down the machine. (Once I figure out the right script to have sleep-to-memory and wake from it work properly, I'll post my script and switch the lid-closing to that action.) The ACPI system provides all necessary information for the battery state -- I normally use gkrell to give me a battery monitor.

Frequency Management

No problem with a compiled kernel, but I was a bit disappointed to see only two possible frequencies (1GHz and 1.5GHz). No fear, though: on the consumption side, the processor is ULV and uses very little power, so there is not an overwhelming need to slow it down a lot; and on the speed side, memory (and, for response time, a very aggressive policy for idling the disk) is the limiting factor. I normally use the "conservative" governor -- it does not find it necessary to run at 1.5GHz even while compiling a new kernel under AC power.


There are three issues to deal with here. One is resolution: the Video BIOS needs to be set up properly for each resolution and, by default, the 1400x1050 full screen resolution is not supported (!). The fix is to continue using the 915 driver (in the kernel), but to install the 915resolution package (an "extra" package under the category x11 in Debian). The package has excellent instructions with it. As the author remarks, which of the existing modes to override for your full resolution mode is not something that can be decided from scanning the list; in my case, I found out by trial and error that overriding mode 5a worked fine, so my file /etc/default/915resolution contains


915resolution will be started automatically through /etc/init.d and will create a mode 5a at resolution 1400x1050, which works fine with X. Do not attempt to set a 24-bit depth in 915resolution for this chipset: it will appear to work, but will not be usable by X in 24-bit depth, only in 16-bit depth. By setting a 32-bit depth in 915resolution, you can then start your X driver in 24-bit depth without problem (although not in 32-bit depth, which is not supported by the X driver for this chipset). No idea why the discrepancy between X and the video BIOS, but it works, so I won't fret about it.

One big change to these remarks with the latest Xorg driver (xf86-video-intel, version 2.0.0 and higher, rather than the previous xf86-vide0-i810): it no longer has any problem with resolution and makes use of the 915resolution package unnecessary.

Note that Debian will want to install Xorg, not XFree86. I have found that XFree86 is easier to install and configure; and it is *much* easier to update when you want it compiled from sources -- you just download the latest XFree86 snapshot, untar it, compile it, and install it. This has not failed me even once in many years on dozens of machines, whereas trying to compile Xorg from source (whether from the huge list of tar files or from the git repository) is a nearly hopeless endeavor. For all that, I currently run Xorg, because of display switching and modesetting issues, as noted above and further addressed below.

Finally, still on the issue of the X software suite, you will need to check that your setup supports direct rendering. For that, you may need to download and compile the latest drm and mesa libraries (I did) and they will not compile well against the XFree86 source -- they are meant to be compiled against the Xorg source. You only need direct rendering for GL graphics, of course, so whether to go to that trouble is up to you -- both XFree86 and Xorg will work fine without. (One last note: glxinfo may still tell you that you do not have direct rendering when in fact you do have it -- such is the case for me; use a GL graphics app, such as one of the standard tux games -- ppracer, tuxkart, etc., to test your rendering: if it's reasonably smooth, you have DRI, if it's ridiculously chopped up, you do not.)

The second issue is brightness control, through the hotkeys. For that, see the hotkeys section below: it can be done easily.

The last issue is switching between laptop screen and external monitor or projector. The hotkeys package will enable you to get the key with the switching icon (F3) detected, and the i810switch package should, theoretically, be able to support the switch, but so far I have not been able to get the switching working -- and there are resolution issues as well.

Some notes on this. The BIOS settings are dumb: you can enable the local display or an external monitor on them, but not both; if you set it on external monitor, it will use it (alone) if detected at boot time, otherwise it will use the LCD screen. If you want both external and laptop screens to work at the same time, you must rely on X to do it -- for instance, if you set the option MonitorLayout to "CRT+LFP,LFP" in the X config file, your X driver will "see" the connected projector or external monitor and will get its characteristics. However, note that the current 810/915 driver does not do modesetting (hence the need for 915resolution above), and so it is not able to alter the resolution for the typically lower-resolution projector (or typically higher-resolution monitor) that is connected -- the feed to the connected display will be the same resolution as that set to start with. So you have to rerun 915resolution to change the mode, then start X. This is quite annoying: you'd really just want to get X to reduce resolution through the usual Ctrl-Alt-(-), so as not to have to change all your settings. The latest Xorg xf86-video-intel is modesetting, however, so it may solve this issue -- stay tuned.


In order for these to work, you will need the excellent PCC-ACPI package. Get it from
along with the handler and utilities. (Use the driver package in preference to the kernel patches: the patches are a few versions behind and do not seem to work very well, unlike the driver.) You compile the driver into a kernel module and edit your /etc/modules file to load the module automatically. Note that earlier versions of this package would not compile against a 2.6.18 or later kernel, so be sure to get the 0.9 or later release. The keys are now enabled and you just need scripts to handle brightness and sound. For sound, I use lineak (available as a Debian package from the Debian servers) driving the amixer command. For brightness, you need to alter the handler script, which was written for another laptop (a single increment in that script immediately switches the CF-Y5 from totally dark to maximum brightness). I modified a script found on the web to alter brightness by the minimum increment as follows:


grep -q off-line /proc/acpi/ac_adapter/*/state
if [ $? = 0 ]

BRIGHTNESS=$(( `cat /proc/acpi/pcc/$INTERFACE` + 0 ))
MAXBRIGHT=$(( `cat /proc/acpi/pcc/"$INTERFACE"_max` - $SPAN))
MINBRIGHT=$(( `cat /proc/acpi/pcc/"$INTERFACE"_min` + $SPAN))

if [ "x$1" = "xdown" ]; then
   if [ $BRIGHTNESS -gt $MINBRIGHT ]; then
   echo $BRIGHTNESS > /proc/acpi/pcc/$INTERFACE
elif [ "x$1" = "xup" ]; then
   if [ $BRIGHTNESS -lt $MAXBRIGHT ]; then
   echo $BRIGHTNESS > /proc/acpi/pcc/$INTERFACE
   echo >&2 Unknown argument $1


The generic kernel on your installation CD has the driver (8139too). Compile it into your new kernel.


Nothing to do here, other than make sure that your new kernel has support for SCSI and USB.


Make sure your new kernel has support for input events and that your X configuration file includes the synaptics module. Works fine; if you use circular scrolling (recommended), remember that you will be scrolling (even after lifting your finger) anywhere close to the edge of the pad.


The sound driver is "Intel High Definition" (HDA); the actual chip is a Sigmatel 9200. I am using ALSA, naturally, for the sound system. The HDA driver (starting with ALSA 1.0.13) works without trouble for the headphones speakers and interacts fine with the usual mixers, but does not work for the speakers in every version (curiously, ALSA 1.0.11 and 1.0.12rc2 had the reverse behavior: speakers worked fine, but headphones required a small patch). Sound works out of the box for both speakers and headphones under kernel 2.6.20-rc5, but 2.6.20 only gives me headphones. Note that getting the speakers working is nearly useless: they are tinny little things you do not really want to hear anyway -- if you want sound, use headphones!

There is a report for the related CF-R5 that the HDA driver should be set up as a module so it can be unloaded in order to get the machine to sleep and wake up properly; I have not verified the necessity, but my HDA subsystem is compiled as modules.


Go to the IPW 3945 project page at SourceForge and follow the instructions: it works just fine (but you need version 1.1.0-rc1 or better, otherwise you may have compilation problems). Just ignore warning messages from the compiler. (The Debian unstable distribution now includes all three ipw3945 pieces---daemon, binary, and driver source, but I find it much easier to install from the Sourceforge files.) In the current setup, the 3945 driver is automatically loaded as a module and the daemon started. However, this particular driver does not automatically associate the wireless device with a signal source: you have to do it "by hand" either through a configuration file or by running an "iwlist scan" to get the ESSID and then using iwconfig to create the association.


Works out of the box (use the Yenta driver for your new kernel).

There is a report for the related CF-R5 that the PCMCIA driver should be set up as a module so it can be unloaded in order to get the machine to sleep and wake up properly; I have not verified the necessity, but my PCMCIA subsystem is compiled as modules.

SD Card

The latest kernels have a driver for SD cards that works on many platforms. Enable it -- seems to work fine here with an SD card from my camera, but it's not something I anticipate using much, so I did not test it beyond this one proof of concept.


Did this just for completeness -- have not used one of those in over 4 years... The sl-modem suite ( works fine; it detects the HDA driver and sets up a device for the modem, loading the slamr module. There is a Debian package for sl-modem, but you should download the source from the URL above, as it is more up-to-date and handles HDA properly.

Final Notes

I have observed a stray line under X (which is about 2/3 of the way down the screen, starting 1/3 of the way along the horizontal and wrapping around on the pixel line below) that is misaddressed in the video buffer (it mirrors pixels from another part of the screen) after one of two manipulations: sleeping to memory and waking up; or switching to external monitor, either from the BIOS setting (use external monitor if present) or from restarting X with an external monitor connected. I thought that this might be a hardware glitch in the video system on my machine, since it is not consistenly reproducible, but there is a report on the Intel i8xx/i9xx graphics driver site ( of a similar observation on a BenQ Joybook S61 (also 945M chipset) running under Ubuntu. So there could be some subtle bug in the i9xx chip family or (more likely) in the i9xx driver.

With the latest driver, xf86-video-intel (as opposed to xf86-video-i810 in any flavor), that artifact no longer occurs, although I get issues of distortions when resuming from sleep-to-memory.

Finally, I have now had this machine since late July 2006 -- a bit over 9 months -- and have used it several hours every day. It is by far the best combination of portability, durability, and screen resolution I have found so far -- and I've had everything from 2lbs subnotebooks to 10lbs 17" luggable (not really portable) workstations (the great Dell M90, for instance). I could wish for it to be 16:9 rather than 4:3 -- i.e., to have it 1680x1050 instead of 1400x1050 -- and to have an NVIDIA graphics system rather than the problematic i945GM; I prefer the glossy "TrueLife" displays to the matte nonreflective ones as used on this machine (the glossy ones have much better contrast, even outdoors); and I would prefer for the power button not to be so brightly lit when the machine is on or in sleep-to-memory mode (as bright as a typical nightlight). But these are minor quibbles: in today's market, the overall package cannot be beat.