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

  • Adobe Reader Default Toolbar: FAIL

    Maybe I’m misusing Adobe Reader, but I’ve always thought of it as a program that displays PDF files. In my case, that means data sheets for various & sundry electronic parts: I carefully squirrel both PDFs and parts away, having learned that physical parts can outlast both datasheets and company websites.

    So I open quite a few PDFs that reside on my file server in the basement.

    With that in mind, what’s missing from this row of toolbar icons?

    Adobe Reader Default Toolbar
    Adobe Reader Default Toolbar

    Go ahead, take your time…

    Hint: the only active button lets you “start an Acrobat Connect meeting and share documents”.

    This has been true for the last few versions; the Official Ubuntu Linux Version seems to be stuck at 8.1-ish. Let’s jump ahead a bit, fetch 9.3 directly from the Adobe download page, and install it:

    Adobe Reader 9.3 Toolbar
    Adobe Reader 9.3 Toolbar

    Now I can not only “Share documents and collaborate live within PDF documents”, but also “Click to create PDF using Acrobat.com”.

    What I can’t do is open a PDF file from disk by just clicking a button. That rarely used function is relegated to the File pulldown menu and, for those of us who can touch-type fairly well, hidden behind the arcane Ctrl-O keyboard chord.

    Reconfiguring the toolbar is a few minutes of clickety-click action, but it seems odd to me that none of the focus group participants suggested putting an Open File button on the toolbar.

    Although I never ascribe to malice what can be explained by stupidity, this continuing design decision does seem to require forethought.

  • Xubuntu 9.10: Quasi-functional Kensington Trackball Configuration

    As mentioned there, Ubuntu prohibits having two mice with different handedness. Xubuntu enumerates the various mice and allows you to set their handedness separately.

    This file swaps the upper two buttons.

    The scroll ring operates intermittently. I no longer believe it’s a hardware problem, as I have two Kensington trackballs and both behave the same way. I’m guessing the evdev driver has trouble with button pushes from two devices, but that’s just a guess. Sometimes it works perfectly for hours on end, other times it jams up first thing in the morning. Restarting X helps, which indicates the hole isn’t in the trackball’s end of the boat.

    Here’s my /usr/share/hal/fdi/policy/20thirdparty/10-expertmouse.fdi file:

    
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
 <match key="input.product" string="Kensington      Kensington Expert Mouse">
 <append key="input.x11_options.ButtonMapping" type="string">3 8 1 4 5 6 7 2</merge>
 </match>
 </device>
</deviceinfo>

    [Update: made the code block cut-and-paste-able. Sorry ’bout that…]

  • Xubuntu 9.10: Barely Functional Wacom Tablet Configuration

    For some background on a single-monitor box, read that first. This file is for my dual-monitor setup, which introduces horrible problems: basically, this setup doesn’t really work.

    The MMonitor and ScreenNo values restrict the tablet to the left-hand X screen. Without those settings, things get really weird.

    But, with the X screen nailed down, the fundamental problem is that the tablet stylus cursor starts out restricted to just the upper-left part of the left-hand (landscape) monitor. The fraction of the screen seems somehow related to the aggregate total of the two monitors, but not in any numeric sense I can figure out.

    The fix for that is tweaking the BottomX and BottomY values so that the cursor can cover the entire screen. I used the wacomcpl utility to cut-and-try various numbers until I got something close. They are quite different than the tablet’s default values: 16700 and 12064.

    The values suggest that the driver expects the tablet to cover the entire range of coordinates for both monitors, but whether that’s with the right monitor rotated or not isn’t obvious. The numbers do not work out either way. Maybe it’s taking the outermost bounding box?

    It is not clear why this hocus-pocus works at all, as I thought those values were supposed to restrict the stylus cursor to specific locations of the tablet’s surface. Evidently they’re scaling factors.

    Note that this fdi file adds the names required by wacomcpl, without which nothing works.

    The GIMP is markedly unhappy with this arrangement. Mostly, the stylus works and provides pressure information, but none of the trackballs or the tablet can select fields within some (but not all) of the dialog boxes (like, for example, File->Save…). Only the keyboard Tab key can move between fields in that situation.

    The wacdump utility segfaults. This seems to be a known problem with Ubuntu 9.10, for reasons that aren’t clear.

    Sometimes, but not always, the stylus cursor has an offset: the visible cursor on the screen is a few inches up-and-right of the actual tool location that’s affecting the drawing. When this happens, tweaking the BottomX and BottomY values with wacomcpl sometimes restores proper operation; the ensuing values have no relation with anything I can understand.

    Much to my surprise, button remapping works perfectly: the front switch on the stylus is Button 3, the rear is Button 2. That means context menus pop up on the more easily reached switch. At least I think so.

    Basically, something that worked absolutely dependably and without much manual intervention in 8.10 has become completely, totally, and utterly dysfunctional in 9.10. I do not count this as progress.

    With all that in mind, here’s the /usr/share/hal/fdi/policy/20thirdparty/10-linuxwacom.fdi file…

    
