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

  • Automated Scan-and-Enhance: ImageMagick to the Rescue

    Mary’s folks enjoy the daily crossword, but they wanted a slightly larger edition… and, after a bit of procrastination, I conjured up an automated way to make it happen, so her father need not do this manually with The GIMP and Xsane.

    The scanner, an old HP Scanjet 3970, dropped off the Windows driver list after Vista, so it now runs only with Linux.

    Doing the scan is straightforward, as it’s the default scanner:

    scanimage --mode Gray --opt_emulategray=yes --resolution 300 -x 115 -y 210 --format=pnm & scan.pnm
    

    The X and Y coordinates set the scan dimensions in millimeters, which should be as small as possible consistent with scanning the whole crossword.

    The driver produces output image files in PNM format, which isn’t particularly common these days, or TIFF. ImageMagick knows what to do with both of them; I picked PNM.

    Unfortunately, for some unknown reason, the SANE driver produces a severely low-contrast image:

    HP3900 Grayscale Scan
    HP3900 Grayscale Scan

    ImageMagick can produce a histogram:

    convert scan.pnm histogram:hist.png
    

    Which shows the problem:

    HP3900 Grayscale Histogram
    HP3900 Grayscale Histogram

    That’s using the grayscale emulation mode: the driver does a Color scan and converts to Gray mode for the output image. It seems having the driver do the conversion produces better results than scanning directly in Color and then applying ImageMagick, but it’s not my scanner and I don’t have a lot of experience with it.

    Given the PNM image:

    • Blow out the contrast
    • Resize the scan to fill the page
    • Crisp up the edges a bit
    convert scan.pnm -level 45%,60% -resize 2400x3000 +repage -unsharp 0 trim.png
    

    Which looks like this:

    Crossword - contrasty resize
    Crossword – contrasty resize

    This being Linux, the best way to print something is with either Postscript or PDF. I used PDF, because then we can look at the results with Reader, a more familiar program than, say, Evince:

    convert -density 300 -size 2550x3300 canvas:white trim.png -gravity center -composite page.pdf
    

    Which centers the crossword on the page over a white background with enough margin to keep the printer happy:

    Crossword - full page
    Crossword – full page

    That PDF goes to the default printer queue, where it’s turned into Postscript and comes out exactly like it should:

    lp page.pdf
    

    I gimmicked the default printer instance to use only black ink by creating a separate CUPS printer with the appropriate defaults. Other programs pay no attention to that setting and the printer uses colored inks. There is no explanation I can find for any of this; Linux / CUPS printing is basically a black box operation.

    In theory, you could print the composited image file as a PNG or some such, but I cannot make it come out the right size in the right place.

    You could do all of that in one line, with one huge ImageMagick invocation kicking off the scan and firing the result to the printer, but leaving some intermediate results lying along the trail isn’t necessarily a Bad Thing. I should probably use random temporary file names, though, in the interest of not polluting the namespace.

    All this happened remotely, with me signed on through SSH: hooray for the command line. Had to use SCP a few times to fetch those intermediate files to puzzle over the results, too.

    The complete Bash script:

    #!/bin/bash
    scanimage --mode Gray --opt_emulategray=yes --resolution 300 -x 115 -y 210 --format=pnm > /tmp/scan.pnm
    convert /tmp/scan.pnm -level 45%,60% -resize 2400x3000 +repage -unsharp 0 /tmp/trim.png
    convert -density 300 -size 2550x3300 canvas:white /tmp/trim.png -gravity center -composite /tmp/page.pdf
    lp /tmp/page.pdf
    

    A slightly closer scan crop with left and top margins may also work, at the cost of more precise positioning on the scanner:

    #!/bin/bash
    scanimage --mode Gray --opt_emulategray=yes --resolution 300 -l 5 -t 6 -x 105 -y 190 --format=pnm > /tmp/scan.pnm
    
    
  • UDEV Rules for M2’s HAL Devices

    Rather than have a bunch of separate rule files for each USB HID device I’ll be using with LinuxCNC on the M2, here they are in one lump:

    cat /etc/udev/rules.d/hal-input.rules
    # Rules to configure input device permissions for hal_input
    
    ATTRS{product}=="Nostromo SpeedPad2",GROUP="plugdev",MODE="0660"
    ATTRS{product}=="Arduino Leonardo",GROUP="plugdev",MODE="0660"
    ATTRS{product}=="Logitech Dual Action",GROUP="plugdev",MODE="0660"
    

    The strings are case-sensitive and must match exactly. That post (among others) describes the whole dance required to get all the information.

    Remember to add yourself to the plugdev group, too.

  • Logitech Dual Action Gamepads: Mac vs. PC

    Turns out that there’s no difference between the Mac and PC versions of the Logitech Dual Action Gamepad:

    Logitech Dual Action Gamepads - Mac vs PC
    Logitech Dual Action Gamepads – Mac vs PC

    I picked up a Mac version cheap from the usual eBay seller and discovered that LinuxCNC / HAL was perfectly happy. That wasn’t too surprising; they have the same model and part numbers. Most likely, the only difference was the CD and maybe the Quick Start Guide that I didn’t get in the opened retail box…

    So now I have either a hot backup for the Joggy Thing or one for a different box.

    Most likely, it was cheap because nobody wants a blue-and-black peripheral next to their shiny white Mac…

  • Dual Monitors: devilspie2 FTW!

    Because it seems there’s no good support for separate X sessions with dual monitors these days, the landscape and portrait monitors on my desk represent viewports into a larger pixel array within a single X session. As a consequence, it’s entirely possible to slide windows across the gutter between the two displays (generally producing an essentially unusable result), but one cannot flip through workspaces on only one monitor.

    Worse, some programs seem to have trouble remembering that they were last seen on the portrait monitor, so I must rearrange the windows at the start of every session. First world problem, yeah, but still annoying.

    I’d previously used devilspie to force windows to their proper places across monitors, sessions, and workspaces, but its s-expression syntax was impenetrable and I eventually gave up using it.

    A fork (or continuation or something) called devilspie2 uses lua scripts that I can both read and write. It’s an Ubuntu package and easy to set up.

    A typical script in ~/.config/devilspie2 looks like this:

    if (get_application_name()=="Firefox") then
       set_window_geometry(0,0,1300,1200);
       maximize_vertically();
    end
    

    Putting Adobe Reader on the portrait monitor looks about the same:

    if (get_application_name()=="acroread") then
       unmaximize();
       set_window_geometry(2561,0,1000,100);
       maximize();
    end
    

    Set /usr/bin/devilspie2 as an auto-started program and it Just Works…

  • Dual Monitors: Dual-Link DVI + HDMI

    Finally, this Just Worked…

    The problem was to get both a landscape and a portrait monitor working. The complexity came from the landscape monitor, a 2560×1440 Dell U2711, which requires either a Dual-Link DVI or HDMI input to reach full resolution. The portrait monitor, an old 1608×1050 Dell 2005FPW, uses Single-Link DVI.

    The previous attempt with an nVidia GT430 card failed: both DVI outputs were Single-Link, despite their connector’s appearance. It had worked OK with the previous landscape monitor, a 1600×1200 Dell 2001FP.

    So I picked up a low-end nVidia GT610 card that advertised both Dual-Link DVI and HDMI. I plugged the DVI cable into the U2711 and it lit up at full resolution, then I plugged the HDMI into the 2005FPW and it lit right up. By some miracle that didn’t involve tweaking an xorg.conf file, the 2005FPW immediately displayed the pixels lying to the right of the U2711, exactly as I wanted; all I had to do was rotate the image using xrandr.

    Not only that, but the version of xsetwacom in Xubuntu 12.10 once again respects the MapToOutput "HEAD-0" option that restricts the stylus to the U2711 monitor. That means I can’t put the GIMP toolbars and suchlike on the portrait monitor, but the U2711 has enough dots to render that moot.

    Although the Dell doc strongly suggests that the on-board VGA and Displayport outputs don’t work with a PCI-E video card plugged in, xrandr reports:

    Screen 0: minimum 8 x 8, current 3610 x 1680, maximum 16384 x 16384
    DVI-I-0 disconnected (normal left inverted right x axis y axis)
    VGA-0 disconnected (normal left inverted right x axis y axis)
    DVI-I-1 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
       2560x1440      60.0*+
       1920x1200      59.9
       1680x1050      60.0
       1600x1200      60.0
       1280x1024      75.0     60.0
       1280x800       59.8
       1152x864       75.0
       1024x768       75.0     60.0
       800x600        75.0     60.3
       640x480        75.0     59.9
    HDMI-0 connected 1050x1680+2560+0 left (normal left inverted right x axis y axis) 434mm x 270mm
       1680x1050      59.9*+
       1280x1024      75.0     60.0
       1152x864       75.0
       1024x768       75.0     60.0
       800x600        75.0     60.3
       640x480        75.0     59.9
    

    I’m not going to connect the DVI-I-0 and VGA-0 outputs; my physical desk has no room for more pixels…

    The ~/.xprofile file now looks like:

    setxkbmap -option terminate:ctrl_alt_bksp
    xrandr --output HDMI-0 --rotate left
    xrandr --dpi 100x100
    xsetwacom --verbose set "Wacom Graphire3 6x8 stylus" MapToOutput "HEAD-0"
    xsetwacom --verbose set "Wacom Graphire3 6x8 eraser" MapToOutput "HEAD-0"
    

    Phew…

  • Kensington Expert Mouse Trackball: Scroll Ring Aperture Alignment

    That comment suggested scroll ring failures on a Kensington Expert Mouse (it’s a trackball) might occur when the apertures become misaligned from the IR emitter-detector pair, although later results were equivocal. I tore apart a failed unit to see what the alignment looked like for a known-bad scroll ring.

    The right side view shows the receiver roughly centered in an aperture:

    Kensington Expert Mouse - Scroll Ring aperture - right
    Kensington Expert Mouse – Scroll Ring aperture – right

    The left side view shows that the ring is almost flush against the circuit board, with the isolating cutout just in front, and it’s not obvious how to lower it any further:

    Kensington Expert Mouse - Scroll Ring aperture - left
    Kensington Expert Mouse – Scroll Ring aperture – left

    So I think there’s no way to realign this one, other than to raise the aperture ring a bit, but that doesn’t seem like it would make any difference: the detector already has a good view of the emitter.

    If your trackball has a failed scroll ring, tweaking the aperture ring’s alignment certainly can’t hurt: try it and report back.

    If you don’t expect a miracle, you probably won’t be disappointed, alas.

    The pix come from the Canon pocket camera mounted on the macro lens / illuminator, handheld with manual focus. The dust speck on the detector is just slightly out of focus, but you get the general idea.

    Update: 2015-07-29 – A success story from Tom:

    Hi, I wanted to leave a comment for your page here: [this url]

    I’ve got an expert mouse trackball that was having intermittent scroll ring problems, then finally quit working altogether. Dismantled it easily using the instructions on this site.

    Cleaned it and it still wasn’t working. Tried changing the alignment of the IR emitter/detectors and it still wasn’t working. Then we kept on fiddling with the alignment and voilà.

    Like others have said, the alignment seems to be SUPER sensitive. So if any others are reading this with the same problem, keep persevering.

    Thanks to everyone who has posted to help find solutions!

    Another update: Seven years in the future, a real fix appears!

  • Upstart vs. NFS Mounts vs. LightDM: Success!

    That comment suggested a different solution to the problem of having the display manager start before the NFS mounts complete. When that happens, you can sign in and start programs that won’t have access to their data, producing all manner of heartache and confusion.

    One complication: it seems /etc/rc.local starts and runs before the network (among other tidbits) gets connected and becomes ready, which means you can’t just plunk your code in that file like you used to, at least not in Ubuntu. Fixing that requires an upstart script triggered when the network interface finally hauls itself to its feet.

    There’s no actual link between the NFS mount commands and the display manager startup, but it seems that if you don’t attempt to mount the NFS shares before the network becomes active (which is what happen with shares automounted through /etc/fstab), but wait for the network to come up and then issue the mounts, the shares mount almost instantly and become ready by the time the display manager presents the login screen. That’s better than the kludge I had figured out and works fine, so I’ll run with it until something else breaks.

    The not-quite-deterministic fix has three parts:

    • Use noauto in the fstab entries for the NFS shares
    • Create an upstart script to mount those shares after eth0 lights up
    • Allow lightdm to start up normally (i.e., remove my hackish attempts)

    A sample line from fstab, with the vital noauto option:

    oyster:/mnt/bulkdata	/mnt/bulkdata	nfs	noauto,noatime	0 0
    

    The /etc/init/local.conf script assumes the network interface will be eth0, which does not generalize to wireless networks on laptops and suchlike. You could add some Boolean logic to wait for the first of several interfaces, I suppose:

    description "Stuff that should be in /etc/rc.local"
    author "Ed Nisley - KE4ZNU"
    
    start on (local-filesystems and net-device-up IFACE=eth0)
    stop on shutdown
    script
    
    logger Starting local init...
    
    logger Mounting NFS filesystems
    mount /mnt/bulkdata
    mount /mnt/userfiles
    mount /mnt/diskimages
    mount /mnt/music
    
    logger Ending local init
    
    end script
    

    The lightdm.conf file reverts to the distribution version, with this starting trigger:

    start on ((filesystem
               and runlevel [!06]
               and started dbus
               and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
                    or stopped udev-fallback-graphics))
              or runlevel PREVLEVEL=S)
    

    It’s worth noting that the upstart interpreter hates comment lines embedded within statements: it does not regard them as whitespace and does not ignore them. Just don’t do it. That explains some of the problems I encountered before, but fixing those problems did not eliminate the overall issue.

    The end result of all that hocus-pocus makes the box boot the way it used to: the display manager comes up promptly, presents the GUI login screen, and the NFS mounts are ready when you are.