Brother MFC-7220: Scanner allergic to Linux?

Hmmm, mine seems slightly different:


#! /bin/sh
FILE_NAME=/etc/sane.d/dll.conf
OLD_SCRIPT_NAME=/usr/local/Brother/sane/setupSaneScan


case "$1" in
    -i)
    cat << EOF >> $FILE_NAME
brother2
EOF
        if  -e $OLD_SCRIPT_NAME ];
        then
               mv $OLD_SCRIPT_NAME $OLD_SCRIPT_NAME.tmp
           cat ${OLD_SCRIPT_NAME}.tmp | sed 's/brother\/d/^brother$\/d/' > ${OLD_SCRIPT_NAME}
           rm -f ${OLD_SCRIPT_NAME}.tmp
           chmod 755 $OLD_SCRIPT_NAME
        fi
    ;;
    -e)
    mv $FILE_NAME $FILE_NAME.tmp
        cat ${FILE_NAME}.tmp | sed '/^brother2$/d' > ${FILE_NAME}
    rm -f ${FILE_NAME}.tmp
    ;;
    *)
    ;;
esac

Yes, this has already been asked, & i have previously confirmed it. I’ve checked again now, & “brother2” is still therein.

Not good:


gooeygirl@linux-Tower:~> scanimage --test
scanimage: no SANE devices found
gooeygirl@linux-Tower:~> sudo scanimage --test
[sudo] password for root: 
scanimage: no SANE devices found
gooeygirl@linux-Tower:~> 

Here’s another check i did, based on my ongoing research, testing, & swearing. It proved as useless as all else so far.

Reference = Others | Brother support website

Pre-required Procedure (9)
Related distributionsDistributions using firewallRelated products/drivers******scan-key-toolRequirementThe following ports are required to be open.Inbound direction : UDP Port 54925****************Outbound direction : TCP Port 54921Example of the setting location;
******OpenSUSE10.0: Yast-> Security and Users-> Firewall-> Allowed Service->Advanced

And so i did this:
https://paste.opensuse.org/images/79323644.png

I actually did it many days ago [but the settings are still there, i’ve rechecked], & there’s been many reboots since then, but the MFC still refuses to scan.

  1. The firewall port configuration is not relevant to USB connected devices.

  2. Regarding your question about checking the device node permissions…for bus 00x, device 00y do…

ls -l /dev/bus/usb/00x/00y
  1. This is potentially of interest…
gooeygirl@linux-Tower:~> **dmesg --follow**
[10730.413791] usb 3-5: USB disconnect, device number 3      #The MFC-7220 was still plugged in at this point, so then i unplugged it.
[10730.413978] usblp0: removed
[10740.436413] usb 3-5: new full-speed USB device number 10 using xhci_hcd    #The response to me plugging it back in.

The xhci_hcd driver is handling your host controller, and in the past at least, this has been problematic with some older USB1/USB2 hardware. This may or may not be an issue here. Some more research needed…

Oh. Brother’s documentation leaves a LOT to be desired.

Thanks:


gooeygirl@linux-Tower:~> **lsusb**
Bus 002 Device 002: ID 8087:8001 Intel Corp. 
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8009 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
**Bus 003 Device 011: ID 04f9:0185 Brother Industries, Ltd MFC-7220 Printer**
Bus 003 Device 009: ID 045e:0039 Microsoft Corp. IntelliMouse Optical
Bus 003 Device 007: ID 413c:2003 Dell Computer Corp. Keyboard
Bus 003 Device 008: ID 413c:2010 Dell Computer Corp. Keyboard
Bus 003 Device 006: ID 413c:1003 Dell Computer Corp. Keyboard Hub
Bus 003 Device 005: ID 0461:4d81 Primax Electronics, Ltd Dell N889 Optical Mouse
Bus 003 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 003 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


gooeygirl@linux-Tower:~> **ls -l /dev/bus/usb/003/011**
crw-rw-r--+ 1 root lp 189, 266 Oct  6 19:09 /dev/bus/usb/003/011


