Re: [GTALUG] Stand-alone scanner for Ubuntu?
I just searched for your scanner on the SANE list, as well as a cannon photo printer I'm trying to resurrect from mechanical failure. Your scanner is not on it, so it looks like Simple Scan hooks into the kernel on its own. I also saw a recent post of yours from earlier this year, I forget what forum, where you had already been exploring the udev possibilities. I usually only mess with stock debian and fedora. SElinux gave me a heck of a fight a couple of kernels ago but I was always able to use udev or SElinux itself to overcome the policy issues which were trumping previously working cannon MFP scanner hardware. Pulseaudio is another problematic implementation and I find that some spins manage to hook in correctly and some don't, depending on the kernel. So, on further reflection, it looks like the most current Ubuntu spins are hardwired to always use XHCI. This seems to me to be a transitional problem in upgrading from usb 2.0 to 3.0. If you are able to change this setting with your MB, you might try disabling XHCI in bios. This should force the system to EHCI and might resolve what I'm seeing presented as endpoint block errors in bulk transfers. Might also resolve your USB serial issues. Hope this helps. Russell
| From: Russell Reiter via talk <talk@gtalug.org> | So, on further reflection, it looks like the most current | Ubuntu spinsare hardwired to always use XHCI. This seems to me to be | atransitional problem in upgrading from usb 2.0 to 3.0. If you are able | to change this setting with your MB, you might trydisabling XHCI in | bios. This should force the system to EHCI and mightresolve what I'm | seeing presented as endpoint block errors in bulktransfers. Might also | resolve your USB serial issues. Hope this helps. This sounds crazy. After all USB 3.0 can do anything USB 2 can do. But it isn't. My SnapScan won't work on a USB 3 port with Linux. But it will work with a USB 2 port. Known problem. Surely a kernel bug but no kernel hacker has stepped up to fix it.
On May 7, 2017 11:02:11 PM EDT, "D. Hugh Redelmeier via talk" < talk@gtalug.org> wrote:
| From: Russell Reiter via talk <talk@gtalug.org>
| So, on further reflection, it looks like the most current | Ubuntu spinsare hardwired to always use XHCI. This seems to me to be | atransitional problem in upgrading from usb 2.0 to 3.0. If you are able | to change this setting with your MB, you might trydisabling XHCI in | bios. This should force the system to EHCI and mightresolve what I'm | seeing presented as endpoint block errors in bulktransfers. Might also | resolve your USB serial issues. Hope this helps.
This sounds crazy. After all USB 3.0 can do anything USB 2 can do. But it isn't.
My SnapScan won't work on a USB 3 port with Linux. But it will work with a USB 2 port. Known problem. Surely a kernel bug but no kernel hacker has stepped up to fix it..
Yesterday I installed a Cannon Photo printer which I connected via its onboard USB 3.0. My UDEV saned env rule failed, that is until I added my user to the lp group. Simple Scan had been able to scan after installing the vendors deb package, but only if it was run as root. Xsane did not report a scanner at all, even when tested from root. I added my user to the lp group and bingo, all was well for both apps as a normal user. This was on a usb 2.0 base system while adding the usb 3.0 multifunction scan/print device. I found it somewhat peculiar that the printer part of the photoprinter worked without me being a member of lp and that the scanner part wouldn't work under my user until I was added to the lp group. Perhaps this is a kludgy way to virtualise and offset the greater number of USB 2.0 Endpoint devices which are no longer available under 3.0. The same number of endpoint buffers is theoretically available to both standards, but 3.0 only addresses half the number of Endpoint devices. I wonder, is your user login for Simple Scan a member of the lp group. I ask because I can't test my kludge theory on a machine with no 3.0. ports. My problem was in reverse. A 3.0 device which was attached to a 2.0 usb host. Recognition of bulk MTP transfer request blocks was apparently enabled by adding the user to the lp group. It just so happened that I previously had no printer attached to this machine, just a scanner. I dont see a kernel fix for this to be forthcoming. For one thing, USB 3.0 cuts a potential DWORD jmp vulnurability surface in half. I'm pretty sure thats a good thing on a bus as ubiquitous as usb. The other reason I see is that, soon enough most, if not all, USB 2.0 devices will be dodo's and only cheapo's like me and creative anachronists will have any interest in running obsoleted​ equipment on edge of the art kernels.
--- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
-- Russell Sent by K-9 Mail
participants (3)
-
D. Hugh Redelmeier -
Russell -
Russell Reiter