Ubuntu 16.04 (or any other recent linux) and the Canon LBP6020B laser printer

My last post on battling with the Canon LBP6020 seems to have been quite
populer (my one and only post that regularly appears near the top of a
relevant google search), however it's getting a bit old now (Ubuntu
14.04).

I switched my daily laptop from Ubuntu to Arch Linux about a year ago,
and at the time was able to install the Canon drivers through the AUR
and everything was fine (as much as it ever is with a LBP6020).
Sometime earlier this year a regular update changed all that and it
hasn't worked since.

I finally got around to learning about docker and thought that it might
provide a solution to the LBP6020, i.e. a stable environment in which to
run the driver.

Now thanks to ticosax/cups-in-docker and Nik I've got a docker container
which appears to be reliably printing (although admittedly with only a
little testing).

If you're running Ubuntu 16.04, or any other linux capable of running
docker, this may provide a simple way to get a LBP6020 printing.

The docker image can be built from:

https://github.com/akgrant43/cups-in-docker

Instructions are in the readme.

hstr (hh) and fish

Thanks again to the team at the Ubuntu podcast and their listeners I'm trying out hstr, but unlike Martin, didn't want to switch from fish back to bash, so...

The proper way to do this would be to modify hstr to support the fish history file format, but I wanted to try it out a bit before putting the effort in (if I ever get around to it).

The following steps provide a poor man's port by forcing fish to maintain a bash compatible history file (in addition to fish's own history) and pointing hstr to it:

1. Modify your fish prompt to save the bash compatible history file:

~/.config/fish/functions/fish_prompt.fish:

function fish_prompt
    .
    .
    .
    echo $history[1] | grep -Ev '(^hh$|^sd|^l.$)' >> ~/.config/fish/hh.history
end


The command as written above filters out the hh command itself, my version of cd, sd, and directory list commands such as ls, ll, lh, etc.


2. Set HISTFILE in config.fish:

~/.config/fish/config.fish:

set -x HISTFILE ~/.config/fish/hh.history

If you want your existing fish history to be available immediately, use Martin's command line love from S08E32:

grep cmd ~/.config/fish/fish_history | cut -d' ' -f3- | sort -u >> ~/.bash_history

Alternatively you could just point HISTFILE to ~/.bash_history.

Video capture with the Hauppauge USB-Live2

I'm a bit behind the times and have only just started converting old analogue video tapes to digital format.

I chose the Hauppauge USB-Live2 to perform the analogue to digital conversion, and have been very happy with the results.

The command I used for the capture was:

mythffmpeg -y -loglevel debug -f alsa -i plughw:1,0 -f v4l2 -s pal -pix_fmt yuyv422 -i /dev/video0 -b:v 2048k myfile.nut

on a Mythbuntu 14.04 system, although it should be easily adaptable to other installations, e.g. using ffmpeg instead of mythffmpeg.

The components of the command that may need to be changed:

The Audio input device (plughw:1,0): On my system, executing:

> arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: AD1981 Analog [AD1981 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Cx231xxAudio [Cx231xx Audio], device 0: Cx231xx Audio [Conexant cx231xx Capture]
  Subdevices: 1/1

  Subdevice #0: subdevice #0

Shows that the Live2 (which uses the Cx231xx drivers) is card 1, subdevice 0.  And:

> arecord -L

[... removed irrelevant entries ...]

default:CARD=Cx231xxAudio

    Cx231xx Audio, Conexant cx231xx Capture

    Default Audio Device

sysdefault:CARD=Cx231xxAudio

    Cx231xx Audio, Conexant cx231xx Capture

    Default Audio Device

dmix:CARD=Cx231xxAudio,DEV=0

    Cx231xx Audio, Conexant cx231xx Capture

    Direct sample mixing device

dsnoop:CARD=Cx231xxAudio,DEV=0

    Cx231xx Audio, Conexant cx231xx Capture

    Direct sample snooping device

hw:CARD=Cx231xxAudio,DEV=0

    Cx231xx Audio, Conexant cx231xx Capture

    Direct hardware device without any conversions

plughw:CARD=Cx231xxAudio,DEV=0

    Cx231xx Audio, Conexant cx231xx Capture

    Hardware device with all software conversions

shows that plughw has all the format conversions.  Putting the two together gives plughw:1,0.  I think that plughw:CARD=Cx231xxAudio,DEV=0 will also work, but haven't tested it.

The video device (/dev/video0) can usually be guessed by looking at the output of ls /dev/video*.  If there's only one video device, that's it, if there are two, the first is probably the built in webcam.  If you really want to be sure, look in /var/log/syslog at the time you plugged the Live2 in:

Jan 28 14:30:49 myth kernel: [ 5319.874560] cx231xx #0: cx231xx #0/0: registered device video0 [v4l2]

Jan 28 14:30:49 myth kernel: [ 5319.874652] cx231xx #0: cx231xx #0/0: registered device vbi0

Jan 28 14:30:49 myth kernel: [ 5319.874656] cx231xx #0: V4L2 device registered as video0 and vbi0

The PC I used for transfer doesn't have a webcam, so it is video0, as confirmed in the syslog extract above.

-b:v 2048k specifies the bitrate to record at.  2048k is probably overkill, but I figured that I won't have another chance to capture the tapes, so a little extra disk space isn't worth worrying about.

After capturing the video I trimmed the blank video at the start and end, and fixed the timestamps using:

mythffmpeg -ss -t -fflags +genpts -i myfile.nut -vcodec copy -acodec copy myfile.mkv

Where x is the start offset in seconds, and y is the length of the video in seconds.

Some articles I've read have discussed capturing video simply using:

cat /dev/video0 > file.mpg

this won't work for the Live2 as it is a simple frame-grabber, and doesn't have onboard compression.

The only hiccup in the whole process is that the Live2 more reliable if it is plugged in to a USB port that is using the ehci stack.  Newer computers that support USB3 and use the xhci stack will have problems.  If you want to check, once again looking at /var/log/syslog:

Jan 28 14:30:45 myth kernel: [ 5316.076069] usb 1-6: new high-speed USB device number 3 using ehci-pci

Jan 28 14:30:45 myth kernel: [ 5316.210847] usb 1-6: New USB device found, idVendor=2040, idProduct=c200

Jan 28 14:30:45 myth kernel: [ 5316.210856] usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3

Jan 28 14:30:45 myth kernel: [ 5316.210860] usb 1-6: Product: Hauppauge Device

Jan 28 14:30:45 myth kernel: [ 5316.210863] usb 1-6: Manufacturer: Hauppauge

From the first line above we can see that in this case the Live2 is using a ehci port.

[EDIT 11 APRIL 2015] Kernel 4.0-rc7 includes patches which largely resolve the issues with USB3 / xHCI ports and Intel xHCI controllers.  More specifically, the problem was with Intel xHCI controllers and isochronous USB devices (i.e. video and audio capture devices).  It looks like there are still some issues, however the current hypothesis is that they are issues to do with the cx231xx driver that are triggered by the differences between the eHCI and xHCI drivers.  Depite these issues, if you have an Intel xHCI controller, cx231xx devices are now usable on USB3 ports, and other video / audio capture devices may well work without any problems.  If you're interested in the details, please see: http://www.gossamer-threads.com/lists/linux/kernel/2126922

Many thanks to Devin Heitmueller, Mathias Nyman and Lu Baolu for their assistance it getting the Live2 working for me.

[EDIT 25 Apr 2015] More good news: The patch has been back-ported to 3.19.5, 3.14.39 and 3.10.75.

[EDIT 20 Jun 2015] More good news: Ubuntu kernel 3.19.0-21 (and a couple of earlier version, I think) are based on mainline 3.19.8, which include a few more fixes than mentioned above.