Thursday, June 25, 2015

[solved] screen blanking

Link: Excellent Blanking Overview

The Linux solutions in forums seem to me to often lack some necessary detail. And if something is missing, a person doesn't even know this, of course, until they entirely overcome whatever was left out. That might be hours or days later, if ever. It can be frustrating.

For screen blanking management, the key detail, unstated in any forum solution I found, was to first be sure blanking was disabled in runlevel3. Screen blanking settings are baked into the kernel, and if they're not first managed in runlevel3, prior to startx, blanking cannot be narrowed down to X settings. Rule-out half of the possible screen blanking problems by disabling runlevel3 blanking.

Run Level 3 (Non-GUI blanking isolation)

Again, do this first, prior to working on X, since terminal blanking is baked into the kernel and must be defeated before any X solution will work. In runlevel3 terminals, the setterm command controls several terminal settings, among them blanking times. To stop blanking in the terminal:
$ setterm -blank 0
The setterm command is not permanent when used in a terminal -- the next boot will reset to default kernel settings. To permanently stop blanking users can: disable blanking using their GRUB/LILO configuration, add a bootline flag, or make a systemd command. But another permanent option, which I considered the easiest hack for my installation, was to add a setterm line into /etc/profile. In other words:
$ nano /etc/profile
setterm -blank 0
This arrangement survived reboots. And, with the runlevel3 managed, I could attempt various X session solutions. Ideally, I wanted a 2.5 hour blank-out so I could watch a film while going to sleep and have it blank soon after.

X session failed configurations

Typically, the primary file for X configuration is ~/.xinitrc. If you're running Arch, multiple options are described here. Users may have to try several configurations or combine them. In my case, no suggested settings within ~/.xinitrc was successful. Even a suggested combination of runlevel3 and x commands did not work, for example:
$ nano .xinitrc
setterm -blank 0 -powersave off -powerdown 0
xset s off

X session successful configuration

Per the same link, after failures with ~/.xinitrc, I created a DPMS file to place into /etc/X11/xorg.conf.d/. The file was named, 10-monitor.conf. Here is one way to set it up.
# nano /etc/X11/xorg.conf.d/10-monitor.conf
Section "Monitor"
Identifier "LVDS0"
Option "DPMS" "false"

Section "ServerLayout"
Identifier "ServerLayout0"
Option "BlankTime" "150"
Option "StandbyTime" "155"
Option "SuspendTime" "160"
Option "OffTime" "0"
This worked for me. As described here, one can tweak these entries. Trial and error revealed that times in the ServerLayout are in units of minutes. I left "OffTime" as 0, to disable automatic power-down.

Summary: Manipulating blanking requires two files, one to stop runlevel3 blanking, and a second to adjust X session blanking.

Tuesday, June 23, 2015

extra laptop storage - hdd in optical slot, notes: external usb, thunar

Backups are a pain. They can be managed more easily in a laptop by purchasing a $10 drive caddy (photo) into which a backup SATA HDD can be placed.
Once the HDD is in the caddy, the laptop's DVD drive is removed, and the caddy (with the HDD drive) goes into its place.

software steps

First, determine the names of drives in your system. This is easily done with, say, fdisk -l. Using the name of drive, add a line for it in fstab:
# fdisk -l
[suppose result is "sdb1" for caddy drive]

# nano /etc/fstab
/dev/sdb1 /home/media ext3 rw,relatime 0 1

Now the drive will automatically mount each time the system is booted. Once mounted, the drive is an available repository for back-ups. Files can be transferred between the drives using a file manager, or a user might implement a backup schema or program (such as Rsync, eg. with chron).

Note: if you decide to put the optical drive back in the slot, comment the fstab entry for the removed HDD before rebooting, otherwise, it will seek the drive and take several minutes to boot.

external (usb) drives

For the setup above, no special applications are necessary. However, if one is going to use a USB stick or drive, the typical rule applies: you will need to install udisks2, fuser, gvfs or similar bullsh*t, if you don't want to deal with manually mounting these or moving in and out of root. Such applications cause a permission kludge, and may have memory hogging notification daemons that continually poll your system (I dislike .gvfs, notification-daemon is slightly better),but there's little doubt some permutation of these is necessary you're copying to a thumb drive or other USB block device regularly, and want to use a GUI file manager in user-space, without sudoing-up and some CLI skills. In Arch, I use udisks2 in tandem with udiskie (for userspace). Taken together, these are 20Mb:
# pacman -S udisks2 ntfs-3g parted dosfstools udiskie
With these, I can mount any format USB drive, including HFS (Mac).

