Bug 3698

Hi, thanks for reporting this bug.
Assigned to the package maintainer.

(maybe more a sane issue and/or upstream ?

Keywords: (none) => Triaged
Assignee: bugsquad => supp

Have you tried as root?

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud

Also attach the dmesg.txt file resulting from running the following command:
dmesg > dmesg.txt

(In reply to comment #2)
> Have you tried as root?

Yes it works as root.

Created attachment 1225 [details]
dmesg as requested

Permissions issues

Assignee: supp => mageia
Summary: xsane fails to correctly find device Brother DCP-J125 => xsane fails to correctly find device Brother DCP-J125 us user (OK as root)
Source RPM: xsane-0.998-1.mga1 => udev

(In reply to comment #6)
> Permissions issues

/.sane (and contents) have the same permissions for both root and user

(In reply to comment #6)
> Permissions issues

Thats really good to know, but whats the solution?

Tried running it from the command line and get the following message:

libusb couldn't open USB device /dev/bus/usb/002/005: Permission denied.
libusb requires write access to USB device nodes.

(/dev/bus/usb/002/005 permissions are set at 664, Owner: Root; Group: lp)

I've made myself a member of the lp and saned groups and that didn't work.

(In reply to comment #8)
> (In reply to comment #6)
> > Permissions issues
> 
> Thats really good to know, but whats the solution?
> 
> Tried running it from the command line and get the following message:
> 
> libusb couldn't open USB device /dev/bus/usb/002/005: Permission denied.
> libusb requires write access to USB device nodes.
> 
> (/dev/bus/usb/002/005 permissions are set at 664, Owner: Root; Group: lp)
> 
> I've made myself a member of the lp and saned groups and that didn't work.

Ah! it needed a reboot. I now have it working

removed NEEDINFO

@ Colin

Please set status to ASSIGNED if you agree this bug was assigned correctly.

Keywords: NEEDINFO => (none)
CC: (none) => marja11

David do you still have this h/w and can you test on Cauldron? I suspect updated udev rules will make this work without needing to be in any special groups, but I don't have any h/w to test with.

Status: NEW => ASSIGNED

Will do Colin as soon as I can get Cauldron up and running

Created attachment 1707 [details]
Extract of various commands/logs

(In reply to comment #11)
> David do you still have this h/w and can you test on Cauldron? I suspect
> updated udev rules will make this work without needing to be in any special
> groups, but I don't have any h/w to test with.

In a nut shell had to add the groups lp and saned to the user to get the scanner working.

Downloaded and installed the printer/scanner drivers from Brother.

System-config-printer then downloaded/installed a bunch of cups drivers.

Add and select printer routines scanned for the printer but fail to find.

see attachment 1707 [details] for log extracts.

What other info do you require?

*** Bug 4800 has been marked as a duplicate of this bug. ***

Colin, I've seen the same issue on my uncle's PC with a DCP-153c multifunction printer.
Only root can scan unless I manually add a new udev rule:

ATTRS{idVendor}=="04f9", ATTRS{idProduct}=="01e1", TAG+="udev-acl"

Severity: normal => major

The tag would want to be uaccess these days (tho' doing both udev-acl and uaccess is a good idea for the transition period when consolekit is deprecated)

(In reply to comment #16)
> Colin, I've seen the same issue on my uncle's PC with a DCP-153c multifunction
> printer.
> Only root can scan unless I manually add a new udev rule:
> 
> ATTRS{idVendor}=="04f9", ATTRS{idProduct}=="01e1", TAG+="udev-acl"

Thierry, where exactly does this line have to be inserted? /etc/udev/??

David, it would typically be included in the upstream file, but perhaps under different mechanisms (e.g. not based purely on vendor and product ids, but rather on other metadata - it may be that the ids are used to add the other metadata and then standard rules then subsequently add the TAG).

For example, the standard rules for uaccess (/lib/udev/rules.d/70-uaccess.rules) contains the following line.

# SCSI and USB scanners
ENV{libsane_matched}=="yes", TAG+="uaccess"

So we really need to work out why libsane_matched env var does not contain the word "yes".

Now the file /etc/udev/rules.d/60-libsane.rules (which shouldn't be in /etc/ it should be in /lib), contains all the rules that set the libsane_matched env var.

So you probably want to add a new lines to that file so that it recognises your scanner.

From previous commands, we know that your scanner is: vendor: 04f9, product: 0253 so the lines would be:

# Brother DCP-J125
ATTRS{idVendor}=="04f9", ATTRS{idProduct}=="0253", MODE="0664", GROUP="usb", ENV{libsane_matched}="yes"


If you do this, does your printer work as expected?

If so we can add those lines to the sane package (along with Thierry's one) and submit the patches upstream for inclusion.

I meant, "does you *scanner* work as expected?" above :p

(In reply to comment #19)
====== sniped ======

> From previous commands, we know that your scanner is: vendor: 04f9, product:
> 0253 so the lines would be:
> 
> # Brother DCP-J125
> ATTRS{idVendor}=="04f9", ATTRS{idProduct}=="0253", MODE="0664", GROUP="usb",
> ENV{libsane_matched}="yes"
> 
> 
> If you do this, does your printer work as expected?
> 
> If so we can add those lines to the sane package (along with Thierry's one) and
> submit the patches upstream for inclusion.

Thanks Colin,

Added the above line, removed myself from the lp and saned groups and the scanner worked as expected. Now to just get the printer side to work on cauldron, but that can wait now until beta2 comes out.

OK, I've added this one in the latest sane package. I also added Thierry's uncle's model too (tho' separately as I forgot initially!)

The udev rule location was also fixed to move it to /lib/udev/rules.d/. As you edited the one in /etc/ you may have to remove an rpmsave file left over when you upgrade.

So this will be fixed in mga2 which will be out soon.

I'll leave it up to the maintainer to see if he wants to backport this fix.

Assignee: mageia => dmorganec
Source RPM: udev sane => sane-1.0.22-5.mga2.src.rpm

I have a similar behavior on a epson perfection 2400, after installation of MGA2 BETA2.

SM

CC: (none) => serge.moreau

Still does not work as root.

Message : failed to load canberra-gtk-module;

Corresponding rpm (canberra-gtk) is however installed.

That's a gtk+ _warning_ which is totally unrelated anyway

Thanks, so, what to do ?

Some additionnal data

[serge@Saturne ~]$ xscanimage
Gtk-Message: Failed to load module "canberra-gtk-module"
[xscanimage] No scanners were identified. If you were expecting something
          different, check that the scanner is plugged in, turned on and
          detected by sane-find-scanner (if appropriate). Please read
          the documentation which came with this software (README, FAQ,
          manpages).
[serge@Saturne ~]$ 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.


found USB scanner (vendor=0x03f0 [HP], product=0xc202 [Photosmart 8200 series]) at libusb:001:006
found USB scanner (vendor=0x04b8 [EPSON], product=0x011b [EPSON Scanner]) at libusb:001:007

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: ASSIGNED => RESOLVED
Resolution: (none) => OLD