<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
 <match key="info.product" string="Wacom Graphire3 6x8">
 <merge key="input.x11_driver" type="string">wacom</merge>
 <merge key="input.x11_options.Type" type="string">stylus</merge>
 <merge key="input.x11_options.Button2" type="string">3</merge>
 <merge key="input.x11_options.Button3" type="string">2</merge>
 <merge key="input.x11_options.MMonitor" type="string">off</merge>
 <merge key="input.x11_options.ScreenNo" type="string">0</merge>
 <merge key="input.x11_options.BottomX" type="string">8146</merge>
 <merge key="input.x11_options.BottomY" type="string">11893</merge>
 <append key="info.callouts.add" type="strlist">hal-setup-wacom</append>
 <append key="wacom.types" type="strlist">eraser</append>
 <append key="wacom.types" type="strlist">cursor</append>
 </match>
 </device>
 <!-- Wacom names "parser" -->
 <device>
 <match key="info.udi" contains_not="subdev_0">
 <match key="info.udi" contains_not="subdev_1">
 <match key="info.udi" contains_not="subdev_2">
 <match key="input.x11_options.Type" contains="stylus">
 <merge key="info.product" type="string">stylus</merge>
 </match>
 <match key="input.x11_options.Type" contains="eraser">
 <merge key="info.product" type="string">eraser</merge>
 <merge key="input.x11_options.MMonitor" type="string">off</merge>
 <merge key="input.x11_options.ScreenNo" type="string">0</merge>
 <merge key="input.x11_options.BottomX" type="string">8146</merge>
 <merge key="input.x11_options.BottomY" type="string">11893</merge>
 </match>
 <match key="input.x11_options.Type" contains="cursor">
 <merge key="info.product" type="string">cursor</merge>
 </match>
 </match>
 </match>
 </match>
 </device>
</deviceinfo>

  • Xubuntu 9.10: Functional xorg.conf

    After considerable thrashing, this hand-tweaked version of /etc/X11/xorg.conf seems to do what’s needed for Xubuntu 9.10. It includes only display setup stuff; all the input device configuration is now tucked away in HAL FDI files.

    I used the nvidia-settings control panel to create a basic xorg.conf file that used separate X sessions, saved it in my home directory, then tweaked it in small increments until everything worked. Or, more precisely, until things stopped failing…

    Some observations:

    • Obviously, this uses the proprietary nVidia driver
    • The option Rotate CCW line must be commented out (or omitted) to avoid killing xrandr, because many utilities expect xrandr
    • Use the Xubuntu display setup applet to apply the xrandr rotation; just specify Screen 2 as rotated left
    • X locks up occasionally when Wacom tablet cursor falls into the seam between the displays. Make sure you can ssh into the box to restart X: an X crash kills the keyboard, too!
    • Metamodes must specify the exact monitor resolution
    • The nVidia logo doesn’t appear on either monitor during boot, even with NoLogo turned off. I like the logo, because it gives an early heads-up when something goes wrong.

    The xorg.conf file:

    
Section "ServerLayout"
 Identifier     "RotatedPortrait"
 Screen      0  "Landscape" 0 0
 Screen      1  "Portrait" RightOf "Landscape"
EndSection

Section "Module"
 Load           "dbe"
 Load           "extmod"
