[GTALUG] Stand-alone scanner for Ubuntu?

[Russell]

On May 7, 2017 11:02:11 PM EDT, "D. Hugh Redelmeier via talk" <
talk at gtalug.org> wrote:
>| From: Russell Reiter via talk <talk at 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 at gtalug.org
>https://gtalug.org/mailman/listinfo/talk

-- 
Russell
Sent by K-9 Mail