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 D15CB138247 for ; Sat, 9 Nov 2013 16:45:48 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id B8D2EE0A5C; Sat, 9 Nov 2013 16:45:44 +0000 (UTC) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by pigeon.gentoo.org (Postfix) with ESMTP id 08E4FE0A5A for ; Sat, 9 Nov 2013 16:45:43 +0000 (UTC) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta07.westchester.pa.mail.comcast.net with comcast id nUN61m0021vXlb857Uljt6; Sat, 09 Nov 2013 16:45:43 +0000 Received: from ajax ([24.11.47.14]) by omta17.westchester.pa.mail.comcast.net with comcast id nUlj1m00V0JMh7c3dUljDz; Sat, 09 Nov 2013 16:45:43 +0000 Date: Sat, 9 Nov 2013 11:45:29 -0500 From: Frank Peters To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: USB Scanner Problems with Newer Kernels/Libusb Message-Id: <20131109114529.f29b71e10f00f6a8b170d0e8@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=1384015543; bh=Y88UrSt9BIEK3QsJj/ex0v720SJSugU60zvKOBehLog=; h=Received:Received:Date:From:To:Subject:Message-Id:Mime-Version: Content-Type; b=LUUJPq3eiAVE7HtJorM5M7MqxhWsW09xhxZpevojKEzZpXoyEqhQyABZUQtJmIksw XQfF4/lnUhuYSEdBbMPr2U9MgTS3JnoQY7v/xRby9+FFB5lRiMxop4cwWNi7ZttMtd +JUav3hvnRVXoQ6WMXh3U1qZfSyuhTTjB4ALHGu4EVpl52rMGnGGLNdwTy1x4Tq2us 7JF9KvSFrBZC8SzJEMHsuubm+E2gobVHdSA/3k2sSPpHL7P0GYa/US6UsUjCWTR5c6 PCuPDihw5/UrmZEGFuoYta2PugvkyEvWRjLIOul8bfjyBqLq/Sih18HV/qaKFsZBma ziXzUCoB+DzCw== X-Archives-Salt: 27685bdb-df3e-4212-9693-49a22adc6880 X-Archives-Hash: 787126ff62843126f3fbbc47e22fae18 On Sat, 9 Nov 2013 12:29:49 +0000 (UTC) Duncan <1i5t5.duncan@cox.net> wrote: > > Libusb, meanwhile, has been updated to work with the /dev/bus/usb/ tree, > so AFAIK that's what you need to create... somehow. > Thanks for this synopsis. I've been slowly piecing together essentially the same picture from many different sources but was still unsure about how libusb fits into the scheme. Creating, somehow, the /dev/bus/usb devices is also the conclusion I thought would be necessary, but I don't believe that it is possible without udev. Yet it seems that it *should* be possible. Everything, at least according to my limited understanding, within the /dev tree is just an interface to the kernel using major and minor numbers. The necessary modules, namely ehci-pci and uhci-pci, are already integrated into the kernel. Scanners used to work in the same way that USB printers or USB mass storage devices *still* work. That is, an appropriate module is either built or separately loaded into the kernel which will allow the use of certain interfaces in the /dev tree (e.g. /dev/usb/lp0). My USB modem also functions in the same way using a module, cdc-acm, and /dev/usb/ttyACM0. These /dev interfaces could be created independently of udev. Why not with /dev/bus/usb? In fact, everything classed as USB on my system, i.e. keyboard, mouse, printer, mass storage, modem, external hard drives, can be straightforwardly controlled using this module/dev method -- with the sole exception of USB scanners. Why this crazy distinction? Of course I could always jump on the udev bandwagon, like most everyone else, but I still very much enjoy the ability to control, in a simple manner, the operation of my own system. I don't like the idea of another system daemon doing things without my knowledge or approval. Frank Peters