ThinkPad X250 on CentOS 7

Wow, almost a year since the last post. Definitely time to reboot the blog.

Got to replace my aging ThinkPad X201 with a lovely shiny new ThinkPad X250 over the weekend. Specs are:

  • CPU: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz
  • RAM: 16GB PC3-12800 DDR3L SDRAM 1600MHz SODIMM
  • Disk: 256GB SSD (swapped out for existing Samsung SSD)
  • Display: 12.5" 1920x1080 IPS display, 400nit, non-touch
  • Graphics: Intel Graphics 5500
  • Wireless: Intel 7265 AC/B/G/N Dual Band Wireless and Bluetooth 4.0
  • Batteries: 1 3-cell internal, 1 6-cell hot-swappable

A very nice piece of kit!

Just wanted to document what works and what doesn't (so far) on my standard OS, CentOS 7, with RH kernel 3.10.0-229.11.1. I had to install the following additional packages:

  • iwl7265-firmware (for wireless support)
  • acpid (for the media buttons)

Working so far:

  • media buttons (Fn + F1/mute, F2/softer, F3/louder - see below for configuration)
  • wifi button (Fn + F8 - worked out of the box)
  • keyboard backlight (Fn + space, out of the box)
  • sleep/resume (out of the box)
  • touchpad hard buttons (see below)
  • touchpad soft buttons (out of the box)

Not working / unconfigured so far:

  • brightness buttons (Fn + F5/F6)
  • fingerprint reader (supposedly works with fprintd)

Not working / no ACPI codes:

  • mute microphone button (Fn + F4)
  • application buttons (Fn + F9-F12)

Uncertain/not tested yet:

  • switch video mode (Fn + F7)

To get the touchpad working I needed to use the "evdev" driver rather than the "Synaptics" one - I added the following as /etc/X11/xorg.conf.d/90-evdev.conf:

Section "InputClass"
  Identifier "Touchpad/TrackPoint"
  MatchProduct "PS/2 Synaptics TouchPad"
  MatchDriver "evdev"
  Option "EmulateWheel" "1"
  Option "EmulateWheelButton" "2"
  Option "Emulate3Buttons" "0"
  Option "XAxisMapping" "6 7"
  Option "YAxisMapping" "4 5"

This gives me 3 working hard buttons above the touchpad, including middle-mouse- button for paste.

To get fonts scaling properly I needed to add a monitor section as /etc/X11/xorg.conf.d/50-monitor.conf, specifically for the DisplaySize:

Section "Monitor"
  Identifier    "Monitor0"
  VendorName    "Lenovo ThinkPad"
  ModelName     "X250"
  DisplaySize   276 155
  Option        "DPMS"

and also set the dpi properly in my ~/.Xdefaults:

*.dpi: 177

This fixes font size nicely in Firefox/Chrome and terminals for me.

I also found my mouse movement was too slow, which I fixed with:

xinput set-prop 11 "Device Accel Constant Deceleration" 0.7

(which I put in my old-school ~/.xsession file).

Finally, getting the media keys involved installing acpid and setting up the appropriate magic in 3 files in /etc/acpid/events:

# /etc/acpi/events/volumedown
action=/etc/acpi/actions/ down

# /etc/acpi/events/volumeup
action=/etc/acpi/actions/ up

# /etc/acpi/events/volumemute
action=/etc/acpi/actions/ mute

Those files capture the ACPI events and handle them via a custom script in /etc/acpi/actions/, which uses amixer from alsa-utils. Volume control worked just fine, but muting was a real pain to get working correctly due to what seems like a bug in amixer - amixer -c1 sset Master playback toggle doesn't toggle correctly - it mutes fine, but then doesn't unmute all the channels it mutes!

I worked around it by figuring out the specific channels that sset Master was muting, and then handling them individually, but it's definitely not as clean:

# /etc/acpi/actions/ (must be executable)


