Started by zachary, January 11, 2014, 10:38:14
Quote from: zachary on January 11, 2014, 10:38:14First of all xsane (but in general everything sane-related, it seems) takes a lot to scan for devices, about 35 seconds before showing the device dialog. It's not clear to me if that is normal or not. Any takers? If it is "normal", is there a way to avoid the device scanning and reuse the results from the last run? I'd be particularly cool if that could be done even when xsane is invoked by other applications, and most notably gimp.
Quote from: zachary on January 11, 2014, 10:38:14It looks like a bug in the scanner firmware, but it's probably one which is caused by xsane and/or the suld driver (because otherwise there will be way more people than me complaining about this over the net... :)).Any idea about how to fix / work around this?
Quote from: bchemnet on January 12, 2014, 11:56:16Since it seems to be using the xerox-mfp backend, I would guess that's where the problem lies, not the Samsung driver.
Quote from: bchemnet on January 12, 2014, 11:56:16There is a newer version of sane available (1.24 and 1.25 in development) than is currently in the Debian repositories, you could try installing that and see if it resolves the problem. Otherwise I would suggest filing a bug report with the SANE project, and/or searching their reports for something similar that may provide a clue to a work-around.
Quote from: zachary on January 12, 2014, 12:02:09Are there other backends that I could/should use? I went for the xerox-mfp because that's what I've seen mentioned on the suld website and in other replies on this forum. In fact, I wasn't entirely sure about whether which one I should use between xerox-mfp and xerox-mfp_smfp... If there are alternatives I should try, I'm all ears! :)
Quote from: zachary on January 12, 2014, 12:02:09I'll give newer sane versions a try. Still, it seems to me that there is arguably a bug *also* in the scanner firmware. It is definitely inappropriate for it to reboot, no matter what the client is telling it over the network.
Quote from: bchemnet on January 12, 2014, 13:51:41xerox-mfp_smfp is not a real backend, it still refers to xerox-mfp. The only other thing to try is to not specify a backend at all and see if it picks up the suld backend (which can't be forced, because it isn't a SANE component).
Quote from: zachary on January 12, 2014, 15:15:15Thus far I had used the expression "specify a backend" to mean that I've added the "tcp..." line to a specific file under /etc/sane.d. So I've specified the xmfp_mfp backend only in the sense that it is at the end of /etc/sane.d/xmfp_mfp.conf my "tcp..." line. Where should I put it instead not to specify a backend, and trying that way to have the suld backend picked up?
Quote from: bchemnet on January 12, 2014, 17:41:59In theory, the suld driver should be able to work with the scanner without modifying anything. So simply remove anything you have added to the .conf file.
Quote from: zachary on January 13, 2014, 02:41:38If it is via some network auto detection, that implies (I suspect) configuration of other services to that end, such avahi or equivalent.If I'm on the right track, can you clarify which mechanisms suld uses to find the scanner address?