From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 22EC9138247 for ; Sun, 10 Nov 2013 01:31:12 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C112FE0AC9; Sun, 10 Nov 2013 01:31:05 +0000 (UTC) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by pigeon.gentoo.org (Postfix) with ESMTP id F16E3E0AC5 for ; Sun, 10 Nov 2013 01:31:04 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta14.westchester.pa.mail.comcast.net with comcast id ndBL1m00127AodY5EdX49l; Sun, 10 Nov 2013 01:31:04 +0000 Received: from ajax ([24.11.47.14]) by omta19.westchester.pa.mail.comcast.net with comcast id ndX41m00G0JMh7c3fdX4TR; Sun, 10 Nov 2013 01:31:04 +0000 Date: Sat, 9 Nov 2013 20:30:50 -0500 From: Frank Peters To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: USB Scanner Problems with Newer Kernels/Libusb [Solved] Message-Id: <20131109203050.a1754f19defbcfd9a514a48d@comcast.net> In-Reply-To: References: <20131108222553.33af27243ad5aa2411c3f0ff@comcast.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.22; x86_64-unknown-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1384047064; bh=VApUzL0ITYdPKvRTWXy/Xdzww30YWwESgrs3dZV0KzA=; h=Received:Received:Date:From:To:Subject:Message-Id:Mime-Version: Content-Type; b=VTZvkx8EZl1X96pO5PYZoMaKufHT7EOCxrFau+Er3OWQdb2+g3HCq0+iThjz5ORDs Pz222633cjVdyR8hHkRgzCYPgtPuXY7EKb/BFrO2hMdBh3m+0u1j01cqZzCxQqE/Mf LZ9PJMqezjBtP1kepm5KF1BLSSQbBN1TXmSmoc8qK4gHMcpgcpK3NDZ4ILb6vxTa/7 FsYbQJcUAYi4032V3E/4Sf9I56kIbPwcpLJokoGi3xY87+BjWCPlz/I+/uYHGvwqKz tALirG24hRUx851av4+QzlypK+pi3FRiboDS2k88EUxRuOs8qgcBbiw2k4Y6JVHgll 67J3E0Xi2yfPQ== X-Archives-Salt: 7157e7f1-b749-4b3b-af43-0dfbe8a0765d X-Archives-Hash: d7252a67ec2e122f9d1066affc5cd3aa On Sat, 9 Nov 2013 12:29:49 +0000 (UTC) Duncan <1i5t5.duncan@cox.net> wrote: > > udev creates usb devices in /dev/bus/usb. Each usb port is a (three-digit > sequentially numbered) directory, > Libusb, meanwhile, has been updated to work with the /dev/bus/usb/ tree, > so AFAIK that's what you need to create... somehow. > On Sat, 9 Nov 2013 16:11:48 -0600 Barry Schwartz wrote: > > Maybe you can run it once even as a non-daemon just to create the > device, similarly to running rescan-scsi-bus. > Well, it works! That is, I can start udev as a daemon, plug in my scanner, and udev will tell me what the major and minor numbers of the scanner device node. Then I can use my scanner with libusb and SANE. I thought that udev would also create the device node, but for some reason it does not. However, I can create the device manually in the /dev tree and then SANE is able to detect the scanner. Thanks especially to Duncan for his info on the /dev/bus/usb/001 ... location. I can manually create, for example, /dev/bus/usb/001 using the major/minor numbers reported by udev. Then I am in business for scanning. Actually, I can just create a whole series of nodes under /dev/bus/usb with the same major number and an incremental minor number. This will eliminate the need to use udev entirely. Whenever I plug in my scanner one of those nodes will be relevant. But the whole process illustrates that udev is not really necessary. The scanner is accessed through a device node in the /dev tree and there is no reason why udev must create this node. As long as the major/minor numbers are known (and the char or block characteristic) then anything can create the node. IOW, the kernel access is the same as always. Only these user space programs impose these node constraints. I wonder if I can determine the major/minor numbers in some other way. Maybe the /sys tree has that information. If so, then I could completely script the process without using udev. Thanks to all for the contribution. Frank Peters