gooeygirl@linux-Tower:~> 

Should i be bothered about the fact that [it feels like] each time i look sideways at this MFC, it changes its bus# &/or device# ?

Oh, well… given i don’t know which way is up anymore, in this intractable >3yr MFC pain, i don’t even know enough to know what specific research i need to do. Suspect i’m very close to abandoning this quest…

FWIW, I found this German wiki page which corroborates my earlier comments about the XHCI driver not playing nicely with some older USB hardware (in some circumstances). Translated via google translate

Scan to the USB 3.0 port

Under certain conditions, the scan process will not start if an older Brother model is connected to a USB 3.0 port. This compatibility issue between the USB 2.0 device and the USB 3.0 system may be caused by the hardware / firmware of the scanner, the EFI / BIOS firmware, the USB chipset, or the Linux kernel driver xhci_hcd . In this case, the scan program outputs the error message " InvalidArgument ". If the computer has a USB 2.0 port, you can connect the scanner there. If necessary, USB 3.0 can also be disabled in the EFI / BIOS settings. However, the faster USB 3.0 is switched off system-wide for all ports.

As an experiment, see if your BIOS supports inhibiting XHCI (USB3) mode somehow.

As an experiment, see if your BIOS supports inhibiting XHCI (USB3) mode somehow.

And this now marks the formal end of my desire to solve this defect. You see, even if disabling my USB3 ports [which i do NOT use with this MFC, but which i [b]do use regularly with my USB3 sticks] magically made my MFC rediscover that it is supposed to be a scanner as well as a printer, that would be a price i’m not prepared to pay. As convenient as it’d certainly be to be able to scan in Linux rather than have to use my Win10 VM, it’d be far more inconvenient to effectively lose my USB3 sticks’ speed benefit compared to usb2. I use those sticks much more often than i scan.

I’d really sincerely like to thank you & all the others] for your wonderful dogged support in helping me in this battle. Onward & upward, or something.
:wink:

Fair enough.

Arrrrg, I have been watching GooeyGirl do all the hard work as I have been working similar(same) issue, but luckily for only a few days.
My first thought, pleassseeeeeee don’t give up.

But I certainly understand addiction to USB3 sticks.

So here are my follow-on results for my issue, which certainly looks like GooeyGirls but slightly different.

My Brother is an MFC-L2700DW.
it is a brscan4 machine.

My computer is all USB3 ports.
I blocked xhci in bios, Initial testing looks good.
I can (finally) manually scan (flatbed mode), I have not yet tried MFC originated scans but will soon.

Here is some info

sudo brsaneconfig4 -d
[sudo] password for root: 
-----------------------------
cat /etc/fstab
UUID=d16b7198-33ab-4315-9807-b4362c6c2bee /                    ext4       noatime,acl,user_xattr 1 1
UUID=2a5f7005-18b8-4c44-826a-fcd77523ef0a swap                 swap       defaults              0 0
UUID=EACA-EE55       /boot/efi            vfat       umask=0002,utf8=true  0 0
UUID=470939b8-9894-47ed-b351-2e8b06a12702 /home                ext4       defaults              1 2
tmpfs   /tmp    tmpfs   defaults,noatime,mode=1777 0 0 
tmpfs   /var/tmp        tmpfs   defaults,noatime,mode=1777 0 0 
/dev/mapper/cr_backupSRV7           /backupSRV7             ext4       acl,user_xattr,nofail    0 2
/dev/mapper/cr_loop1           /home/carl/srvc2             ext4       noauto,rw,acl,user_xattr,nofail    1 1
-----------------------------
sane-find-scanner

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
found USB scanner (vendor=0x04f9 [Brother], product=0x0331 [MFC-L2700DW]) at libusb:001:003
could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
found USB scanner (vendor=0x0cd2, product=0xffff) at libusb:002:006
found USB scanner (vendor=0x04b8 [EPSON], product=0x0142 [EPSON Perfection V33/V330]) at libusb:002:005
could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
could not fetch string descriptor: Pipe error
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backend's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.
-----------------------------
ls -R -all /proc/bus/usb
ls: cannot access '/proc/bus/usb': No such file or directory
-----------------------------
cat /proc/bus/usb/devices
cat: /proc/bus/usb/devices: No such file or directory
-----------------------------
scanimage -L
device `brother4:bus4;dev1' is a Brother MFC-L2700DW USB scanner
device `epkowa:interpreter:002:005' is a Epson Perfection V330 Photo flatbed scanner
-----------------------------
-----------------------------
/etc/opt/brother/scanner/brscan4//brsanenetdevice4.cfg:
-----------------------------
/etc/opt/brother/scanner/brscan4//Brsane4.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_7.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_1.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_6.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_5.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_2.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_17.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_4.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_8.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_15.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_3.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_9.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_13.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_11.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_18.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_19.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_12.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_14.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_10.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_16.ini:
-----------------------------
/etc/opt/brother/scanner/brscan4//models4/ext_20.ini:
-----------------------------
-----------------------------
ping

