Arch Linux User Repository

Works great with simple-scan and Brother DCP-L3551CDW. Thanks a lot.

@PC2022: Thanks for sharing your findings. I don't know this particular model, I have a ADS-3000CN here which has a web interface to set some of the basic settings i.e. paper size.

Here's my findings for a Brother ADS-2600W using scanimage (multiple pages, A4, double sided, PDF output)

To scan more than one page, you need to use --batch, which also means you cannot specify an output filename using -o. Instead the scan is written to current directory as out1.pdf

To scan A4, you also need to specify the document height in mm, otherwise it defaults to 410mm which is far too long.

scanimage -d 'brother4:net1;dev0' --source='Automatic Document Feeder(left aligned,Duplex)' --mode='24bit Color[Fast]' --resolution=600 --format=pdf --batch -y 298

Works with xsane on Brother MFC L3750 CDW (with the printer being auto detected CUPS; not using the dedicated printer package) Thx!

@Konzertheld: your MFC-L2710DN seems to be connected by Ethernet, is it really so? Did you try connecting via USB? Also, how well does it react to printing requests?

Glad it's not my fault ;) Hope you find the problem. Anyway, thanks for reporting back.

@Harvey XSane doesn't work for me, scans only one page, but I just tested scanadf and it worked, so not an issue with this package I suppose.

@Konzertheld: Just tested with XSane under Wayland - works... But I am not a crack concerning Wayland as my laptop freezes the GUI when using a second monitor. So there might be more than meets the eye ;)

Hello, I've been having trouble scanning since I switched from Gnome+X to Gnome+Wayland, so I kindly ask for assistance in searching for the error, be it Wayland related, related to re-installing the system (which I did at the same time) or something else just coinciding with the other two. These problems are not related to the April 21st update of this package, they were there before.

a) After every reboot, I have to enter my root password when I scan something for the first time. I use simple-scan and when I close it afterwards and open it later without reboot or logging out, no password is needed.

b) Worse, I can only ever scan one page from the ADF. The scanner pulls the others and simple-scan waits for it to do so but does not scan them, it only retrieves the first one and then throws a kinda generic error message after the last page has been pulled through by the scanner.

c) Also, I used to see the progress of the page while being scanned. Now I only see the page pop up as whole after it was scanned.

For the sake of readability, I pasted my log elsewhere. Also note how slow everything is. I use a MFC-L2710DN as can be seen there. https://pastebin.com/skCX4dFV

Thanks for reading.

@maxfranco: Well looking into this I found that libavahi-client.so.3 is a dependency brought in by sane. It seems the -q query option depends on this (which makes perfect sense) - but there is no need to include it as sane should pull it in anyway.

@maxfranco: will take a look as soon as possible. Namcap is throwing some more errors I will have to investigate, but it does not point out avahi as a missing dependency. As it is working for you with avahi installed it is not completely broken at least ;)

@ Harvey i'm working with a MFC-J470DW wifi scanner. I installed brscan4 then tried to add my scanner with: brscan4 -a brsaneconfig4 -a name=MFC-J470DW model=MFC-J470DW ip=192.168.x.x

brscan4 complains for missing libavahi-client.so.3 and don't let my add my scanner i installed avahi to solve the problem now i have removed avahi and i can anyway add new scanner, but the brsaneconfig4 -q problem persist brsaneconfig4 -q /opt/brother/scanner/brscan4/brscan_cnetconfig: error while loading shared libraries: libavahi-client.so.3: cannot open shared object file: No such file or directory installing again avahi fix it. sudo brsaneconfig4 -q * MFC-J470DW [ 192.168.x.x] MFC-J470DW

@maxfranco: Please provide more information. Network or USB scanner, scanner model, which frontend do you use, are there any error messages, which steps did you take to use your scanner. Without this I can only tell that for me it works without avahi...

There is a missing dependency, without avahi (libavahi-client.so.3) it's impossible add or query scanners.

Systemd developers seem to be unsure about this case subject too: https://github.com/systemd/systemd/issues/5642 ☺

@ettavolt

