The Smell of Molten Projects in the Morning

Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.

Category: PC Tweakage

Remembering which tweaks worked

  • New 1.5 TB USB Backup Drive

    Just got a new 1.5 TB USB drive (Western Digital Elements; every manufacturer has produced horror stores) for $85 delivered; I do not understand the economics of that business in the least. Anyway, this will become the external drive onto which the rsnapshot routine dumps the daily changes from the file server; the old 500 GB drive was 99% full, so it’s time to tuck that one in the fireproof safe.

    The NTFS partition had some weird-ass peculiarities that choked cfdisk, so I used parted to blow away the NTFS type=7 partition and create a new Linux type-83 partition. Strangely, the drive came with no shovelware, for which I’m grateful.

    sudo fdisk /dev/sde
Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-182401, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-182401, default 182401):
Using default value 182401
Command (m for help): w
The partition table has been altered!

    Then build an ext3 filesystem:

    sudo mke2fs -j -m 0 -L 'Backup-1.5TB' -O sparse_super /dev/sde1

    The sparse_super option seems to make sense; if the drive fails to the point where you must go rummaging for more than one spare superblock, you’re probably not going to find any of them.

    Turns out you really should unplug / replug a USB drive after walloping its partition table. Took me a while to figure that out. Again. You’d think I’d remember.

    Then you find the partitions’s new UUID using any of:

    ll /dev/disk/by-uuid/
vol_id /dev/sde1

    Then plug the UUID into fstab so the rsnapshot routine can mount the drive regardless of which device it wakes up as on any given day:

    UUID=77c75554-26a0-4bbc-a452-201c2150bf1a  /mnt/backup ext2 defaults,noatime,noauto,nodev,noexec,nosuid 0 0

    More on that from the last go-round there.

    The first backup took about six hours to copy 430-some-odd GB of data from the internal SATA drive. Call it almost exactly 20 MB/s; such a nice round number surely means a drive-limited data rate.

    Incidentally, if you need a shiny new UUID for some reason, uuidgen is your friend.

    Memo to Self: Just unplug the [mumble] drive.

  • Kensington Expert Mouse Trackball vs X Server 1.8

    After the fuffing and fawing required to get the Wacom tablet up to speed, swapping the buttons on the Kensington trackball required just one stanza in /etc/X11/xorg.conf.

    To wit:

    Section "InputClass"
Identifier      "Kensington Trackball"
MatchProduct    "Kensington Expert Mouse"
Option          "SendCoreEvents" "True"
Option          "ButtonMapping" "3 8 1 4 5 6 7 2"
EndSection

    For some no-doubt logical reason, it Just Works without an InputDevice stanza or anything in ServerLayout.

    That will swap the buttons on any matching trackball, should I be so bold as to plug more than one in at a time …

    The old FDI file is there.

  • Wacom Graphire3 vs X Server 1.8

    A recent Arch Linux update introduced Version 1.8.1 of the X server, which jettisons the whole HAL infrastructure in favor of udev. This is almost certainly a step in the right direction, but once again it’s time to figure out exactly how to get my Wacom Graphire3 tablet running.

    The solution turns out to be putting all the configuration options back in /etc/X11/xorg.conf, exactly where they started out before they moved into HAL FDI files. Not that any of this is obvious, mind you, but that’s how it works out.

    So.

    At this point, the Arch Linux linuxwacom-bamboo-cth-ctl package installs the only Wacom driver version (0.10.7-4) that works with X 1.8+.

    In /etc/udev/rules.d/10-wacom.rules the two highlighted lines match the Graphire and throw the evdev driver overboard if it got control. The top line was the original file; I commented it out and inserted the rest based on a thread in the Arch wiki; I think the original would work fine.

    ###KERNEL=="event*", ID_VENDOR_ID=="056a", NAME="input/%k", SYMLINK="input/wacom"
# udev rules for wacom tablets.

KERNEL!="event[0-9]*", GOTO="wacom_end"