udisk2 and udiskie note

Links: manual policykit/udiskie config :: systemctl udiskie config
This is a useful app for avoiding fuser, samba, .gvfs, and some others, not needed on stand-alone systems, but it requires configuring. First be sure you're in group "storage" then, for udisks2:
# nano /etc/polkit-1/rules.d/50-udisks.rules
polkit.addRule(function(action, subject) {
var YES = polkit.Result.YES;
var permission = {
// only required for udisks2:
"org.freedesktop.udisks2.filesystem-mount": YES,
"org.freedesktop.udisks2.filesystem-mount-system": YES,
"org.freedesktop.udisks2.encrypted-unlock": YES,
"org.freedesktop.udisks2.eject-media": YES,
"org.freedesktop.udisks2.power-off-drive": YES,
if (subject.isInGroup("storage")) {
return permission[];
Then, for udiskie, somewhere near the end of .xinitrc, but ahead of dbus activation:
$ nano .xinitrc
udiskie &

Thunar note

Supposing this is your file manager for and you've connected a USB drive, you'll also need to install thunar-volman, and to set the permissions (see below) for Thunar to display it.

Select at least the two mounting options I've checked above. The path to this dialog box is: Edit, Preferences, Advanced (tab), Configure.

Finally, if you did install .gvfs, don't forget to exclude it from any dynamic backups or you're in for a world of pain.

Sunday, June 21, 2015

[solved] xsane detection of older or all-in-one HP printers

Sometimes you've got an old HP printer missing print heads or some such, but you still want to use it for scanning. Not all printers can be directly accessed using scanning software, such as SANE, unless the entire printer has been installed using printer software "drivers" (in Windows terms). This is often the case with HP's. To install HP printers, the standard "driver" package is HPLIP. HPLIP is available on Arch repos, however the Arch version of HPLIP doesn't include the specialized PPD's necessary for the printer. (See Section 3 below).

A recent encounter with a broken old HP OfficeJetPro L7590 was a case in point. I only needed this printer to scan. I turned the printer on, and connected the USB. My box detected the USB connection, but /etc/sane.d/dll.conf could not be modified for SANE to successfully communicate with the HP. The standard symptom of this existed: $ sane-find-scanner located the printer, but $ scanimage -L did not. So, good connection, but no scanning: I would have to install the printer driver. Here are the steps.


As just noted above, SANE was properly installed. That was simply:
# pacman -S xsane
Xsane pulls-in SANE software as dependencies, so no need to separately install SANE.


As also noted above, after we'd had SANE in, we'd connected everything (USB cable to scanner, powered on scanner) and attempted $ sane-find-scanner. This detected the printer, but $ scanimage -L did not. Since we were dealing with an HP, we needed the HP Linux printer driver set, HPLIP.
# pacman -S hplip

3. PPD

As noted at the outset, the Arch version of HPLIP does not include PPD's. PPD's are information files specific to each printer model. Both CUPS and HPLIP rely on them. Since the Arch version of HPLIP does not include them, the attempt to install an HP printer ($ hp-install -i) fails at the PPD step. Where to get the PPD for HP printers?

Go to the HP support website and download the tarball of the full version of HPLIP. Uncompress it. Enter the uncompressed folder and locate the "ppd" folder. Find the PPD for your model. After you unzip that PPD, put it anywhere you can easily remember, say your home folder. Now you are ready to complete the HPLIP printer driver installation.

4. Finally

Run $ sane-find-scanner again, and write down the USB number. In this case, let's say it was "002:003". Then we simply run...
$ hp-install -i 002:003
...and follow its prompts. At some point, the HP install dialog will prompt you for a path to the PPD. Provide the path to wherever you put it, eg. "/home/foo/hp_l500.ppd". The installation of the printer will finish normally1.

After HPLIP and the proper PPD are present, and the scanner is connected, our last test is to $ scanimage -L . We should see the scanner:
$ scanimage -L
device `hpaio:/usb/Officejet_Pro_L7500?serial=MT97K251CP' is a Hewlett-Packard Officejet_Pro_L7500 all-in-one
Now we can fire-up Xsane and scan.

1 If also needing to print with this printer, do a customary CUPS printer installation (after doing the steps above). Assuming the CUPS daemon is already running and permissions are correct, access the CUPS'administrative page at http://localhost:631 and add the printer to CUPS.

various chromium issues

You hate to have to use a browser as immense as Chromium. Installing a mainstream browser usually becomes inevitable however, and most of them are worse than Chromium.

What choice do we have but to use gigantic proprietary browsers when website designers are too lazy to create something that works well with lighter browsers? For example, light browsers like Dillo, NetSurf, and so on, have properly functioning cookie capacity, and NetSurf carries simple JavaScript and SSL, yet sites like Yahoo mail, or EBay will disallow access with mislabeled complaints that cookies are being "rejected", or even that correct passwords are "incorrect". These are the result of lazy website design. Anyway...

Here are some installation notes and the three main hassles I've experienced with Chromium (plus safety further down).

Three hassles

These are the big three:
  1. AMD GL settings
  2. Flash settings
  3. Sound settings
Additionally, be sure "gnome-icon-theme is installed. Note that the file ~/.config/chromium/Default/Preferences allows some settings; I the pepper-flash path can go in there, other things that would have to be added to a start-up line instead. Anything in the file is overwritten if the user signs-in to Chromium (not to various Google accounts).

1. AMD/GL settings

After # pacman -S chromium, the initial startup from command line is bound to throw similar errors to these, if you're running an AMD processor:
$ chromium
[6391:6391:0621/] Invalid url pattern: chrome://print/*
[6417:6417:0621/] InitializeSandbox() called with multiple threads in process gpu-process
[6417:6417:0621/] [GroupMarkerNotSet(!:D0CCF6C427020000]GL ERROR :GL_INVALID_OPERATION : glTexStorage2DEXT: <- error from previous GL command
The first fix is in Settings->Show Advanced Settings -> System. Deselect "Use hardware acceleration if available". I also deselect "Continue running background apps when Chromium is closed", but for other reasons). Now restart Chromium without the GPU:
$ chromium --disable-gpu [6391:6391:0621/] Invalid url pattern: chrome://print/*
The print error is probably not worth the trouble, since it's a complex flag issue.

2. Flash settings

The place to turn off Adobe flash and turn on Pepper Flash is inside chrome://plugins. At this point, it should happen automagically, since Google has unwisely allowed Adobe to partner in some way. What is identified as the flash player is not the flash player but PepperFlash if you've installed it. Still, PepperFlash must be downloaded separately, it's not yet apparently bundled.

3. Sound settings

Assuming you want ALSA and not that PulseAudio crap, then be sure to #pacman -S alsa-tools alsa-utils


  1. One site was suggesting removing the RLZ tag from omnibar/omnibox searches (omnibar/omnibox is the URL bar that has morphed into a search bar in Chromium). I don't consider it a threat, but it's good to understand it superficially. One explanation is here. If you don't want it, add another search engine option, calling it whatever you want, but a URL lacking "RLZ". For example:
    You can see this also provides 100 returns per page -- you may want less.

Saturday, June 13, 2015

reasonable startup log (journald) sizing

Prior to systemd, boot-ups used to log to /var/log, pretty much auto-magically via rsyslog (syslog). The only thing one had to configure was chron's timeline for rotating old logs into the trash. Suckily, journald logs grow until they take over something like 10% of disk space by default. To me, it's yet another mistake of the last 8 years of Linux -- adding boggy new application layers instead of improving and simplifying long-standing daemons1. At any rate, journald must be configured if you want anything reasonable and intelligible. Secondly, you must use "journalctl" the read them, because they are stored in a binary format.

Since there are about 30 settings in /etc/journald.conf, you'll have to waste something like an hour researching journald's settings. At the end, this is /etc/journald.conf when I'm troubleshooting.
When I want an ASCII record for grepping, etc, I use journalctl -r -o short-iso ("r" reverses time to put most recent on top, "short-iso" is for giving normal clock timestamps), and save screen output to text:
$ journalctl -r -o short-iso 2>&1 file.txt
Alternatively, one can output other formats such as the apparently standard JSON format. It cannot however export directly to text unless it's to another application.

This the file when the system is running well and no logging is needed:


  • 200K of logging seems to cover about the last 10 boots.
  • journalctl --verify checks logs for corruption

1It's as stupid as when PulseAudio took hold of Alsa (which itself overlaid OSS)