Saturday, June 17, 2017

[solved] A "simple" line and arrow photo mod

Twenty years on in Linux, it's still not easy to take a PNG or JPG and circle something, do a simple straight line, a straight line with an arrow and text, etc, and then resave the file at the same resolution.
  • Xournal will not open PNGs
  • GIMP has rasterized, freehand looking garbage, else you learn to do colored paths with transparent fills, which only works for the circles. Ludicrous.
  • DIA appears unreliable opening PNG's -- it will snap lines to weird locations and so on.
  • Libre Office, could be installed, and then one could add, say, "Draw", which will work on adding arrows, if a person can put up with the immense installation, memory use, and significant updates.
So there's no simple way to note these photos unless one has a large application. Since Inkscape is smaller than Libre Office... OK then, Inkscape it is, though you know it's not going to be easy.

Inkscape: Line and arrow - lots of keystrokes

From this site, there's an unhelpfully incomplete version, to which I've added important steps.
  1. Open the PNG
    "File" -> "Open", then select the PNG
  2. Open "lines mode"
    Select lines from side menu or (Shift+F6)
  3. Make a line
    Click the starting point of the line, click its ending point, and then press "enter" key. The line is not done until "enter" is pressed.
  4. Adjust the line features
    • "Object" --> "Fill and Stroke", or (Shift+Ctrl+F) opens the Fill and Stroke Dialog. A new half-page dialog window appears.
    • Select "Stroke Style" tab. Here you can increase width of the line from 1 pixel to whatever's comfortable.
  5. Select an arrowhead
    Also within the "Stroke Style" tab are "Markers". These are the ending points of the line. Choose an arrow or some other shape for the Start Marker or End Marker of the line.
  6. Save the changes
    "File" --> "Save", or export it to a new file. If exporting, select the entire page or just some selected region.

Thursday, April 20, 2017

[solved] Epson V30 (04b8 x 0131)

Initiating the GUI xsane application with a USB-connected Epson V30 scanner results in a pause, then termination of the xsane application (without scanning). Connecting an Epson V370, the same actions result in normal xsane scanning operations. Using a known-good, functioning USB-connected Epson V370, let's run similar applications on both the V370 and the non-functioning V30, until we can find a difference, and hopefully solve the V30 non-operation.

CLI software