# Multiple interface support for stylus and touch devices.
DRIVERS=="wacom", ATTRS{bInterfaceNumber}=="00", ENV{WACOM_TYPE}="stylus"
DRIVERS=="wacom", ATTRS{bInterfaceNumber}=="01", ENV{WACOM_TYPE}="touch"

# Convenience links for the common case of a single tablet.  We could do just this:
#ATTRS{idVendor}=="056a", SYMLINK+="input/wacom-$env{WACOM_TYPE}"
# but for legacy reasons, we keep the input/wacom link as the generic stylus device.
ATTRS{idVendor}=="056a", ENV{WACOM_TYPE}!="touch", SYMLINK+="input/wacom"
ATTRS{idVendor}=="056a", ENV{WACOM_TYPE}=="touch", SYMLINK+="input/wacom-touch"

# Check and repossess the device if a module other than the wacom one
# is already bound to it.
ATTRS{idVendor}=="056a", ACTION=="add", RUN+="check_driver wacom $devpath $env{ID_BUS}"

LABEL="wacom_end"

    When X wakes up, it stitches together a bazillion snippets of config options that used to live in /etc/X11/xorg.conf. This default snippet in /etc/X11/xorg.conf/50-wacom.conf seems to be OK, although only the highlighted stuff applies to my setup.

    Section "InputClass"
	Identifier "Wacom class"
# WALTOP needs a patched kernel driver, that isn't in mainline lk yet,
# so for now just let it fall through and be picked up by evdev instead.
#	MatchProduct "Wacom|WALTOP|WACOM"
	MatchProduct "Wacom|WACOM"
	MatchDevicePath "/dev/input/event*"
	Driver "wacom"
EndSection

... snippage ...

    Meanwhile, back in /etc/X11/xorg.conf, the tablet requires two InputDevice stanzas and their corresponding ServerLayout entries.

    Section "ServerLayout"
    Identifier     "RotatedPortrait"
    Screen      0  "Landscape" 0 0
    Screen      1  "Portrait" RightOf "Landscape"
    InputDevice     "Wacom - stylus"
    InputDevice     "Wacom - eraser"
EndSection

Section "InputDevice"
    Identifier      "Wacom - stylus"
    Driver          "wacom"
    Option          "Device" "/dev/input/wacom"
    Option          "USB" "on"
    Option          "Type" "stylus"
    Option          "Button2" "3"
    Option          "Button3" "2"
    Option          "MMonitor" "off"
    Option          "ScreenNo" "0"
    Option          "BottomX" "16725"
    Option          "BottomY" "11893"
EndSection

Section "InputDevice"
    Identifier      "Wacom - eraser"
    Option          "Device" "/dev/input/wacom"
    Driver          "wacom"
    Option          "USB" "on"
    Option          "Type" "eraser"
    Option          "MMonitor" "off"
    Option          "ScreenNo" "0"
    Option          "BottomX" "16725"
    Option          "BottomY" "11893"