Thanks, the workaround did the trick, though now it's fixed :)

@Harvey

I removed the udev rule, updated the package and rebooted for good measure, now I can confirm it's working perfectly, so the suspicions may have been correct.

Thank you both!

@Sondeluz, sorry, I've copy-n-pasted != for the idProduct check in the proposed rule. It should have been

ACTION=="add" ATTR{idVendor}=="04f9" ATTR{idProduct}=="041f" ENV{libsane_matched}="yes"

@Sondeluz: Please try again with -5 (Converted to uppercase as used in 20-sane.hwdb)

Hello!

The command returns libsane_matched=yes

Yes, I am the only user on a Plasma/X session with systemd indeed.

I had no luck with the udev rule, the (same) error keeps appearing.

Oh, this is much better!

Thank you for testing the change, I'm sorry that it disrupted your system even though that everything is seem to be correct.

What does the following command return in your environment?

systemd-hwdb query usb:v04f9p041f

Just to reconfirm: when you try to scan, you're the only user in the system and have a graphical session, driven by systemd, correct?

For an immediate remedy I suggest creating /etc/udev/rules.d/20-dcp-l2510d.rules with the following contents:

ACTION=="add" ATTR{idVendor}=="04f9" ATTR{idProduct}!="041f" ENV{libsane_matched}="yes"

I'm planning to have a testing session myself in a couple of days, maybe I find the package bug actually. My suspicion is that we need uppercase HEX in the hwdb in contrary to rules…

Sorry! I wasn't specific enough. This comes directly from the desktop scanner application, the printer itself was and is working nicely using brscan4 on Fedora, for example. It's a DCP-L2510D connected via USB, nothing fancy.

Both skanlite, simple-scan and xsane report I/O errors since the update. Here's what simple-scan complains about for example when running it with --debug:

[+3,50s] DEBUG: scanner.vala:341: sane_get_devices () -> SANE_STATUS_GOOD

[+3,50s] DEBUG: scanner.vala:353: Device: name="brother4:bus2;dev3" vendor="Brother" model="DCP-L2510D" type="USB scanner"

[+3,61s] DEBUG: app-window.vala:2080: Saving state to /home/sam/.cache/simple-scan/state

[+10,53s] DEBUG: app-window.vala:2080: Saving state to /home/sam/.cache/simple-scan/state

[+10,64s] DEBUG: simple-scan.vala:1819: Requesting scan at 300 dpi from device 'brother4:bus2;dev3'

[+10,64s] DEBUG: scanner.vala:1704: Scanner.scan ("brother4:bus2;dev3", dpi=300, scan_mode=ScanMode.COLOR, depth=8, type=single, paper_width=0, paper_height=0, brightness=0, contrast=0, delay=0ms)

[+10,64s] DEBUG: scanner.vala:837: Processing request

[+10,64s] DEBUG: scanner.vala:898: sane_open ("brother4:bus2;dev3") -> SANE_STATUS_IO_ERROR

[+10,64s] WARNING: scanner.vala:902: Unable to open device: Error during device I/O

Sorry, we can't help you with the information you've provided. Our printers don't show anything like this on their dot-led displays. ☺

Maybe that is an error in the output of some application or service? Which one? How is it launched?

I honestly fail to understand these changes, but if it is of any help, my printer now throws "Failed to open device 'brother:bus4;dev1': Error during device I/O." since the last update.

@applebloom recent version doesn't install anything /etc/udev, please update.

Hi. I noticed that udev rules are installed in /etc (/etc/udev/rules.d/40-brscan4.rules). Shouldn't they go into /usr/lib/udev? Etc should be only for local configuration only, I think.

@markuschaaf, the setup with rules adding 'scanner' group is package-specific. Sane's way is to add libsane_matched=yes to scanner devices and let some 'base' rule to react to this env. Particularly, /usr/lib/udev/rules.d/66-saned.rules runs /usr/bin/setfacl -m g:saned:rw $env{DEVNAME} for these.

You should probably tweak your service launchers to start under 'saned' group instead of 'scanner'.

