SANE crashy crashy

I spend quite a lot of time triaging bugs in Fedora for stuff I maintain upstream. The most common crasher bug I come across is colord segfaulting deep in libsane. Digging even more, 99% of those libsane crashers are when the user has installed closed source binary drivers to make the scanner “work”.

Of course, segfaulting colord just because it automatically assigns color profiles to scanners is not a good idea, even if we can blame non-free code. Something had to be done, as it was starting to make colord look bad as all the display and print color management would suddenly stop working in quite a dramatic way.

Now, in an ideal world, there would be a scanner daemon, scannerd, that I could patch for colord support, just like we’re doing for printers and dispays. This would then register devices with colord, and if it crashed, it could be autorestarted. Such a thing doesn’t exist, and so I had to do something that involved separating the libsane code from the main colord process.

In git master I’ve added a tiny dbus daemon called colord-sane, that basically does nothing except for rescanning sane whenever a USB device is plugged in and creating and deleting devices in colord. It only has one method “Refresh” and it is started when colord is started (usually in early boot) if the UseSANE=true option is specified in /etc/colord/colord.conf

In an ideal world, someone could take that code, and make a proper scannerd or saned project that adds some DeviceAdded and DeviceRemoved signals, a GetDevices() method and some more properties on each device, hopefully using something l33t like GDBusObjectServer. This would mean that the session could just use that for device discovery (e.g. in Simple Scan) and the world would be a much nicer place.

So, if you see a tiny colord-sane process show up in your system that’s not doing anything, don’t panic. You can disable the functionality if you know you’ll never have a scanner attached.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

8 thoughts on “SANE crashy crashy”

  2. Surely the main colord could start colord-sane on demand by sending a message to it then a usb device is plugged in. There is no need to keep it around indefinately.

    1. There’s no way of knowing if a usb device is a scanner without calling into sane. SANE really isn’t a very good modern library, but it’s main benefit is that it supports basically every scanner ever made. :( We also don’t want to autostart it each time as want to rate limit the number of times we call sane_init in a given number of seconds as it can take quite a lot of time to startup.

      Basically, a seporate process is a shit-ton less work than re-inventing libsane.

        1. So how do we detect a device being removed? The only way to know what device was removed is to compare the SANE device lists before and after a device is removed. We’d need to dump the device states to disk and load it on startup if we auto-exited after a couple of seconds.

      2. How about spawning colord-sane on any USB attach event? It could listen for detach events and do the SANE list-comparison after each one.

Comments are closed.