Not sure what else I could post that would be informative or helpful to others.

Here is a remove/re-insert

dmesg --follow
 1319.914420] usb 1-1.1: USB disconnect, device number 3
 1319.914502] usblp0: removed
 1322.593704] usb 1-1.1: new high-speed USB device number 4 using ehci-pci
 1322.688255] usb 1-1.1: New USB device found, idVendor=04f9, idProduct=0331
 1322.688257] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
 1322.688258] usb 1-1.1: Product: MFC-L2700DW
 1322.688259] usb 1-1.1: Manufacturer: Brother
 1322.688259] usb 1-1.1: SerialNumber: U63887G7N370957
 1322.689399] usblp 1-1.1:1.0: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0331

Aside from potential success, today I learned about dmesg --follow. Thanks!

Before blocking xhci, my thought plan was to try accessing scanner via network (IP address) connection,
since certain things just did not look right with USB. I will try that one I go back to xhci enabled.

The MFC-L2700DW is new to me, not sure if is to be considered ‘older’ hardware.
but add brscan4 to the list of drivers that appear to be allergic to xhci.

I’m using a Brother DCP-7055 multifunction device for scanning at home. It uses the ‘brother4’ backend as well. Thankfully, my laptop has USB2 and USB 3 ports. Only the USB 2 ports (supported by the ehci-pci driver) allows me to scan successfully, matching your experience as well. When I try scanning (eg via simple-scan or xsane) from a USB 3 port I note the following kernel output

 1720.229329] usb 3-1: usbfs: interface 0 claimed by usblp while 'scan-thread' sets config #1
 1720.229344] usb 3-1: usbfs: process 4061 (scan-thread) did not claim interface 1 before use
 1721.307310] usb 3-1: usbfs: interface 0 claimed by usblp while 'scan-thread' sets config #1
 1721.307316] usb 3-1: usbfs: process 4061 (scan-thread) did not claim interface 1 before use
 2091.594894] usb 3-1: usbfs: interface 0 claimed by usblp while 'scan-thread' sets config #1
 2091.594904] usb 3-1: usbfs: process 4061 (scan-thread) did not claim interface 1 before use
 2092.672873] usb 3-1: usbfs: interface 0 claimed by usblp while 'scan-thread' sets config #1
 2092.672877] usb 3-1: usbfs: process 4061 (scan-thread) did not claim interface 1 before use
 2107.607677] usb 3-1: usbfs: interface 0 claimed by usblp while 'scan-thread' sets config #1
 2107.607683] usb 3-1: usbfs: process 4061 (scan-thread) did not claim interface 1 before use
 2108.866175] usb 3-1: usbfs: interface 0 claimed by usblp while 'scan-thread' sets config #1
 2108.866188] usb 3-1: usbfs: process 4061 (scan-thread) did not claim interface 1 before use
 2168.796011] usb 3-1: usbfs: interface 0 claimed by usblp while 'xsane' sets config #1
 2168.796043] usb 3-1: usbfs: process 4086 (xsane) did not claim interface 1 before use
 2174.796354] usb 3-1: usbfs: interface 0 claimed by usblp while 'xsane' sets config #1
 2174.796360] usb 3-1: usbfs: process 4086 (xsane) did not claim interface 1 before use