die() {
  echo $*
  exit 1
usage() {
  die "usage: $(basename $0) up|down|mute"

test -n "$1" || usage


case $ACTION in
    amixer -q -c1 -M sset Master 5%+ unmute
    amixer -q -c1 -M sset Master 5%- unmute
    # Ideally the next command should work, but it doesn't unmute correctly
#   amixer -q -c1 sset Master playback toggle

    # Manual version for ThinkPad X250 channels
    # If adapting for another machine, 'amixer -C$DEV contents' is your friend (NOT 'scontents'!)
    SOUND_IS_OFF=$(amixer -c1 cget iface=MIXER,name='Master Playback Switch' | grep 'values=off')
    if [ -n "$SOUND_IS_OFF" ]; then
      amixer -q -c1 cset iface=MIXER,name='Master Playback Switch'    on
      amixer -q -c1 cset iface=MIXER,name='Headphone Playback Switch' on
      amixer -q -c1 cset iface=MIXER,name='Speaker Playback Switch'   on
      amixer -q -c1 cset iface=MIXER,name='Master Playback Switch'    off
      amixer -q -c1 cset iface=MIXER,name='Headphone Playback Switch' off
      amixer -q -c1 cset iface=MIXER,name='Speaker Playback Switch'   off

So in short, really pleased with the X250 so far - the screen is lovely, battery life seems great, I'm enjoying the keyboard, and most things have Just Worked or have been pretty easily configurable with CentOS. Happy camper!


Fujitsu ScanSnap 1300i on RHEL/CentOS

Just picked up a shiny new Fujitsu ScanSnap 1300i ADF scanner to get more serious about less paper.

Fujitsu ScanSnap 1300i

I chose the 1300i on the basis of the nice small form factor, and that SANE reports it having 'good' support with current SANE backends. I'd also been able to find success stories of other linux users getting the similar S1300 working okay:

Here's my experience getting the S1300i up and running on CentOS 6.

I had the following packages already installed on my CentOS 6 workstation, so I didn't need to install any new software:

  • sane-backends
  • sane-backends-libs
  • sane-frontends
  • xsane
  • gscan2pdf (from rpmforge)
  • gocr (from rpmforge)
  • tesseract (from my repo)

I plugged the S1300i in (via the dual USB cables instead of the power supply - nice!), turned it on (by opening the top cover) and then ran sudo sane-find-scanner. All good:

found USB scanner (vendor=0x04c5 [FUJITSU], product=0x128d [ScanSnap S1300i]) at libusb:001:013
# Your USB scanner was (probably) detected. It may or may not be supported by
# SANE. Try scanimage -L and read the backend's manpage.

Ran sudo scanimage -L - no scanner found.

I downloaded the S1300 firmware Luuk had provided in his post and installed it into /usr/share/sane/epjitsu, and then updated /etc/sane.d/epjitsu.conf to reference it:

# Fujitsu S1300i
firmware /usr/share/sane/epjitsu/1300_0C26.nal
usb 0x04c5 0x128d

Ran sudo scanimage -L - still no scanner found. Hmmm.

Rebooted into windows, downloaded the Fujitsu ScanSnap Manager package and installed it. Grubbed around in C:/Windows and found the following 4 firmware packages:

Copied the firmware onto another box, and rebooted back into linux. Copied the 4 new firmware files into /usr/share/sane/epjitsu and updated /etc/sane.d/epjitsu.conf to try the 1300i firmware:

# Fujitsu S1300i
firmware /usr/share/sane/epjitsu/1300i_0D12.nal
usb 0x04c5 0x128d

Close and re-open the S1300i (i.e. restart, just to be sure), and retried sudo scanimage -L. And lo, this time the scanner whirrs briefly and ... victory!

$ sudo scanimage -L
device 'epjitsu:libusb:001:014' is a FUJITSU ScanSnap S1300i scanner

I start gscan2pdf to try some scanning goodness. Eeerk: "No devices found". Hmmm. How about sudo gscan2pdf? Ahah, success - "FUJITSU ScanSnap S1300i" shows up in the Device dropdown.

I exit, and google how to deal with the permissions problem. Looks like the usb device gets created by udev as root:root 0664, and I need 'rw' permissions for scanning:

$ ls -l /dev/bus/usb/001/014
crw-rw-r--. 1 root root 189, 13 Sep 20 20:50 /dev/bus/usb/001/014

The fix is to add a scanner group and local udev rule to use that group when creating the device path:

# Add a scanner group (analagous to the existing lp, cdrom, tape, dialout groups)
$ sudo groupadd -r scanner
# Add myself to the scanner group
$ sudo useradd -aG scanner gavin
# Add a udev local rule for the S1300i
$ sudo vim /etc/udev/rules.d/99-local.rules
# Added:
# Fujitsu ScanSnap S1300i
ATTRS{idVendor}=="04c5", ATTRS{idProduct}=="128d", MODE="0664", GROUP="scanner", ENV{libsane_matched}="yes"

Then logout and log back in to pickup the change in groups, and close and re-open the S1300i. If all is well, I'm now in the scanner group and can control the scanner sans sudo:

# Check I'm in the scanner group now
$ id
uid=900(gavin) gid=100(users) groups=100(users),10(wheel),487(scanner)
# Check I can scanimage without sudo
$ scanimage -L
device 'epjitsu:libusb:001:016' is a FUJITSU ScanSnap S1300i scanner
# Confirm the permissions on the udev path (adjusted to match the new libusb path)
$ ls -l /dev/bus/usb/001/016
crw-rw-r--. 1 root scanner 189, 15 Sep 20 21:30 /dev/bus/usb/001/016
# Success!

Try gscan2pdf again, and this time it works fine without sudo!

And so far gscan2pdf 1.2.5 seems to work pretty nicely. It handles both simplex and duplex scans, and both the cleanup phase (using unpaper) and the OCR phase (with either gocr or tesseract) work without problems. tesseract seems to perform markedly better than gocr so far, as seems pretty typical.

So thus far I'm a pretty happy purchaser. On to a paperless searchable future!

The New Car Stereo

Bought a new car stereo a few weeks ago to replace the broken CD-stacker that came with our Ford Fairmont.

In researching the options it seemed that the mainstream choices these days were for stereos with auxiliary-in jacks at the front, so you could plug your music player in, and/or units that would play mp3s. Turns out that latter option means they will play mp3s that you've burned onto CDs, not off something super-high-tech like a memory stick. Hmmm.

Well, that's not quite true. Newer units are starting to appear with USB slots that will play music off a USB memory stick, so there are actually starting to be some useful options available. I didn't see any that took anything like compact flash or SD cards however.

They also don't seem to know anything much about codecs except MP3, WMA, WAV, and some AAC. Being the open source geek that I am, I was keen to get something that supported ogg vorbis, but I could not find any information (including with my google-fu) on models that might support this. I did find one guy, however, who'd burnt a bunch of tracks in different formats to a CD and then just gone down and tried out all the units at his local hi-fi store. That sounded like a plan!

So I ended up testing a bunch of units at my local JB Hi-Fi and Strathfield stores, and the good news is that about half of them actually played ogg vorbis just fine. I guess they're just using stock sound decoder chips, which these support a whole bunch of codecs out of the box. Sure would be nice if they could manage to advertise the codecs they actually support though.

We ended up going with a Kenwood KDC-MP4036U, which advertises support for "MP3/WMA/AAC Files", but plays at least ogg vorbis just fine as well. It's supposedly AU$429 RRP, but we picked it up for $180 at the big post-Christmas sale at Strathfield, so clearly it pays to shop around.

So far it's working really nicely - I've got most of the girls' music and stories on a 4GB USB stick and get them to drive the music selection from the back using the remote control. Way more music than 6-CDs ever gave us, and without the hassle of a separate music player or ipod.

All is good in the car again!

Rant: How To Not Sell Stuff

Today I've been reminded that while the web revolution continues apace - witness Web 2.0, ajax, mashups, RESTful web services, etc. - much of the web hasn't yet made it to Web 1.0, let alone Web 2.0.

Take ecommerce.

One of this afternoon's tasks was this: order some graphics cards for a batch of workstations. We had a pretty good idea of the kind of cards we wanted - PCIe Nvidia 8600GT-based cards. The unusual twist today was this: ideally we wanted ones that would only take up a single PCIe slot, so we could use them okay even if the neighbouring slot was filled i.e.

select * from graphics_cards
where chipset_vendor = 'nvidia'
and chipset = '8600GT'
order by width desc;

or something. Note that we don't even really care much about price. We just need some retailer to expose the data on their cards in a useful sortable fashion, and they would get our order.

In practice, this is Mission Impossible.

Mostly, merchants will just allow me to drill down to their graphics cards page and browse the gazillion cards they have available. If I'm lucky, I'll be able to get a view that only includes Nvidia PCIe cards. If I'm very lucky, I might even be able to drill down to only 8000-series cards, or even 8600GTs.

Some merchants also allow ordering on certain columns, which is actually pretty useful when you're buying on price. But none seem to expose RAM or clockspeeds in list view, let alone card dimensions.

And even when I manually drill down to the cards themselves, very few have much useful information there. I did find two sites that actually quoted the physical dimensions for some cards, but the in both cases the numbers they were quoting seemed bogus.

Okay, so how about we try and figure it out from the manufacturer's websites?

This turns out to be Mission Impossible II. The manufacturer's websites are all controlled by their marketing departments and largely consist of flash demos and brochureware. Even finding a particular card is an impressive feat, even if you have the merchant's approximation of its name. And when you do they often have less information than the retailers'. If there is any significant data available for a card, it's usually in a pdf datasheet or a manual, rather than available on a webpage.


So here are a few free suggestions for all and sundry, born out of today's frustration.

For manufacturers:

  • use part numbers - all products need a unique identifier, like books have an ISBN. That means I don't have to try and guess whether your 'SoFast HyperFlapdoodle 8600GT' is the same things as the random mislabel the merchant put on it.

  • provide a standard url for getting to a product page given your part number. I know, that's pretty revolutionary, but maybe take a few tips from google instead of just listening to your marketing department e.g.

  • keep old product pages around, since people don't just buy your latest and greatest, and products take a long time to clear in some parts of the world

  • include some data on your product pages, rather than just your brochureware. Put it way down the bottom of the page so your marketing people don't complain as much. For bonus points, mark it up with semantic microformat-type classes to make parsing easier.

  • alternatively, provide dedicated data product pages, perhaps in xml, optimised for machine use rather than marketing. They don't even have to be visible via browse paths, just available via search urls given product ids.

For merchants:

  • include manufacturer's part numbers, even if you want to use your own as the primary key. It's good to let your customers get additional information from the manufacturer, of course.

  • provide links at least to the manufacturer's home page, and ideally to individual product pages

  • invest in your web interface, particularly in terms of filtering results. If you have 5 items that are going to meet my requirements, I want to be able to filter down to exactly and only those five, instead of having to hunt for them among 50. Price is usually an important determiner of shopping decisions, of course, but if I have two merchants with similar pricing, one of whom let me find exactly the target set I was interested in, guess who I'm going to buy from?

  • do provide as much data as possible as conveniently as possible for shopping aggregators, particularly product information and stock levels. People will build useful interfaces on top of your data if you let them, and will send traffic your way for free. Pricing is important, but it's only one piece of the equation.

  • simple and useful beats pretty and painful - in particular, don't use frames, since they break lots of standard web magic like bookmarking and back buttons; don't do things like magic javascript links that don't work in standard browser fashion; and don't open content in new windows for me - I can do that myself

  • actively solicit feedback from your customers - very few people will give you feedback unless you make it very clear you welcome and appreciate it, and when you get it, take it seriously

End of rant.

So tell me, are there any clueful manufacturers and merchants out there? I don't like just hurling brickbats ...

Using Network Driver Images on RedHat/CentOS Installs

I was building a shiny new CentOS 5.0 server today with a very nice 3ware 9650SE raid card.

Problem #1: the RedHat anaconda installer kernel doesn't support these cards yet, so no hard drives were detected.

If you are dealing with a clueful Linux vendor like 3ware, though, you can just go to their comprehensive download driver page, grab the right driver you need for your kernel, drop the files onto a floppy disk, and boot with a 'dd' (for 'driverdisk') kernel parameter i.e. type 'linux dd' at your boot prompt.

Problem #2: no floppy disks! So the choices were: actually exit the office and go and buy a floppy disk, or (since this was a kickstart anyway) figure out how to build and use a network driver image. Hmmm ...

Turns out the dd kernel parameter supports networked images out of the box. You just specify dd=http://..., dd=ftp://..., or dd=nfs://..., giving it the path to your driver image. So the only missing piece was putting the 3ware drivers onto a suitable disk image. I ended up doing the following:

# Decide what name you'll give to your image e.g.
mkdir /tmp/$DRIVER
cd /tmp/$DRIVER
# download your driver from wherever and save as $ (or whatever)
# e.g. wget -O $
#   though this doesn't work with 3ware, as you need to agree to their
#   licence agreement
# unpack your archive (assume zip here)
mkdir files
unzip -d files $
# download a suitable base image from somewhere
wget -O $DRIVER.img \
# mount your dos image
mkdir mnt
sudo mount $DRIVER.img mnt -o loop,rw
sudo cp files/* mnt
ls mnt
sudo umount mnt

Then you can just copy your $DRIVER.img somewhere web- or ftp- or nfs-accessible, and give it the appropriate url with your dd kernel parameter e.g.


Alternatives: here's an interesting post about how to this with USB keys as well, but I didn't end up going that way.

Fuzzy Displays and Dual NVIDIA 8xxx Cards

We've been chasing a problem recently with trying to use dual nvidia 8000-series cards with four displays. 7000-series cards work just fine (we're mostly using 7900GSs), but with 8000-series cards (mostly 8600GTs) we're seeing an intermittent problem with one of the displays (and only one) going badly 'fuzzy'. It's not a hardware problem because it moves displays and cables and cards.

Turns out it's an nvidia driver issue, and present on the latest 100.14.11 linux drivers. Lonni from nvidia got back to us saying:

This is a known bug ... it is specific to G8x GPUs ... The issue is still being investigated, and there is not currently a resolution timeframe.

So this is a heads-up for anyone trying to run dual 8000-series cards on linux and seeing this. And props to nvidia for getting back to us really quickly and acknowledging the problem. Hopefully there's a fix soonish so we can put these lovely cards to use.

Linux on Gigabyte GA-M59SLI-S5/S4 Motherboards

We've been having a bit of trouble with these motherboards under linux recently. The two S4/S5 variants are basically identical except that the S5 has two Gbit ethernet ports where the S4 has only one, and the S5 has a couple of extra SATA connections - we've been using both variants. We chose these boards primarily because we wanted AM2 boards with multiple PCIe 16x slots to use with multiple displays.

We're running on the latest BIOS, and have tested various kernels from 2.6.9 up to about 2.6.19 so far - all evidence the same the same problems. Note that these are much more likely to be BIOS bugs, we think, than kernel problems.

The problems we're seeing are:

  • kernel panics on boot due to apic problems - we can workaround by specifying a 'noapic' kernel parameter at boot time

  • problems with IRQ 7 - we get the following message in the messages log soon after boot:

    kernel: irq 7: nobody cared (try booting with the "irqpoll" option)
    kernel:  [<c044aacb>] __report_bad_irq+0x2b/0x69
    kernel:  [<c044acb8>] note_interrupt+0x1af/0x1e7
    kernel:  [<c05700ba>] usb_hcd_irq+0x23/0x50
    kernel:  [<c044a2ff>] handle_IRQ_event+0x23/0x49
    kernel:  [<c044a3d8>] __do_IRQ+0xb3/0xe8
    kernel:  [<c04063f4>] do_IRQ+0x93/0xae
    kernel:  [<c040492e>] common_interrupt+0x1a/0x20
    kernel:  [<c0402b98>] default_idle+0x0/0x59
    kernel:  [<c0402bc9>] default_idle+0x31/0x59
    kernel:  [<c0402c90>] cpu_idle+0x9f/0xb9
    kernel:  =======================
    kernel: handlers:
    kernel: [<c0570097>] (usb_hcd_irq+0x0/0x50)
    kernel: Disabling IRQ #7

    after which IRQ 7 is disabled and whatever device is using IRQ 7 seems to fail intermittently or just behave strangely (and "irqpoll" would just cause hangs early in the boot process).

This second problem has been pretty annoying, and hard to diagnose because it would affect different devices on different machines depending on what bios settings were on and what slots devices were in. I spent a lot of time chasing weird nvidia video card hangs which we were blaming on the binary nvidia kernel module, which turned out to be this interrupt problem.

Similarly, if it was the sound device that happened to get that interrupt, you'd just get choppy or garbled sound out of your sound device, when other machines would be working flawlessly.

So after much pain, we've even managed to come up with a workaround: it turns out that IRQ 7 is the traditional LPT port interrupt - if you ensure the parallel port is turned on in the bios (we were religiously turning it off as unused!) it will grab IRQ 7 for itself and all your IRQ problems just go away.

Hope that saves someone else some pain ...