Tue 06 Oct 2015
Tags: hardware, linux, rhel, centos
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"
EndSection
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"
EndSection
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
event=button/volumedown
action=/etc/acpi/actions/volume.sh down
# /etc/acpi/events/volumeup
event=button/volumeup
action=/etc/acpi/actions/volume.sh up
# /etc/acpi/events/volumemute
event=button/mute
action=/etc/acpi/actions/volume.sh mute
Those files capture the ACPI events and handle them via a custom script in
/etc/acpi/actions/volume.sh, 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:
#!/bin/sh
#
# /etc/acpi/actions/volume.sh (must be executable)
#
PATH=/usr/bin
die() {
echo $*
exit 1
}
usage() {
die "usage: $(basename $0) up|down|mute"
}
test -n "$1" || usage
ACTION=$1
shift
case $ACTION in
up)
amixer -q -c1 -M sset Master 5%+ unmute
;;
down)
amixer -q -c1 -M sset Master 5%- unmute
;;
mute)
# 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
else
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
fi
;;
*)
usage
;;
esac
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!
References:
Sun 21 Sep 2014
Tags: hardware, linux, scanning, rhel, centos, usb
Just picked up a shiny new Fujitsu ScanSnap 1300i ADF scanner to get
more serious about less paper.
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!
Sun 10 Feb 2008
Tags: hardware, mp3, ogg vorbis
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!
Thu 04 Oct 2007
Tags: web, rant, hardware
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.
Arrrghh!
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.
http://www.supervidio.com.tw/?q=sofast-hf-8600gt-256
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 ...
Thu 30 Aug 2007
Tags: linux, hardware, tips
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.
DRIVER=3ware-c5-x86_64
mkdir /tmp/$DRIVER
cd /tmp/$DRIVER
# download your driver from wherever and save as $DRIVER.zip (or whatever)
# e.g. wget -O $DRIVER.zip http://www.3ware.com/KB/article.aspx?id=15080
# 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 $DRIVER.zip
# download a suitable base image from somewhere
wget -O $DRIVER.img \
http://ftp.usf.edu/pub/freedos/files/distributions/1.0/fdboot.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.
dd=http://web/pub/3ware/3ware-c5-x86_64.img
Alternatives: here's an
interesting post
about how to this with USB keys as well, but I didn't end up going that way.
Tue 21 Aug 2007
Tags: linux, hardware
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.
Thu 09 Aug 2007
Tags: linux, hardware
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 ...