Before blocking xhci, my thought plan was to try accessing scanner via network (IP address) connection,
since certain things just did not look right with USB. I will try that one I go back to xhci enabled.

Network scanning should just work as the XHCI driver is only related to USB-connected devices.

The MFC-L2700DW is new to me, not sure if is to be considered ‘older’ hardware.
but add brscan4 to the list of drivers that appear to be allergic to xhci.

This is not just limited to Brother devices. There’s been a number of bug reports describing various issues (mostly around device initialisation) usually characterised by full/high speed devices connected to XHCI controller interfaces.

On the same topic, some historic reports…
https://forums.opensuse.org/showthread.php/504397-USB-Scanner-disappears-after-some-seconds-of-system-runtime?p=2689744#post2689744
https://bugzilla.redhat.com/show_bug.cgi?id=1011238

This bug report comment (from maintainer Johannes Meixner) caught my attention…

The sane-backends version 1.0.27 release contains
in particular this change regarding USB3
for details see http://www.sane-project.org/

  • Updated Linux USB3 workaround (see Note 3).

    Note 3: The Linux USB3 workaround which was added
    in version 1.0.25 is now disabled by default.
    If you have difficulty using a scanner which previously worked,
    or intermittent scanner availability, try setting the new
    environment variable SANE_USB_WORKAROUND=1
    before starting your frontend.

I assume the issue is fixed in sane-backends version 1.0.27.

https://wiki.archlinux.org/index.php/SANE#Communication_via_xHCI_not_working_.28older_scanner_models.29

Communication via xHCI not working (older scanner models) Some older scanner models do not work when connected via an USB3 port. If you experience this issue, try setting the SANE_USB_WORKAROUND=1 environment variable before starting your frontend.[1]]([sane-announce] Sane-backends 1.0.27 has been released)[2]](https://anonscm.debian.org/cgit/sane/sane-backends.git/commit/?id=1207ce5a40664c04b934bd0a6babbc1575361356)
If that does not work, try one of the following workarounds:

  • Use an USB2 port instead of an USB3 port, if available.
  • Disable xHCI via BIOS/EFI. eHCI will consequently be used and communication with the scanner will work. On the downside, USB3 speed can not be reached on any port.
  • On (some) intel chipsets the setpci command can be used to route specific usb ports to either the xHCI or the eHCI controller. See here and here (scroll down to where it says “setpci”) for further information. With this it is possible to toggle single USB ports with a simple shell script.
  • Connect the scanner over the network instead if it is supported.

The ‘setpci’ approach to configuring a particular Intel-based usb port to USB 2 mode might be a viable option for some users with Intel cUSB host controller chipsets. I recall this opensuse thread where one user reported success with it (as also linked to in the archlinux wiki page). The advantage with doing this is that the remaining USB ports are left as default for use with USB 3 capable devices.

Good stuff, deano, as usual

I will report back on my Network connection success.

Hi & thanks very much for your interesting input, cmcgrath5035](https://forums.opensuse.org/member.php/539-cmcgrath5035)

Thanks for your latest info deano](https://forums.opensuse.org/member.php/122-deano_ferrari) - against my better judgement, & offering an uncomfortable insight into my possible masochism quotient, as time allows i might try to follow-up on your

‘setpci’ approach to configuring a particular Intel-based usb port to USB 2 mode

As far as i know the MFC-7220 has no network capability. It does have an alternative parallel port connection mode, which alternative excited me only for as long as it took me to remember that my Tower has no parallel port [ditto my Lappy] - ha! I continue to admire Brother’s skill & dedication in providing me with exemplary Linux Torment, heehee.

I had a quick play with this tonight, and started with ‘/sbin/lspci’ to get my PCI bus address

00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)

