cyberwizzard.nl

After leaving my printer unused for some time I suddenly found myself unable to print to my Canon ip4300 printer (which is connected using USB and should be run by CUPS). Dmesg showed the following after powering up the printer:

usb 1-3.1: new high speed USB device using ehci_hcd and address 5 
usb 1-3.1: configuration #1 chosen from 1 choice 
usblp0: USB Bidirectional printer dev 5 if 0 alt 0 proto 2 vid 0x04A9 pid 0x10B6 
usb 1-3.1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1 
usb 1-3.1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1 
usb 1-3.1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1 
usb 1-3.1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1

The problem here is the USB Printer subsystem of the kernel called 'usblp'. Some people might have it compiled into the kernel (like me - seemd like a good idea at the time) and others might have it as a module. If you have it as a module, unload it and blacklist it so it won't be loaded automatically. Repower the printer and it should suddenly become available to CUPS.

If you have it compiled in - like I had - recompile your kernel after disabling USB Printing. The device manager will pick it up if you connect it again so the printing subsystem can use it.

On a side note: it would have been nice to have a warning in the kernel description that using printing subsystems will not work properly if you use 'usblp'...

If you are a Bacula user, you most likely had the problem of a Director clogging up on one or more jobs getting stuck while others keep piling up. With the new directives for managing duplicate jobs, this should not happen anymore but last night I found out that 2 of my backup servers managed to dead-lock.

The resulting job queue was over 300 jobs long and restarting the Director did not seem to help. So I threw a little shell script together to use bconsole to cancel all jobs in a waiting state.

Us usual, use on your own risk, I only tested it on my servers and it worked fine…

#!/bin/bash
jobIds=`echo 'status dir running' | bconsole | fgrep 'is waiting' | awk '{print $1}'`
for i in $jobIds
do
    if [ -z `echo "$i" | grep '^[0-9]\+$'` ]
    then
        echo "Error: job ID $i is not a number!"
    else
        echo "Killing waiting Bacula job $i"
        echo "cancel jobid=$i" | bconsole
    fi
done

Looking for instructions to get your latest Logitech webcam to work on linux? Your in the right place! Need a replacement for gspcav1 or spca5xx? Have no clue what I just said but you need a new webcam driver? Please, read on...

If you are running linux and have had the QuickCam Communicate STX for a while (like me) you would probably have started out with the GSPCAV1 package - from 2007.

2007 you ask? Yes, that piece of kit is antique and I couldn't get it to compile anymore on any modern kernel (which you pretty much should have if you are running Gentoo). Not surprisingly though, I was not the only one. Besides, a driver for a common camera should be updated more often and even better: it should be in the kernel tree.

Guess what? It is!

It sounds so simple but if nobody tells you how to upgrade from the gspcav1 driver to the new driver in the 2.6.27+ kernel tree - you'd be stuck, just like I was.

According to the page of the maintainer, pretty much all new Logitech and webcams from other producers work with the new gspcav driver. In my case, my Logitech identifies as 'ID 046d:08d7 Logitech, Inc. QuickCam Communicate STX'.

Instructions:

• Find your camera on the driver list
• Grab a recent kernel (2.6.27+ will do)
• Remember the subdriver name that matches your webcam, mine is zc3xx.
• Configure your kernel:
  • Device Drivers --->
    • Multimedia devices --->
      • <*> Video For Linux
      • [*] Video capture adapters --->
        • V4L USB devices --->
          • <M> GSPCA based webcams --->
            • <M> ZC3XX USB Camera Driver
• Decide whether you want it build in or as a module and compile the kernel
• Check using ' dmesg'  after plugging in if it worked:
  

  gspca: main v2.4.0 registered
  usbcore: registered new interface driver zc3xx
  zc3xx: registered
  usb 4-2.3: new full speed USB device using uhci_hcd and address 9
  usb 4-2.3: configuration #1 chosen from 1 choice
  gspca: probing 046d:08d7
  zc3xx: probe 2wr ov vga 0x0000
  zc3xx: probe sensor -> 11
  zc3xx: Find Sensor HV7131R(c)
  gspca: probe ok
  gspca: probing 046d:08d7
  gspca: probing 046d:08d7
  

If you see a similar output to the above, everything *should* work.

But as always, there is a catch: if you use the latest Nvidia drivers (if you have an Nvidia card of course) you probably have no DGA support because it got dropped (something with DGA needing a static frame buffer address and dynamic memory management on a graphics card - whatever) ad when you try to run something like 'xawtv' you get a warning and only a black image.

This is xawtv-3.95, running on Linux/x86_64 (2.6.29-gentoo-r1)
WARNING: v4l-conf is compiled without DGA support.
/dev/video0 [v4l2]: no overlay support
v4l-conf had some trouble, trying to continue anyway
Warning: Cannot convert string "-*-ledfixed-medium-r-*--39-*-*-*-c-*-*-*" to type FontStruct
no way to get: 384x288 32 bit TrueColor (LE: bgr-)

The reason for this is the fact that xawtv and some others try to get the data through the V4L interface which most of the time comes with a DGA display method... which doesn't work... which means your webcam is working but you can't see it...

This is silly ofcourse and luckely, players like mplayer can use the V4L2 interface as well which allows it to display the feed without a DGA interface. For example to test using V4L2 and mplayer type:

mplayer tv:// -tv driver=v4l2:width=352:height=288:device=/dev/video0 -fps 15

Have fun with your webcam on linux! ^^

After upgrading my laptop to the latest of the latest and even recompiling pretty much the whole system after that, I was still facing a whacky system which crashed on me on seemingly random times.

After a while I noticed that when I log in, hit alt+F2 and fire up 'konsole', the whole X server comes down crashing on me. Resulting in a few seconds of dark terror and a fresh login panel.

After running konsole from a text terminal, I spotted the following errors:

kdeinit4: preparing to launch /usr/bin/konsole
konsole(2671): Attempt to use QAction "change-profile" with KXMLGUIFactory! 
Undecodable sequence \001b(hex)[?1034h

Because any attempt to trace the program failed, I started to search for other people and their solutions.

I've read things about people reinstalling parts of Xorg (namely libX11 as 1.1.5 seems to have some quirks) and parts of Qt 4.5 which should be unstable as well. None of these things worked for me and after restoring the system in the unmodified state, I found someone claiming that removing 'tweaks' in the xorg.conf file for the nVidia driver did the trick.

Although I indeed upgraded the nvidia-drivers package, I thought this was one of the bogus stories (like people solvin mounting problems by unplugging printers on the other side of the globe) - but at this point I had nothing to lose.

To my sheer terror I must admit that it actually worked!

I've had one occasion where konsole started but the window rendering was all screwed up (white or no background or no window decorations) but I hadn't linked it to the display driver itself.

For now, everything is stable so I assume that I found the culprit. Please note that one or more of the following will make your KDE 4.2.2 desktop crash randomly:

• TrippleBuffer
• BackingStore

I have 2 options left in my configuration which are there for a while now and which still seems to be perfectly safe:

• AddARGBVisuals
• OnDemandVBlankInterrupts

Hopefully this post will safe someone a lot of grey hairs and a couple of precious hours spent on a goose hunt...

Add new comment