Alternatively, add a copy of that rule in, say, /etc/udev/rules.d/66-scanner.rules with 'saned' group replaced by 'scanner'.

Note: both tweaks will leave all scanners (not just those supported by brscan4) equally accessible.

Group based permission management is deprecated in Arch and repo packages are moving away from it. It's hard to blame AUR package for doing exactly the same what repo package did. It's more a standard than a fashion. One of the points of systemd dynamic permission model is to differentiate between local and remote user permissions. Users are free to modify this behavior as they wish.

What's the purpose of using hwdb, besides "because you can"? Supporting the scanner group has a real world use case: I can use the scanner from other services beside saned and over ssh, which is what I do. Now the package is broken for me and I have to roll my own. The udev-rules I had sent @Harvey worked for everyone. I don't know what's the reason for those commenters here pushing their unjustified but fashionable ideas.

Sorry, still didn't manage to bring my Arch installation to the device.

I can say that systemd-udevd accepts the new file at least.

Ok, although I am not fully convinced yet I made up my mind to sync with sane's behavior. Pushed a new package Version with udev-hwdb support. Lets see what happens (Fingers crossed).

I think when provided udev+hwdb approach will work here then other packages will follow (if they are still maintained). Someone must go first.

@ettavolt: Did you test it? I only have networked devices here so this is rather like flying blind for me :( I had a look at your PKGBUILD. Does this work for you? Meanwhile I looked at the other brscan incarnations (2/3/5) in AUR, none of them is using udev+hwdb... I feel if we decide to go this way, at least all should do the same. And the Arch wiki should be corrected as well: https://wiki.archlinux.org/index.php/CUPS/Troubleshooting#Conflict_with_SANE

@ettavolt: Did you test it? I only have networked devices here so this is rather like flying blind for me :( I had a look at your PKGBUILD. Does this work for you? Meanwhile I looked at the other brsan incarnations (2/3/5) in AUR, none of them is using udev+hwdb...

Yes, like this: https://github.com/ettavolt/aur-brscan4/commit/3680c46f83ec7909e433cebfae4d0c92cdb98238

Let me test it though. ☺

My understanding is if you add right device id to hwdb then systemd will take care of permissions (it will grant permission for currently logged user regardless of any groups set).

I think the request from https://aur.archlinux.org/packages/brscan4/#comment-793321 was about generating .hwdb file with device ids and install it to /usr/lib/udev/hwdb.d/ instead of creating custom udev rules which grant permissions for generated device id.

To be honest this seems far more complicated to me than it should be and, to be even more honest, I don't understand it. brscan4 is for Multi-function devices, Scan-only devices and god knows for what else, all of them being either networked or attached via local ports. How can a scanner driver decide what group to use or not? Is saned the only daemon/piece of software using scanner devices? If would be easy to generate rules for saned group instead of scanner then... Me scratching head... BTW, mine looks not so different from https://github.com/archlinux/svntogit-packages/blob/packages/sane/trunk/66-saned.rules

@Harvey sane maintainer in Arch said scanner group (or any other group) isn't used anymore with udev+hwdb setup so why did you switch over it right now?

https://bugs.archlinux.org/task/57391#comment197064

2nd try, forgot to push mk-udev-rules

mk-udev-rules did not pass the validity check (md5sum). Package version brscan4 0.4.10_1-2

Published a new version only based on acl udev rules. Please try!

@ettavolt: Will have a look as soon as I find the time. The gawk script was provided by another user, so :p For now: Don't change a running system...

Harvey, now that Arch has switched [1] to hwdb + acl, would you mind doing the same here next time you get your hands on this?

That means changing mk-udev-rules to build something like /usr/lib/udev/hwdb.d/20-sane.hwdb supplied by the sane package now. (Sorry, I'm total noob in awk) Arch's custom 66-saned.conf will take care of other things (like some sane's rules did before).

I see no specific lines in the source [2] of Arch's sane package to do hwdb rebuild/reload. systemd likely does that automagically.

Benefits of hwdb are the ability to supply the data to something else but udev and it's indexed nature [3].

For Manjaro nothing should change (they should already have systemd with hwdb).

I think I saw someone from OpenSUSE coming here. They seem to have two separately maintained packages in the OBS, for which I didn't find any traces connecting them to AUR's brscan4.

Thank you for maintaining this package!

[1] https://bugs.archlinux.org/task/57391 [2] https://github.com/archlinux/svntogit-packages/blob/packages/sane/trunk/ [3] https://github.com/systemd/systemd/blob/main/NEWS, see "CHANGES WITH 196"

@jowlo: updated, thanks for the hint

There is a new version 0.4.10 available at the Brother website since 25/01/2021 at https://download.brother.com/welcome/dlf105200/brscan4-0.4.10-1.amd64.deb

Would you mind updating the package? Thank you!

@trapezestunned: This does not look like a standard brscan4 device. Quick google search found this: https://bbs.archlinux.org/viewtopic.php?id=250065 Please take some time to investigate yourself ;)

Trying to get scanning with a Brother DS-620 working. I've installed this package (the Brother website said to use brscan4), but it isn't working. I can see the device when I use lsusb, but scanimage and sane-find-scanner don't see anything whether run as root or not. I've tried adding my user to lp, rebooting, replugging, no change. Any idea what I could've done wrong?

@yywrobbie: If it is in the driver, I can't be of any further help. Please contact upstream support. Did you try both ADF and Flatbed? Any settings of the hardware that you could change?

@Harey Having the same problem on opensuse with the upstream rpm driver. Tried xsane and it didn't work as well.

@surm: I suggest reading the comments before complaining, on the second page you will find your answer.

I have a trouble updating brscan4 to version 0.4.9_1-1:

error: The following untracked working tree files would be overwritten by checkout:
        agree.html
Please move or remove them before you switch branches.
Aborting
error: could not detach HEAD
error: clone failed for brscan4: git exited with unexpected exit status 1
:: failed to retrieve packages

@yywrobbie: I suggest to validate if the driver is working correctly on other linux distributions. Have you tried sane-frontends, i.e. xsane?

Unable to scan US letter-sized documents on my MFC-L2700DW. On skanlite it shows that the maximum width of scannable area is 8.3 inches which is smaller than the width of a US letter (8.5 inches). Same thing with gscan2pdf where the maximum width is 211.90mm (~8.3 in) which suggests an issue with the scanner driver or the configuration of it.

updated. Thanks @lgm @ua4000: The 'Required by xxx (optional)' tag has to be provided by the other package, in this case brother-dcpj4110dw

Thanks ! Got my Brother DCP-J4110DW working.

You could add: Required by brother-dcpj4110dw (optional)

Have a good day!

I installed this package and ran the following command:

brsaneconfig4 -a name=Brother_MFC-L2740DW model=Brother_MFC-L2740DW nodename=hostname.domain

At this point scanimage --list-devices showed the device, and scanimage successfully scanned the paper I had in there. It was super easy.

Thanks!

Again (like stated before on 2020-03-18)... The brsan4.install file should get this right without user interaction. Calling /opt/brother/scanner/brscan4/setupSaneScan4 -i does exactly that - adding 'brother4' to /etc/sane.d/dll.conf... Don't know why this does not work for you... Did you by chance configure addditional restrictions for pacman? If noone answers the question I won't be able to find a cause for the missing entry in /etc/sane.d/dll.conf. And it won't help to just add it like you suggested. Think about uninstallation and update...

There's a drop in folder that can be used to make this package work out of the box.

echo brother4 > /etc/sane.d/dll.d/brother4.conf

Any reason why not to include it in the package?

Makes sense. I didn't understand this error was from Git, fixed now :)

Looks like yay downloads sources to the folder with PKGBUILD. That's why when agree.html became a versioned file, Git refused to check it out over already present unversioned copy. Victoria, Julien, can we see a listing of your directories with brscan4 PKGBUILD? I bet we'll see rpms there too.

So why don't you just overwrite the file agree.html? BTW, yay is not an official tool. I tested with makepkg which is the arch way and this worked for me.

I have the same issue when updating the package:

$ yay -Suy
[sudo] password for julien: 
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
:: Starting full system upgrade...
 there is nothing to do
:: Searching databases for updates...
:: Searching AUR for updates...
:: 1 Packages to upgrade.
1  aur/brscan4  0.4.8_1-1 -> 0.4.8_1-2
==> Packages to exclude: (eg: "1 2 3", "1-3", "^4" or repo name)
==> 
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur: 1]  brscan4-0.4.8_1-2

  1 brscan4                          (Installed) (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 
:: Downloaded PKGBUILD (1/1): brscan4
  1 brscan4                          (Installed) (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 
error merging brscan4: error: The following untracked working tree files would be overwritten by merge:
    agree.html
Please move or remove them before you merge.
Aborting

@vstuart: I don't get the sense of your message, sorry ;) I tested pure 'makepkg -cfsi' and it works without quirks. Could you please tell us a little more?

error merging brscan4: error: The following untracked working tree files would be overwritten by merge:
      agree.html

Start update (e.g., yay -Syu), and at appropriate prompt (brscan4 update) choose to view the differences (diff), to get your path to agree.html:

  ...
  ==> Diffs to show?
  ==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
  ==> A
  ...
  diff --git /home/victoria/.cache/yay/brscan4/agree.html /home/victoria/.cache/yay/brscan4/agree.html
  ...

Then, in a terminal:

mv /home/victoria/.cache/yay/brscan4/agree.html /home/victoria/.cache/yay/brscan4/agree.html.old

Update /install should now proceed. :-)

It works ! Many Thanks

Brother seems to have deleted the license file from their website. For the time being I have pushed a new version of the package that contains the license file.

Hello Harey and all

Brscan4 (0.4.8_1-1) build fails as http://www.brother.com/agreement/English_sane/agree.html can't be downloaded (error 404). Is there a way to bypass this?

Thanks in advance

The brsan4.install file should get this right without user interaction. Calling /opt/brother/scanner/brscan4/setupSaneScan4 -i does exactly what you did manually - adding 'brother4' to /etc/sane.d/dll.conf... Don't know why this does not work for you... Did you by chance configure addditional restrictions for pacman? Puzzled...

I used brsaneconfig4 but I had to do this also:

$ echo brother4 | sudo tee /etc/sane.d/dll.d/brother4

thanks @Junker

@Junker: Did you use brsaneconfig4 after the installation?

my scanner DCP-1510 didn't work until i didn't do this:

$ echo brother4 | sudo tee /etc/sane.d/dll.d/brother4

so, maybe should add this file to the package

Hopefully your surgery went well @Harey!

Updated to 0.4.8-1

Just a short note: I am in the process of getting hip surgery atm and can't do much. Online time is short and precious ;) If someone else wants to adopt the package I'll orphan it for now. But I will be back in about 3-4 weeks.

I suggest adding to the package()-function a creation of a symlink of the /etc/opt/[...]-stuff directly into /etc/, so it is easier to find. E.g.:

  # Create configuration file symlinks such that it is more straight forward to find ...
  cd  "${pkgdir}/etc
  ln -s opt/brother/scanner/brscan4 .

/etc/opt/[...] is quite a strange directory. I had a very hard time looking where I defined my network scanner, because, when it/ the network is not available, sane was rejecting any other work, too.

Note to self and future Googlers:

brscan4's notion of your scanner's IP address has nothing to do with CUPS' notion thereof. If you change your printer's IP, it won't affect the scanning, and you'll get the dreaded Invalid argument error.

You can fix this by correcting your scanner's IP in /opt/brother/scanner/brscan4/brsanenetdevice4.cfg

Hi ettavolt. I'm not sure if that was directed towards me but "/opt/brother" does not exist. I had installed brscan4 using yay and I'm not sure if another tool is advised instead.

EDIT: I had this error: brscan4: /usr/lib/sane/libsane-brother4.so exists in filesystem brscan4: /usr/lib/sane/libsane-brother4.so.1 exists in filesystem brscan4: /usr/lib/sane/libsane-brother4.so.1.0.7 exists in filesystem Errors occurred, no packages were upgraded.

so I deleted these three files and were able to install brsane4 just fine and run brsaneconfig4. Thanks!

~ % /opt/brother/scanner/brscan4/brsaneconfig4 --help
USAGE: brsaneconfig4 [-OPTION]   OPTION:
       -a name=FRIENDLY-NAME model=MODEL-NAME ip=xx.xx.xx.xx    
       -a name=FRIENDLY-NAME model=MODEL-NAME nodename=BRN_xxxxx 
                   : Add network scanner
       -r FRIENDLY-NAME [FRIENDLY-NAME ...]
                   : Remove network scanner
       -q          : Query supported models and available network scanners
       -d          : Diagnosis
       -p          : Ping (for network scanners)  
       -s:[LABEL]  : Save current configuration
       -l:[LABEL]  : Load saved configuration

I noticed that after installing this package that I don't get a binary starting with "brs", namely brsaneconfig4. I was wondering what package I'll need to install for that.

updated to 0.4.6_1

@marcin: changed that back, thanks. Learned: never rely on anything :(

Was getting this error:

curl: (51) SSL: no alternative certificate subject name matches target host name 'www.brother.com' ==> ERROR: Failure while downloading https://www.brother.com/agreement/English_sane/agree.html

I downloaded the brscan4:

git clone https://aur.archlinux.org/brscan4.git

and then manually edited PKGBUILD to have http instead of https for two brother links there.

And then manually build and install the packakage

makepkg -si

@lordbalmung: Done. Thank you for the hint. Did not change the pkgver though because it does not change the package itself.

Can you please modify the source to https instead of http? brother seems to release the rpm in https as well.

@Harey: it still blocks executing binary files. To be clear: noexec flag isn't defense against malicious PKGBUILD. It's a coincidence that it can break building in circumstances as described below. What I'm advocating here is to prevent that accidental breakage.

Just out of curiosity: what is the sense in this if a malicious PKGBUILD can circumvent it with a - agreed - trivial change?

@ettavolt: You're partially right :)

If the files were simply copied to chroot dir it will work as files can have executable bit (x) on noexec filesystem - it's just not effective.

The problem is that in Archlinux chroot they're bind mounted, see https://git.archlinux.org/devtools.git/tree/makechrootpkg.in#n419 . That means original mount point flags like noexec are inherited and the build will fail.

So in this example mounting /home (or /var or whatever) with noexec will even break building in clean chroot (assuming /home is where you downloaded PKGBUILD). That's why using ./some-script is harmful in PKGBUILD.

Even if the files are copied from noexec FS into clean chroot for that kind of build, they'll miss the flag, won't they?

@ettavolt: It's not about BUILDDIR (which is set to /tmp as default) directory where packages are being built. It's about SRCDEST (which defaults to dir where PKGBUILD is stored).

If you download brscan4 snapshot to /home mounted with noexec it will still break building in /tmp mounted with default flags. That's because files (like mk-udev-rules) from /home will be symlinked to /tmp. That's the essence of this issue.

Luckily this problem goes away with a trivial change :)

To quote the wiki:

the most restrictive … without losing functionality

Particularly, noexec on /tmp is said

breaks compiling packages and various other things

Also, many other packages execute some script as a part of build process. sane itself uses a built undistributed binary to write udev rules.

@Harey

Well, I did my best to explain the benefit. Mounting partitions with noexec flag is what Arch wiki recommends for security: https://wiki.archlinux.org/index.php/Security#Mount_options . I don't understand why not use my approach which will work always instead of something which can break in a known scenario. I'm modifying this locally for years but I thought it would be beneficial to upstream it to prevent everyone from hitting this issue.

@egrupled: I don't see the benefit for this but you are always free to edit the PKGBUILD to suit your needs before building. Anybody else having the same problem?

@Harey

Yes, it breaks when you try building the package and the directory where you downloaded sources is mounted with noexec flag.

In such case executing scripts directly like ./some-script will fail with permission denied.

But executing scripts by passing them to interpreter like bash some-script, python some-script or gawk -f some-script will still work.

The script functionality is unchanged so there is no downside of doing this change.

@egrupled: Could you describe the scenario a bit more and why somebody wants to use it? It breaks only while building the package, right?

Hi, thx for providing this package!

Could you change in https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=brscan4#n26

./mk-udev-rules opt/brother/scanner/brscan4/{Brsane4.ini,models4/*.ini} > etc/udev/rules.d/40-$pkgname.rules

to:

gawk -f mk-udev-rules opt/brother/scanner/brscan4/{Brsane4.ini,models4/*.ini} > etc/udev/rules.d/40-$pkgname.rules

Otherwise it breaks when "mk-udev-rules" is cached on mount point with "noexec" flag.

updated to 0.4.5_1 @ron2138 I changed the upstream URL to something more unspecified because the one you provided did not have the latest updates. Thanks for reporting upstreams - please keep us informed if you get an answer.

1. The upstream URL recorded above can not be found

. I believe the this is the current URL.

2. Replying ettavolt comment on 2018-06-13 05:13 and Harey comment on 2018-06-12 09:20: On 2018-06-19 I sent a message through Email Support. Got #180619-000271 reference number for follow up. A reply by email was they will provide this to the software engineers.

Man (https://www.freedesktop.org/software/systemd/man/udev.html) says that /etc/udev/rules.d/ is for local administrator. Local = per-machine. Package isn't machine-dependent (though it may be useful only for some that have Brother's scanner connected). Having rules in /usr/lib would allow a simple disabling via linking /etc/udev/rules.d/40-brscan4.rules to /dev/null. And this way won't interfere with package updates (while deleting file does).

The output of 'pacman -Qo /usr/lib/udev/rules.d/' makes me feel it is better to leave this directory alone ;). As far as you don't have a pressing argument I will stay with /etc/udev/rules.d/. One could interpret 'vendor' as 'Archlinux' as well...

Currently, /etc/udev/rules.d/40-brscan4.rules are installed by brscan4. I think it would be better if that file will be installed under /usr/lib/udev/rules.d/. The reason is that, as far as I can tell, /usr/lib/udev/rules.d/ are for vendor files, while /etc/udev/rules.d are for local files.

So you should file a bug for sane in Archlinux's bugtracker and see what the devs think about the situation...

Works, thank you. But for a bit different reason. ☺

So, what's happening with my DCP-1510 (as I understand it now):

40-brscan: MODE 664, GROUP lp, libsane_matched=yes

49-sane: MODE 664, GROUP scanner

50-udev-defaults: GROUP="lp" (because ENV{ID_USB_INTERFACES}==":0701??:")

70-uaccess: TAG+uaccess (because libsane_matched=yes)

Systemd somehow adds current-user ACL for uaccess-TAGged devices (this package owns udev-defaults and uaccess). Since brscan4 has priority of 40 (higher than 70 of uaccess) scanner works for current user without modification of his group. I think Arch's sane has to generate ACL-based udev rules (instead of what's generated now).

Here you can remove MODE and GROUP actions. The combination of sane.rules and udev-default.rules will do exactly the same (checked for DCP-1510).

ettavolt: OK, this seems quite logical to me. I pushed a new version of the package with the change you proposed. Let's see what happens ;)

Sorry, forgot to enable notifications. Basically udev is applying files from /etc and /usr in lexical order (without directory paths). Sane's rules are chowning scanner ports to 'scanner' group if ENV{libsane_matched}=="yes" (see the bottom of /usr/lib/udev/rules.d/49-sane.rules). "brscan4" is lexically after "49-sane". That's why ENV{libsane_matched}="yes" in "brscan4" will be applied after sane's rules and thus a Brother's scanner port won't be chowned to 'scanner'.

BTW, I wonder why is there MODE=xxx GROUP=xxx in the sane's rules file? This changes are reapplied by ENV{libsane_matched}=="yes" condition…