EndSection

    I haven’t checked to see if the driver still requires the BottomX / BottomY values to keep the cursor from crashing X when it enters the crack between the displays.

    Most of that is documented in the man pages for xorg.conf and wacom.

    The corresponding FDI file for the previous X Server is there, just in case you want to compare notes.

  • Epson R380 Printer: Resetting the Waste Ink Counters

    So a few days after topping off the continuous ink tanks on my Epson R380 printer, we had a series of thunderstorms that prompted me to turn everything off. Upon turning the printer back on, its fancy LCD panel showed a message along the lines of

    Service is required. Contact Epson Customer Service.

    Oddly, it continued to print perfectly with no further complaints. The error message appeared only at power-on, then politely went away when I pressed the OK button.

    Well, that puppy is long out of warranty, even if I wasn’t using a continuous ink system, soooo… what to do? The printer produces absolutely no diagnostic codes other than that error message.

    A bit of searching gave me the Maintenance Manual for that family of printers. That message isn’t among the ones listed.

    Further searching suggests that at least one of the two waste ink pads / tanks is nearly full and that ignoring the problem will cause the printer to shut itself down, lest it dribble ink. The listed messages warn that the printer is approaching the “end of its service life”, which isn’t the message I saw, but it’s close enough.

    The Maintenance Manual suggests that it’ll be cheaper and better to simply buy a new printer, as replacing the waste ink tanks may cost more than the printer is worth. The website points out that providing a customer-replaceable tank would drive up the cost of the printer, because most customers would buy a new printer before filling the tank.

    In order to get to the waste ink tank, you must remove:

    • Paper Support
    • Printer Cover
    • Front Cover
    • Right Housing
    • Left Housing
    • USB Housing
    • Upper Housing
    • Panel Unit
    • EMI Frame

    I can see why it might take a trained tech a few hours to get all that done… and then reassemble in reverse order.

    The Epson website has a link to a program that will reset the waste ink counters for one of the tanks. Downloaded & ran it on the Token Windows Laptop; it tells me there’s no problem.

    Hmmm…

    So I ordered an external waste ink tank from the usual eBay supplier. The hardware is grossly overpriced ($20 delivered) for what it is (large tube with sealed endcaps, some tubing & barb fittings, a syringe), but the deal includes links to programs that will reset the counters. I found several of those programs by myself, so it’s not as if you must actually spend money to reset the printer’s counters. I figured this was in the nature of a learning experience.

    Turns out that the programs are provided by parties having, shall we say, long-term interests that may not coincide with mine. To wit, I’d be batshit crazy to run those programs on a PC I cared about.

    [Update: Something like that.]

    The various program files all passed a ClamAV virus scan, but that doesn’t mean anything these days.

    So, during the next hour:

    • Boot System Rescue CD on my oldest Token Windows Laptop
    • Run partimage to back up the Windows partition to another partition
    • Disconnect from the house LAN
    • Reboot in Windows, which evidently hasn’t seen the light of day in about a year
    • Stifle bleating requests for updates
    • Copy the programs from a USB stick, install as needed
    • Reset one of the ink counters (more on this below)
    • Reboot in SRC
    • Restore the partition from the backup

    All that is straightforward and I’ve written about it earlier. Search the blog for more info using the obvious keywords.

    I attempted to restore the drive’s Master Boot Record from the partition backup file, but partimage complained that the drive size in the backed-up MBR did not match the existing drive size, which suggests something tinkered with the drive’s MBR between the backup and the restore.

    Hmmm….

    You might want to do a bit of reading on Boot Sector Viruses at this point. I have no other evidence to suggest that’s what’s going on, other than to remind you that programs need not do only what they say they’ll do.

    Given all that, I figured this was a great time to update the Token Windows Laptop to Xubuntu 10.04, which installed Grub2 in the MBR and wiped away anything placed therein. The box is heavily multi-booted: Dell Diags, XP, Puppy, and now Xubuntu 10.04.

    Without naming names or providing links:

    • The Russian program seems to not include the R380, but it does include others in that family. I elected to not reset the counters using that program.
    • The Chinese program seems to be a bootleg copy of the Official Epson Adjustment Program, although it’s rife with misspellings and grammatical errors. I told it to reset the “Main Pad” counter and give me a dump of the EEPROM.

    The Main Pad had 16008 counts of the maximum 16200, while the Platen Pad had only 3019 of 54513. Those names do not correspond to anything in the Maintenance Manual, but I suspect the Main Pad is the Waste Ink Tray at the head-cleaning station and the Platen Pad is the Waste Ink Pad running across the printer to catch the overspray from borderless prints.

    Resetting the Main Pad counter to zero cleared the error message; the printer is perfectly happy now. I’ll install the external waste ink tank when I clear the workbench after building the next GPS interface for our HTs.

    The program reported 9922 pages printed. Figuring 7 bottles of ink at 250 ml each, that’s 0.18 ml per page. That’s a slight overestimate because the ≈50 ml tanks were just topped off, but it’s close enough. I’m guessing head cleaning consumed much of that ink, as the printer does plenty of that, and the number of pages seems close to half the number of counts.

    Perhaps it performs a cleaning when more than X minutes has elapsed since the previous print job? That would account for the high number of cleanings; most print jobs are a few pages, at most.

    En passant, I found some totally unofficial ink cartridge capacity numbers:

    • Standard T078x: 7 ml @ $13 = $1857 / liter
    • Large T077x: 11 ml @ $20 = $1818 / liter

    [Update: corrected typo from ml to liter]

    Ain’t that impressive? I love the savings they give you with higher-capacity cartridges …

  • Turning Off Gnome Desktop Tooltips

    This probably isn’t applicable to the Latest and Greatest, but for the Ubuntu 8.04 version used by EMC…

    gconftool -s --type=bool /apps/panel/global/tooltips -enabled false

  • XFCE vs Evolution vs Gnome Keyring

    So I thought I’d try Evolution, the Gnome email / calendar / messaging Borganism, which can allegedly support maildir files. Installation went swimmingly, but (at least at first glance) it can’t. More on this later.

    Evolution uses the Gnome keyring to store passwords, which is (of course) different from and incompatible with the KDE keyring. The principle seems to be that when you sign on / log in / whatever, the Gnome keyring’s login keyring automagically unlocks, giving Evolution access to the POP3 password used for your ISP. Except that didn’t work; Evolution uses the default keyring, not the login keyring.

    Evolution / Gnome evidently creates a default keyring entry by scraping up a password from somewhere unknown to me. The only way to clear it, at least in XFCE, without installing the entire mumble Gnome desktop, is to simply delete the keyring file… at which point, the keyring manager will ask you for a password and recreate the file.

    rm ~/.gnome2/keyrings/*

  • Arch Linux: Downgrading Clipman

    Come to find out that the new cut-n-paste handler in Inkscape 0.47 collides mightily with (among other things) Clipman 1.1.3, the xfce4 clipboard manager, as mentioned in bugs 487653 and 418242.

    Seeing as how I depend on  Clipman, the least-disruptive course of action seems to be downgrading it to 1.1.1, which required some fiddling with the Arch Build System.

    I have a build tree set up in /var/abs/local, so…

    cd /var/abs/local
cp -r /var/abs/extra/xfce4-clipman-plugin/ .
cd xfce4-clipman-plugin

    The PKGBUILD file tells us that source tarballs are available at

    source=(http://archive.xfce.org/src/panel-plugins/${pkgname}/1.1/${pkgname}-${pkgver}.tar.bz2)
md5sums=('2ba70c6bd710e2a18cba5add66d297dc')

    Go there, get the md5 sum for the 1.1.1 package, then edit the PKGBUILD to suit:

    pkgver=1.1.1
... snippage ...
md5sums=('0884207cabd3a3a94c86b919bbf1617b')

    Remove the existing package, build & install the new / old one:

    sudo packman -R xfce4-clipman-plugin
makepkg -s
sudo pacman -U xfce4-clipman-plugin-1.1.1-1-i686.pkg.tar.xz

    Then edit /etc/pacman.conf to ensure Clipman remains obsolete:

    IgnorePkg   = xfce4-clipman-plugin

    Restart the panels:

    xfce4-panel -r

    And it seems to work just fine…

    Doc for this is pretty good: building custom ABS packages and downgrading packages. The trick was finding the backlevel versions, which stumped me until I dug into the PKGBUILD file.

    It’s worth nothing that this conflict isn’t unique to Arch Linux: the same problem is affecting other distros, too. What is unique to Arch is that it’ll distribute the fix earlier than anybody else, too, because as soon as the upstream versions change, they’re in the Arch repositories.

    Memo to Self: remember to un-wedge Clipman when Inkscape gets its act together. Fortunately, pacman reports which packages it’s ignoring.