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 2F47E138247 for ; Sun, 10 Nov 2013 02:36:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5F125E0AC0; Sun, 10 Nov 2013 02:36:17 +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 96133E084C for ; Sun, 10 Nov 2013 02:36:16 +0000 (UTC) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta14.westchester.pa.mail.comcast.net with comcast id neT11m0020SCNGk5EecGhZ; Sun, 10 Nov 2013 02:36:16 +0000 Received: from ajax ([24.11.47.14]) by omta09.westchester.pa.mail.comcast.net with comcast id necF1m00d0JMh7c3VecG94; Sun, 10 Nov 2013 02:36:16 +0000 Date: Sat, 9 Nov 2013 21:36:02 -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: <20131109213602.38a24c9a1acfa85a00a6c2e0@comcast.net> In-Reply-To: <20131110015302.GA6695@crud> References: <20131108222553.33af27243ad5aa2411c3f0ff@comcast.net> <20131109203050.a1754f19defbcfd9a514a48d@comcast.net> <20131110015302.GA6695@crud> 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=1384050976; bh=Hb4O7Walx+nihU9Jo5j/a1BfzOTtERoyRRCKETc8HVA=; h=Received:Received:Date:From:To:Subject:Message-Id:Mime-Version: Content-Type; b=V09C5nyePEXFIq7e2v07yJPJouhleStNJ6JZKhQLCPwNMHahbHEzL/kMw6W7iGgEZ aMCJrlQ11vXpr3K+AGwgfz6QDKwAfqPud2hEoJvI+XjK+kbf895OahA1qcKgsrRQm2 yh4YHrZEasp7bpiP23neqiM+yHTqFaYNPPmoEJ3iRCmQS6nUeaPIft73ZzXyfDk9hq x9PY7FdTysaKOGcXzJnzVzHL0vF+fxHYnm771xJBg06dRkfGUPzK+aghXkiPKXcgXi xV2C5Pa1G93P3u2eVgYeauO6nRWmJWoKc2sKbhhgF2N457aQqOd+MgIBzx6Q5ooPIC DvrI0dH5RiE3Q== X-Archives-Salt: e33232c4-41ce-40e2-8b47-6427018a318c X-Archives-Hash: b40f3888b2918bb5dd0d25b2ad13d6ae On Sat, 9 Nov 2013 19:53:02 -0600 Barry Schwartz wrote: > > I figured as much. Please let us know if you come up with a good > technique that can be adapted to a MAKEDEV script or such. It is nice > to know how to dump e?udev, just in case; and I also use a scanner. > As soon as I plugged in the scanner (after starting the udev daemon) an entry was created in /run/udev/data for c189:131. This obviously refers to a device node for a character (c) file with a major number of 189 and a minor number of 131. This is all that is needed to access the device through the kernel. However, with udev and libusb there are user-space conventions. A utility such as libusb expects device nodes to be in a certain location, i.e. /dev/bus/usb, and to be named a certain name, i.e. 001, 002, etc. If not for these conventions the device node could be placed anywhere and named anything. So, to stick to conventions, create the node in /dev/bus/usb: mknod --mode=0666 /dev/bus/usb/001 c 189 131 That's it. Now the scanner can be detected by libusb and SANE. Furthermore, this is a *permanent* device node. It will not disappear upon reboot. The udev daemon is needed only once to get the major/minor numbers. However, if the device is unplugged and then plugged back in again the minor number usually jumps. So just create a sequence of nodes to allow for this: mknod --mode=0666 /dev/bus/usb/002 c 189 132 mknod --mode=0666 /dev/bus/usb/003 c 189 133 ... Upon reboot, the node will reset back to the first minor number. If you check devices.txt in the kernel source documentation, these particular major/minor numbers are not listed for any device. I don't know where they come from, but as long as they work I don't care. However, this would preclude using something like MAKEDEV to pre-build these nodes. Also, user-space programs expect certain node naming conventions and I don't know where such conventions are listed. A new issue is determining how udev gets its device info. The kernel sends out a notice when it detects a new device and the udev daemon gets the notice and then reads the new kernel device parameters from somewhere. But from where? If this were known then any script could read the same parameters. In short, if udev reads data from the kernel then a simple custom program or script could accomplish the same thing. Frank Peters