#   Load           "type1"
#   Load           "freetype"
 Load           "glx"
EndSection

Section "ServerFlags"
 Option         "Xinerama" "0"
EndSection

Section "Monitor"
 # HorizSync source: edid, VertRefresh source: edid
 Identifier     "Dell2001FP"
 VendorName     "Dell"
 ModelName      "DELL 2001FP"
 HorizSync       31.0 - 80.0
 VertRefresh     56.0 - 76.0
 Option         "DPMS"
EndSection

Section "Monitor"
 # HorizSync source: edid, VertRefresh source: edid
 Identifier     "Dell2005FP"
 VendorName     "Dell"
 ModelName      "DELL 2005FPW"
 HorizSync       30.0 - 83.0
 VertRefresh     56.0 - 75.0
 Option         "DPMS"
EndSection

Section "Device"
 Identifier     "GF9400_0"
 Driver         "nvidia"
 VendorName     "NVIDIA Corporation"
 BoardName      "GeForce 9400 GT"
 BusID          "PCI:1:0:0"
 Screen          0
EndSection

Section "Device"
 Identifier     "GF9400_1"
 Driver         "nvidia"
 VendorName     "NVIDIA Corporation"
 BoardName      "GeForce 9400 GT"
 BusID          "PCI:1:0:0"
 Screen          1
EndSection

Section "Screen"
 Identifier     "Landscape"
 Device         "GF9400_0"
 Monitor        "Dell2001FP"
 DefaultDepth    24
 Option         "TwinView" "0"
 Option         "metamodes" "DFP-0: 1600x1200 +0+0"
 Option         "NoLogo" "Off"
 SubSection     "Display"
 Depth       24
 EndSubSection
EndSection

Section "Screen"
 Identifier     "Portrait"
 Device         "GF9400_1"
 Monitor        "Dell2005FP"
 DefaultDepth    24
 Option         "TwinView" "0"
 Option         "metamodes" "DFP-1: 1680x1050 +0+0"
 Option         "NoLogo" "Off"
 Option         "RandRRotation" "On"
#    Option         "Rotate" "CCW"
 SubSection     "Display"
 Depth       24
 EndSubSection
EndSection

  • ALSA Sound Samples Are Monaural

    The Arch Linux setup guide uses the ALSA sound samples in /usr/share/sounds/alsa to verify that everything’s working:

    aplay /usr/share/sounds/alsa/Front_Center.wav

    Which, as it turned out, worked perfectly: a female voice front-and-center.

    Flushed with success, I tried some of the other samples:

    cd /usr/share/sounds/alsa/
ls -l
total 1212
-rw-r--r-- 1 root root 137134 2009-10-20 05:26 Front_Center.wav
-rw-r--r-- 1 root root 142128 2009-10-20 05:26 Front_Left.wav
-rw-r--r-- 1 root root 146990 2009-10-20 05:26 Front_Right.wav
-rw-r--r-- 1 root root 135202 2009-10-20 05:26 Noise.wav
-rw-r--r-- 1 root root 130096 2009-10-20 05:26 Rear_Center.wav
-rw-r--r-- 1 root root 126064 2009-10-20 05:26 Rear_Left.wav
-rw-r--r-- 1 root root 146480 2009-10-20 05:26 Rear_Right.wav
-rw-r--r-- 1 root root 134868 2009-10-20 05:26 Side_Left.wav
-rw-r--r-- 1 root root 129966 2009-10-20 05:26 Side_Right.wav

    All of which played front-and-center.

    Come to find out that they’re all recorded in Monaural mode, so the file names don’t really mean anything.

    soxi Front_Left.wav 

Input File     : 'Front_Left.wav'
Channels       : 1
Sample Rate    : 48000
Precision      : 16-bit
Duration       : 00:00:01.48 = 71042 samples ~ 111.003 CDDA sectors
File Size      : 142k
Bit Rate       : 768k
Sample Encoding: 16-bit Signed Integer PCM

    Definite disappointment, that… it’s not Arch’s fault, they’re monaural in Ubuntu,too.

  • Disabling OpenOffice 3.1 Word Completion

    I type well enough that OpenOffice’s default word completion isn’t helpful, so the first thing I do in the first document I open after a new installation is turn word completion off. Having just installed Xubuntu 9.10 with OpenOffice 3.1, I rummaged through the menus and couldn’t find that option. OK, I’ll let my fingers do the walking through the online Help.

    Huh. For some inexplicable reason, the OOo help files aren’t installed by default in Kubuntu 9.10 or Xubuntu 9.10. I install them, only to find:

    Word Completion
    Set the options for completing frequently occurring words while you type.
    To access this command…
    Choose Tools – AutoCorrect Options – Word Completion tab
    Enable word completion
    Stores frequently used words, and automatically completes a word after you type three letters that match the first three letters of a stored word.

    Which is absolutely correct, should you happen to be editing a text document at the time. Oddly enough, the Word Completion tab doesn’t appear in that dialog box when you’re editing a spreadsheet… but the setting applies to spreadsheets.

    So.

    • Save and close the spreadsheet
    • Open a new, blank text document
    • Do the menu dance just like the Help text describes
    • Un-check the mumble Enable word completion box.
    • Discard the text document
    • Re-open the spreadsheet

    There, now, wasn’t that obvious?

  • Ubuntu 9.10 Partition Backup: ext4 vs partimage vs dd

    Ubuntu 9.10 uses ext4 filesystems by default and it’s usually a Good Thing to not mess with defaults early in the installation.

    That precept worked up to the point where I wanted to make a full-partition backup before doing something potentially catastrophic… at which point I discovered that the current version of System Rescue CD has a version of partimage that doesn’t know about ext4 filesystems. While FSArchiver looks promising, all I really wanted was a quick-and-simple backup and (possibly) restoration.

    So. Once again, dd to the rescue.

    This being a fresh installation, there’s not much other data to contend with. In fact, the installation uses under 3 GB, but it’s in a 32 GB partition. Wouldn’t It Would Be Nice If we could back up just the 10% of useful data and skip the rest?

    Reboot to System Rescue CD (hereinafter, SRC) and, while that’s happening, plug in a spare hard drive using a USB-to-SATA converter. That will be the “backup drive”.

    Mount the backup drive (which appeared as /dev/sdf1 and will be different for you) at /mnt/backup, which is conveniently provided by SRC:

    mount /dev/sdf1 /mnt/backup

    Mount the partition to be backed up (which is /dev/sda8 and will be different for you) at /mnt/custom, another existing mount point.

    mount /dev/sda8 /mnt/custom

    Zero out all the unused space by creating one honkin’ big file, then erase it leaving all those highly compressible zeros behind:

    dd bs=1M if=/dev/zero of=/mnt/custom/zero.bin
sync
rm /mnt/custom/zero.bin

    Unmount the partition, make the backup, and save the MBR while you’re at it:

    umount /mnt/custom
dd bs=1M if=/dev/sda1 | gzip -c -3 > /mnt/backup/boxname-sda8-ext4-32GB.bin.gz
dd bs=512 count=1 if=/dev/sda of=/mnt/backup/boxname-mbr.bin

    The bs=1M option sets a decent blocksize for the read operations, which gets dd trundling along at a pretty good clip by reducing the per-read overhead.

    The -c option tells gzip to pipe the output to stdout and not mess with the input file. The -3 says to not waste a lot of time trying to compress the data; much of the partition consists of raw binary executables, so there’s no point. The whole process will be limited by disk I/O speed, most likely.

    As it happened, the partition squeezed down into about 1.8 GB worth of gzipped backup file.

    Unmount the backup drive, reboot, and do risky things…

    As it turned out, I actually had to restore the partition.

    Once again, boot into SRC with the backup drive plugged in, mount the backup drive. Restoration is straightforward:

    gunzip -c /mnt/backup/boxname-sda8-ext4-32GB.bin.gz | dd bs=1M of=/dev/sda8

    Warning: if you bungle the target of that dd, you are so screwed.

    You’re both saving and restoring from a specific partition (/dev/sda8, in my case) within the drive, not the whole drive (which would be /dev/sda). Pay attention to what’s on the screen, check twice, and have a full-drive backup lurking in your fireproof safe…