I read the bit configuration pertaining to USB2/3 mode settings.

# setpci -H1 -s 00:14.0 d0.L
0000000f  

Only 4 bits to deal with in my case (and actually only 2 physical XHCI ports to choose from). On a particular USB port I plugged in my scanner and observed the ‘dmesg -follow’ output in another terminal window. With all bits set this behaved as an XHCI controller. After a bit of experimentation I quickly established the last bit pertained to this particular port, so setting a value of ‘e’ (1110) did the trick for setting this (and only this port) to USB 2 mode…

linux-54cw:/home/dean # setpci -H1 -s 00:14.0 d0.L=E

Confirmed by reading it back…

linux-54cw:/home/dean # setpci -H1 -s 00:14.0 d0.L
0000000e

Here’s the kernel output reflecting the scanner being plugged in to a port now handled by the EHCI driver…


 2168.730139] usb 2-1.1: new high-speed USB device number 12 using ehci-pci
 2168.824016] usb 2-1.1: New USB device found, idVendor=04f9, idProduct=0248
 2168.824021] usb 2-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=3
 2168.824023] usb 2-1.1: SerialNumber: E69893D1N337394
 2168.825229] usblp 2-1.1:1.0: usblp0: USB Bidirectional printer dev 12 if 0 alt 0 proto 2 vid 0x04F9 pid 0x0248

I didn’t make this permanent - it was only for experimental purposes, but I can confirm that it worked as expected for me. It means that I can explicitly configure a given port for use with my scanner (although this laptop actually has a dedicated USB 2 port available already). The openSUSE post I linked to shows how to make it persistent by use of a script executed at boot via the rc-local.service if desired. Thanks to user debruyck for sharing this approach in that thread. YMMV.

G’day deano – ha, i just realised i have slightly caught up to you as of last weekend; now only 2 hrs behind you rather than the erstwhile 3.

Coincidentally i was reading your recent links just as your new post arrived. What you’ve done is rather brilliant, & possibly might crack my problem, though i’m far too cynical & crotchety to feel optimistic ahead of time.

gooeygirl@linux-Tower:~> **/sbin/lspci
**00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
**00:14.0 USB controller: Intel Corporation 9 Series Chipset Family USB xHCI Controller**
00:16.0 Communication controller: Intel Corporation 9 Series Chipset Family ME Interface #1
**00:1a.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #2**
00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller
00:1c.0 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 1 (rev d0)
00:1c.2 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 3 (rev d0)
00:1c.3 PCI bridge: Intel Corporation 9 Series Chipset Family PCI Express Root Port 4 (rev d0)
**00:1d.0 USB controller: Intel Corporation 9 Series Chipset Family USB EHCI Controller #1**
00:1f.0 ISA bridge: Intel Corporation 9 Series Chipset Family Z97 LPC Controller
00:1f.2 SATA controller: Intel Corporation 9 Series Chipset Family SATA Controller [AHCI Mode]
00:1f.3 SMBus: Intel Corporation 9 Series Chipset Family SMBus Controller
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
03:00.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 41)
gooeygirl@linux-Tower:~> 

As you can see, that’s for my Tower. My Lappy instead has Series 5. For the time being i’ll just stay focused on Tower, as it’s my primary pc & the one more likely to need to do scanning. Given it’s Series 9, does that mean i can more or less “borrow” the fine solution of debruyck directly, per their https://forums.opensuse.org/showthread.php/507627-Suse-13-2-scanner-no-longer-working-on-64-bit-version?p=2714695#post2714695 … or [as i suspect] do i need to do the proper port investigation [which i don’t yet fully grasp, but i’ll keep re-reading] per your latest post, specific to my own box?