First, can we at least detect the V30 using the command-line? Two command line interface (CLI) scanner probes, scanimage and sane-find-scanner, verify slightly different features. Scanimage is the more thorough. Scanimage on the V30 pauses, but eventually goes to completion, describing the V30 as "unknown model".
$ scanimage -L
device `epkowa:usb:001:004' is a Epson (unknown model) flatbed scanner
... on the V370 there's no delay and the model name is identified.
$ scanimage -L
device `epkowa:interpreter:001:004' is a Epson Perfection V370 Photo flatbed scanner
Model name aside, the V30 and V370 are properly detected and trigger the kernel to create data files; we can rule-out hardware, firmware, or kernel problems. Since the USB device name for the V370 includes "interpreter", but the V30 device name remains "usb"; the kernel is not receiving additional information for the V30, beyond the simple usb connection. Let's locate the (operational) V370 driver on the hard drive, and see if the V30 is in the same folder and perhaps not working.
Attaching the USB V370, and stracing $ scanimage -T ($ strace scanimage -T 2>&1 |tee V370file.txt) and then searching inside the resulting text file, I noted (~line 1195)
open("/usr/lib/iscan/", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/iscan/", O_RDONLY|O_CLOEXEC) = 9
The V370 driver inside /usr/lib/iscan, however I could find no driver relevant to the V30 in that folder. It appears we're lacking a V30 driver. A V30 driver would give the kernel more information than "usb".

driver software

I lucked into a premade AUR version of the V30 driver -- one step with yaourt. A conversation about this driver exists on the forums. Apparently, the creator downloaded a DEB file from the Epson site and then converted the DEB into a pacman/yaourt package. It's probably also worth noting that DEB's can be directly installed on Arch with a couple of steps. In this case, I had the premade AUR version I could install more easily using yaourt.
$ yaourt Ss v30
aur/iscan-plugin-gt-f720 0.1.1-1 (8) (0.01)
EPSON Image Scan! plugin for Epson Perfection V30 scanner
$ yaourt -S iscan-plugin-gt-f720
After installation, the V30 should appear with its model information and "interpreter" instead of "usb"...
$ scanimage -L
device `epkowa:interpreter:001:004' is a Epson Perfection V30 flatbed scanner
...and scan images via xsane.

possible tweaks

If there are still problems, check the following.
  • Uncomment "usb" inside /etc/sane.d/epowka.conf, but without adding any make or model information, just leave it as "usb". If you add make or model, scanimage may generate a second, conflicting, instance of the V30.
  • Comment "epowka" in /etc/sane.d/dll.conf, or conflicts will occur.
  • The scanner libs directory should include softlinks to the main lib,, eg
    $ ls /usr/lib/iscan/
  • Run
    $ iscan-registry -a 0x04b8 0x0131
See bottom of this page for more configuration file info.

Troubleshooting prior to yaourt

block hpaio

Sometimes hpaio loads when there's no HP scanner. Like many Linux apps, they either don't work at all or they can never be disabled. Hpaio won't stop the V30 or other scanners, but it's a hardcore annoyance since it's impossible to turn off via any interface, by disabling CUPS, etc. I got tired of this fast and blacklisted the sumb*tch. Find the names of the hp-related libsane files in /lib/sane.d/, because you can't find it and its dependencies the normal way...
# modinfo -F depends libsane-hp
modinfo: ERROR: Module libsane-hp not found.
... and then blacklist them via /etc/modprobe.d/blacklisted.conf (you can call the file anything).
# nano /etc/modprobe.d/blacklisted.conf
# stop hpaio annoyance when no hp scanner connected
install libsane-hpaio /bin/true
install libsane-hp /bin/true

xsane also loads hpaio

Any time xsane is initiated, xsane finds these hpaio drivers and loads them directly. Stracing xsane
open("./dll.d", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
fstat64(7, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getdents(7, /* 4 entries */, 32768) = 76
1572:stat64("/etc/sane.d/dll.d/hpaio", {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
1573:open("./dll.d/hpaio", O_RDONLY) = -1 ENOENT (No such file or directory)
1574:open("/etc/sane.d/dll.d/hpaio", O_RDONLY) = 8
1576:read(8, "hpaio\n", 4096) = 6
4071:open("/usr/lib/sane/", O_RDONLY) = 19
4073:open("/usr/lib/sane/", O_RDONLY|O_CLOEXEC) = 19
so you will also have to disable xsane from activating hpaio.
# nano /etc/sane.d/dll.d/hpaio
# comment the following so hpaio doesn't load.
Note: don't forget that, if an HP scanner is ever connected, you'll need to undo these changes to both /etc/sane.d/dll.d/hpaio and to /etc/modprobe.d/blacklisted.conf.
But back to yaourt. Yaourt was the end-point, yet I had proceeded through several troubleshooting steps to determine the driver issue. A couple of workday's worth of effort were spent ruling-out any physical connection, firmware, kernel, or configuration files. Some of that is noted above, the remainder is below.

lsub -vv (v370)

Partial information from lsusb -vv:
idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x014a
bcdDevice 1.00
iManufacturer 1 EPSON
iProduct 2 EPSON Perfection V37/V370
iSerial 0

lsub -vv (v30)

Partial information from lsusb -vv
idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x0131 GT-F720 [GT-S620/Perfection V30/V300 Photo]
bcdDevice 1.00
iManufacturer 1 EPSON
iProduct 2 EPSON Scanner
iSerial 0


Running sane-find-scanner (lsusb -vv also would have been fine) against both models, both scanners properly return hexadecimal model/product codes.
(vendor=0x04b8 [EPSON], product=0x014a [EPSON Perfection V37/V370])
... and for the V30, sane-find-scanner returns...
(vendor=0x04b8 [EPSON], product=0x0131 [EPSON Scanner])
I also attempted to get attributes and do tests on the V30, prior to yaourt.
$ scanimage -A -d 'epkowa:usb:001:004'
$ scanimage -T -d 'epkowa:usb:001:005'
Both of these time-out, returning nothing however, since we have the hexidecimal model code on both scanners (0131 for the V30 and 014a for the V370), firmware, hardware detection, and/or physical USB connection problems are ruled-out. There are three remaining categories of variables for this V30 problem. 1) Kernel software, application software, configuration files.

Kernel side

The kernel creates and destroys files inside the directory /run/udev/data/ whenever a USB device is connected or disconnected to a UNIX system. User-level applications, such as xsane, then read these files for operating parameters. So we'd like to check the /run/udev/data/ files for the V30. If they're good, we know xsane is malfunctioning. If they're bad, we know the kernel is malfunctioning (or not receiving enough V30 info).


How do we find the names of the files created when the V370 or the V30 are connected by USB? Sane-find-scanner is helpful, but we'll need to strace it to gather enough information. We'll send the two results to text files we can parse. First, the operating scanner, V370. Connect it to the USB port and, ($ strace sane-find-scanner 2>&1 |tee V370file.txt). At line 700 (YMMV) of V370file.txt, we find a call to the data file c189:5:
$ grep -rn "/run/udev/data"
open("/run/udev/data/c189:5", O_RDONLY|O_CLOEXEC) = 8
Next, the non-scanning V30. Connect it via USB and, $ strace sane-find-scanner 2>&1 |tee V30file.txt . At line 700 (again, YMMV) of V370file.txt, we find a call to the data file c189:4:
$ grep -rn "/run/udev/data"
open("/run/udev/data/c189:4", O_RDONLY|O_CLOEXEC) = 8
Now we have the names of the two data files the kernel creates, 189:5 for the V370, and 189:4 for the V30. Here's the content for the two files. The (functioning) V370
$ cat /run/udev/data/c189:5
...and, when the V30 is attached
$ cat /run/udev/data/c189:4
E:ID_MODEL_FROM_DATABASE=GT-F720 [GT-S620/Perfection V30/V300 Photo]
Since both the V370 and the V30 files are properly created inside /run/udev/data/, the kernel is now ruled-out as a problem. Secondly, these presence of these data files also probably excludes the rules the kernel uses to write data files for /run/udev/data/. These rules for helping the kernel translate a physical USB connection into a data file are in /lib/udev/rules.d/. In the case of the scanner rules, the rules file is /lib/udev/rules.d/49-sane.rules. So far, everything has checked-out normally, and now we have ruled out the kernel's USB firmware detection and data propagation processes.


Our current unsolved clues related to the non-scanning are 1) the pause and eventual time-out when V30 is queried, 2) the unnamed model "Scanner", 3) the name "usb", instead of "interpreter" inside scanimage -L results.
# echo -1 >/sys/module/usbcore/parameters/autosuspend
Still, EAGAINs and the pauses did not stop, and this led me, finally, to a driver.

Other rule-outs: configuration files

  • /etc/sane.d/epson.conf - possibly could add the make and model to identify the V30, however if a yaourt or pacman solution is available, remove it.
  • /etc/sane.d/saned.conf - Should not be a problem, since V370 is operating
  • /etc/sane.d/dll.conf - No problems since V370 is working
  • /etc/sane.d/epkowa.conf - No problems since V370 operates
  • /usr/share/iscan-data/usb - Neither the 014a or the 0131 models are in this file. This file is opened during scanimage tests however.

[solved] Xerox WorkCentre 5875 on network

This is an interesting case. The only PPD at the Xerox driver site seemed to be embedded in a Windows EXE file -- this may have been complicated to access via, say, Wine. However, I eventually Googled upon an Italian site which provided the generic 5875 PPD, xrx5875.ppd. This version is considered to have only basic functionality, and it was compressed into a ZIP. I was unable to find a full-feature PPD.

Pressing onward, 1) unzip the ZIP to extract the PPD, 2) walk over to the Xerox and retrieve the machine's IP address from its printer menu (in this case,, then....
# cp xrx5875.ppd /usr/share/cups/model/xrx5875.ppd
# chmod 644 /usr/share/cups/model/xrx5875.ppd
# systemctl enable org.cups.cupsd.service
# systemctl start org.cups.cupsd.service
# lpadmin -p WorkCentre5875 -E -v socket:// -m xrx5875.ppd
After this, if the 5875 is the main copy/printer a person uses at work, they might consider going back into CUPS (http://localhost:631) and setting the Xerox to be the default printer.

Tuesday, March 21, 2017

GiMP - delete areas outside an image

GIMP mostly does exactly the opposite of what I want in a few steps, or takes many many steps to do what I want, or the tutorials leave out one critical step that costs my weekend. In other words, I hate GIMP, but it's free. Take the following image of an old duct-taped surfboard that I found online.

Suppose I wanted to delete the background and keep the foreground surfboard. You'd think, OK, 3 minutes,3 steps: take the magic wand/select, add transparency, then bucket fill the selected parts. Two problems: 1) the surfboard has black fins, so fuzzy select goes into the surfboard, 2) bucket fill fills a selected area, not areas outside a selected areas. So now I have to do this differently, and with a shitload of steps.

Tutorials (10 minutes):

  1. Do all the selection steps, click click path nodes, then hit edit and bend them. Then Select by Path
  2. Add alpha transparency layer
  3. Delete key
Your image will be deleted and your background will be left, just as if you used the bucket fill tool.

2 hours later, the Real (10 minutes):

  1. Do all the selection steps, click click path nodes, then hit edit and bend them. Then Select by Path
  2. Select-->Invert. This swaps what's selected with what's not selected or, say, the background with the foreground.
  3. Add alpha transparency layer
  4. Delete key

Wednesday, March 15, 2017

Locale miasma

Linux has so many problems and so many solutions, but if you've been in it for years, two of the biggest little issues that turn into patience cancers are sound and locales. Note from this page the number of variables which can be accepted.

But there are memory (aka "speed") concerns involved with locale selection, which is why I typically only use "C", by uncommenting it inside /etc/locale.conf. To check:
$ locale

However, suppose I want to do something as simple as play solitare.
$ sol v=Klondike
Non UTF-8 locale (ANSI_X3.4-1968) is not supported!

What's needed is a fast way to switch locales, obviously, but without the downstream issues of perhaps font regeneration and other failures.

Monday, February 13, 2017

tcpdump in userspace

Typically, a person needs root permission to get tcpdump:
$ tcpdump
tcpdump: wifi01: You don't have permission to capture on that device
but it appears a person can make a PCAP group and get access to their card. Eg, let's say the card is wifi01.

what worked

  1. # groupadd pcap
    # usermod -a -G pcap user
  2. Now this appears to be the tricky part. We're already members of tcpdump, however now we're going to change the membership and permissions of tcpdump over to pcap's control.(Note: this may not be necessary if my user is already a member of the tcpdump group.)
    # chgrp pcap /bin/tcpdump
    # chmod 750 /bin/tcpdump
  3. Finally, we have to use setcap to set file capabilities. Not sure if this is permanent.
    # setcap cap_net_raw,cap_net_admin=eip /bin/tcpdump
  4. But I had to repeat the process for /usr/bin/tcpdump before it would work.
    # chgrp pcap /usr/bin/tcpdump
    # chmod 750 /usr/bin/tcpdump
    # setcap cap_net_raw,cap_net_admin=eip /usr/bin/tcpdump
  5. This worked:
    $ tcpdump
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on wifi01, link-type EN10MB (Ethernet), capture size 262144 bytes
  6. However with the tcpdump backend configured, I went to wireshark to get me to CSV, so I could parse. Wireshark saves to PCAP: save it as some PCAP. Once saved, I could export to CSV and whittle it down.

Saturday, January 28, 2017

[solved] evince not printing, not displaying printers

Googling around, this post appeared helpful and pointed toward the undocumented dependency problem. Solved with:
# pacman -S gtk3-print-backends
As someone noted on the post, "great catch"; this is a detail which can evaporate a person's weekend. Surprising that the packager wouldn't see it as a necessary dependency for evince, but that's life.