| View previous topic :: View next topic |
| Author |
Message |
johnmdesmond
Tux's lil' helper
Joined: 05 Jan 2005
Posts: 83
|
 Posted: Mon Jan 16, 2006 5:53 am Post subject: Please help with non-root use of Microtek X6 <SOLVED> |
 |
|
After a very short drive, I've reached my wit's end about this. I can't get ordinary users to use the scanner. Actually the scanner worked well for months and then I converted to udev and many emerges later, the scanner wasn't working at all. Turned out the sg module wasn't being loaded anymore. After adding it to autoload, root can finally scan. The problem is that the device that is created, /dev/sg0, has ownership of root:root instead of root:scanner. Back in the day when /dev was /dev, I had at least a tenuous grip on how to reach out and touch a peripheral. Now with udev I'm lost. Does anybody have a clue what creates /dev/sg0 so I can go in there and muck around with it?
Not trashing udev, ever since I moved to it, cameras and flashkeys and all automount and are 'just there' even better than Windows. I just wish someone would write a "udev, hald, dbus, and ivman for dummies"!
-John
Helpful output:
By user -
| Code: | $ sane-find-scanner
# No SCSI scanners found. If you expected something different, make sure that
# you have loaded a SCSI driver for your SCSI adapter.
found USB scanner (vendor=0x05da, product=0x0099) at libusb:003:005
# 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.
# You may want to run this program as root to find all devices. Once you
# found the scanner devices, be sure to adjust access permissions as
# necessary.
$ scanimage -L
device `v4l:/dev/video0' is a Noname BT878 video (Hauppauge (bt878)) virtual device
|
By root (Note that the scanner gets discovered twice; as SCSI and as USB) -
| Code: | # sane-find-scanner
found SCSI scanner " Scanner 636A4 1.30" at /dev/sg0
# Your SCSI scanner was detected. It may or may not be supported by SANE. Try
# scanimage -L and read the backend's manpage.
found USB scanner (vendor=0x05da, product=0x0099) at libusb:003:003
# 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.
# scanimage -L
device `v4l:/dev/video0' is a Noname BT878 video (Hauppauge (bt878)) virtual device
device `microtek2:/dev/sg0' is a Microtek ScanMaker X6USB flatbed scanner
|
Last edited by johnmdesmond on Thu Jan 19, 2006 5:31 am; edited 1 time in total |
|
| Back to top |
|
 |
simon_irl
Guru
Joined: 07 Oct 2004
Posts: 403
Location: New Zealand
|
| Posted: Mon Jan 16, 2006 6:39 am Post subject: |
|
|
basically permissions are set in your udev rules (in the /etc/udev/rules.d directory). search in here for the settings relevant to your device, and modify them accordingly.
detailed instructions are here, but with luck you won't need them...just scan through the udev rules and you'll probably be able to find the relevant section, and (if you have at least a vague idea of how "groups" and "permissions" work in unix) figure out what you need to change. |
|
| Back to top |
|
|
tuam
l33t
Joined: 04 May 2004
Posts: 765
Location: CGN, Germany
|
| Posted: Mon Jan 16, 2006 12:23 pm Post subject: |
|
|
| simon_irl wrote: | | basically permissions are set in your udev rules (in the /etc/udev/rules.d directory). search in here for the settings relevant to your device, and modify them accordingly. |
I would prefer to create a new rule file with higher priority (lower number) for the modified rule, to be prepared for udev updates.
FF,
Daniel |
|
| Back to top |
|
|
johnmdesmond
Tux's lil' helper
Joined: 05 Jan 2005
Posts: 83
|
| Posted: Wed Jan 18, 2006 4:58 am Post subject: |
|
|
| Thanks for your comments. I looked through the udev rules yesterday and found nothing. As luck would have it, just tonight portage had a new version with sg added! It didn't affect the problem though. I still have more homework to do on this. |
|
| Back to top |
|
|
johnmdesmond
Tux's lil' helper
Joined: 05 Jan 2005
Posts: 83
|
| Posted: Thu Jan 19, 2006 5:30 am Post subject: |
|
|
So I did my homework and fixed this problem. Here's how. A textbook "write-a-udev-rule" situation.
The new sg* rule that was just added to the default ruleset just duplicated the default action if there is no rule... /dev/sg0 has ownership of root:root.
First I created a lower-numbered, higher-priority ruleset: /etc/udev/rules.d/10-local.rules
Then, with the scanner on, find the name of the udev-created device file: /dev/sg0
Go find out where sysfs is hiding the info on that device:
| Code: | # find /sys | grep sg0
/sys/class/scsi_generic/sg0
...
|
Find out what udev knows about this device:
| Code: | # udevinfo -a -p /sys/class/scsi_generic/sg0
udevinfo starts with the device the node belongs to and then walks up the
device chain, to print for every device found, all possibly useful attributes
in the udev key format.
Only attributes within one device section may be used together in one rule,
to match the device for which the node will be created.
device '/sys/class/scsi_generic/sg0' has major:minor 21:0
looking at class device '/sys/class/scsi_generic/sg0':
KERNEL=="sg0"
SUBSYSTEM=="scsi_generic"
SYSFS{dev}=="21:0"
follow the "device"-link to the physical device:
looking at the device chain at '/sys/devices/platform/host8/target8:0:0/8:0:0:0':
BUS=="scsi"
ID=="8:0:0:0"
DRIVER=="unknown"
SYSFS{device_blocked}=="0"
SYSFS{iocounterbits}=="32"
SYSFS{iodone_cnt}=="0x1"
SYSFS{ioerr_cnt}=="0x0"
SYSFS{iorequest_cnt}=="0x1"
SYSFS{model}=="Scanner 636A4 "
SYSFS{queue_depth}=="1"
SYSFS{queue_type}=="none"
SYSFS{rev}=="1.30"
SYSFS{scsi_level}=="3"
SYSFS{state}=="running"
SYSFS{timeout}=="0"
SYSFS{type}=="6"
SYSFS{vendor}==" "
looking at the device chain at '/sys/devices/platform/host8/target8:0:0':
BUS==""
ID=="target8:0:0"
DRIVER=="unknown"
looking at the device chain at '/sys/devices/platform/host8':
BUS==""
ID=="host8"
DRIVER=="unknown"
looking at the device chain at '/sys/devices/platform':
BUS==""
ID=="platform"
DRIVER=="unknown"
|
I chose to use these two pieces of data:
| Code: | BUS=="scsi"
SYSFS{model}=="Scanner 636A4 " |
I put the following rule in /etc/udev/rules.d/10-local.rules :
| Code: | # Microtek Scanner
BUS="scsi", SYSFS{model}="Scanner 636A4 ", NAME="%k", SYMLINK="scanner", GROUP="scanner"
|
The spaces are really in the detected scanner name. The device node is still called sg0 because of the NAME="%k" term. It might also be sg1, etc. But the detected scanner will always have a symlink called /dev/scanner pointing to it because of SYMLINK="scanner". The scanner will be accessible to users because the group is finally being set to "scanner" (GROUP="scanner").
Thanks to Daniel Drake for Writing udev rules for the background and to Decibels Linux's "UDEV Primer" for a very specific example.
Hope this helps someone.
-John |
|
| Back to top |
|
|
johnmdesmond
Tux's lil' helper
Joined: 05 Jan 2005
Posts: 83
|
| Posted: Fri Jan 20, 2006 12:17 am Post subject: |
|
|
This problem wasn't quite as "solved" as I thought it was. Here's what I had to do to mostly nail it shut:
The original rule
| Code: | BUS="scsi", SYSFS{model}="Scanner 636A4", NAME="%k", SYMLINK="scanner", GROUP="scanner"
|
created /dev/sg0 with appropriate ownership and a symlink /dev/scanner pointing to it.
I discovered that while the scanner was being found by user's xsane, only /dev/sg0 showed up in xsane's list of devices. User could scan with it. The only way /dev/scanner could be used was by placing it in xsane's command like so.
| Code: | # xsane microtek2:/dev/scanner
|
Unfortunately, while the scanner could be run through this device, the image returned was blank!
Root, however, could successfully scan through /dev/scanner. Grrrr.
So I switched it around.
| Code: | BUS="scsi", SYSFS{model}="Scanner 636A4", NAME="scanner", SYMLINK="%k", GROUP="scanner"
|
Now I have a device file /dev/scanner and symlink /dev/sg0. I should now have the opposite results. Wrong. Same results. User gets blank images from the real device and images from the symlink. What?!
Turns out if I change the rule so NAME="skanner", or if I get rid of the symlink so that /dev/sg0 never shows up, user can scan with the consistantly-named device /dev/scanner.
| Code: | BUS="scsi", SYSFS{model}="Scanner 636A4", NAME="scanner", GROUP="scanner"
|
The only bad side to this is I can't have a devfs-style device or symlink called sg0 as xsane somehow disables /dev/scanner when it sees it.
Did I do anything wrong here?
-John |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