However, all that is jumping ahead of what IMO is the most basic starting question… as i have previously posted, i am already using a USB2 port for the cable to the MFC, not a USB3 port. Their, & your, solution method seems predicated on “converting” a target USB3 port into USB2 for the purposes of the scanner. If my port is already USB2, what’s the point of me bothering to proceed with this method; aren’t i just setting myself up for just another disappointing failure?

Yes, good to be on daylight saving time again in this part of the world.

As you can see, that’s for my Tower. My Lappy instead has Series 5. For the time being i’ll just stay focused on Tower, as it’s my primary pc & the one more likely to need to do scanning. Given it’s Series 9, does that mean i can more or less “borrow” the fine solution of debruyck directly, per their https://forums.opensuse.org/showthread.php/507627-Suse-13-2-scanner-no-longer-working-on-64-bit-version?p=2714695#post2714695 … or [as i suspect] do i need to do the proper port investigation [which i don’t yet fully grasp, but i’ll keep re-reading] per your latest post, specific to my own box?

Start by examining the value returned by…

setpci -H1 -s 00:14.0 d0.L

However, all that is jumping ahead of what IMO is the most basic starting question… as i have previously posted, i am already using a USB2 port for the cable to the MFC, not a USB3 port.

The output you shared back in post #37 of this thread confirmed you were plugged in to a port associated with an XHCI controller…

[10740.436413] usb 3-5: new full-speed USB device number 10 using xhci_hcd

Did you try attaching to different ports? (Assuming one or two might be USB 2 only?)

Their, & your, solution method seems predicated on “converting” a target USB3 port into USB2 for the purposes of the scanner.

Specifically, it’s about configuring a given port to behave as a USB port (ie connected to an EHCI controller).

If my port is already USB2, what’s the point of me bothering to proceed with this method; aren’t i just setting myself up for just another disappointing failure?

Well, the only output you’ve shared so far showed XHCI controller. As above, if you do have a USB 2 port available then scanning should just work.

Hey, is this the answer to my previous final paragraph?

I revisited your https://forums.opensuse.org/showthread.php/527332-Brother-MFC-7220-Scanner-allergic-to-Linux?p=2840770#post2840770 , in which you noted this:

  1. This is potentially of interest…

gooeygirl@linux-Tower:~> dmesg --follow
[10730.413791] usb 3-5: USB disconnect, device number 3 #The MFC-7220 was still plugged in at this point, so then i unplugged it.
[10730.413978] usblp0: removed
[10740.436413] usb 3-5: new full-speed USB device number 10 using xhci_hcd #The response to me plugging it back in.

The xhci_hcd driver is handling your host controller…

At the time, the significance of your observation had partly escaped me. But now, re-reading debruyck’s https://forums.opensuse.org/showthread.php/507627-Suse-13-2-scanner-no-longer-working-on-64-bit-version?p=2714695#post2714695 , & focusing on their

On reading about USB protocols and controllers it turns out that xHCI refers to a USB3 controller and eHCI to a USB2 controller.

…then putting 2 & 2 together leads to an apparent revelation. The port on my Tower in question, is “supposed” to be only USB2, not 3 [both from the vendor’s specs, & the observation that the port is grey/black not blue]. But you have discovered, from my unwitting info already posted, that in fact it’s actually USB3, or at least [somehow] being controlled by the USB3 driver.

If that’s true [have i understood correctly?] then it’s no wonder at all why my Linux scanning has never worked! Again, if that’s true, then the “deano / debruyck” method is certainly worth me trying.

Rats, my post was redundant.

Must type faster…

Yes, it came to my attention because of the reference to the XHCI driver in your output (and I was already suspicious of it, as I think Knurpht was as well if you read back through his replies). No harm in experimenting with ‘setpci’ to determine the appropriate bit for setting a given port to EHCI mode IMHO. Just some time and effort required. :slight_smile: