Date: Tue, 26 Dec 2006 02:35:42 +0100 From: Bernd Walter <ticso@cicely12.cicely.de> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org, amistry@am-productions.biz Subject: Re: Attaching ugen to all usb devices Message-ID: <20061226013541.GB75351@cicely12.cicely.de> In-Reply-To: <200612252352.01377.hselasky@c2i.net> References: <200612251456.42770.amistry@am-productions.biz> <20061225.133821.-1605839720.imp@bsdimp.com> <200612252352.01377.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 25, 2006 at 11:52:00PM +0100, Hans Petter Selasky wrote: > On Monday 25 December 2006 21:38, M. Warner Losh wrote: > > In message: <200612251456.42770.amistry@am-productions.biz> > > > > Anish Mistry <amistry@am-productions.biz> writes: > > : Many usb devices can be attached as different devices along with > > : being functional with some libusb app that requires ugen. > > : eg. HP PSC Printers will attach as ulpt, if ulpt isn't loaded umass > > : can attach to access the card slot, if neither of these are loaded > > : ugen will attach which is required to run the hplip vendor software > > : so that the printer, scanner, and fax machine can be accessed. > > > > You should review how the device presents itself to the system. If > > both umass and ulpt attach to it, it should be possible to make them > > both attach at the same time. > > > > As for ugen, one could easily hack uhub to allow this kind of access. > > ugen really shouldn't be attaching to any device at all, but instead > > the usb bus (aka uhub) should allow ugen-like acess to each of the > > devices. > > Right. > > Here are some pointers: > > The core of your problem is "usbd_set_config()". Whenever you set a new config > value, you need to "device_delete_child()" all attached devices, and re-probe > the "struct usbd_device *" in question. Maybe you can extend the already > existing "usbd_remove_detached_devices()"? > > Try making a system where the USB device config value is always set from > "usbd_probe_and_attach()", hence this function is always called from only one > thread at a time! > > To force the system to re-call "usbd_probe_and_attach()", simply set > "up->last_refcount = 0", then call "usb_needs_explore()". "up" is of type > "struct usbd_port *". > > Maybe you should add a new field: > udev->current_config_value. > > When "udev->probed == USBD_PROBED_SPECIFIC_AND_FOUND" disallow "/dev/ugenX" > from setting the config value. > > Incorporate parts of ugen into "struct usbd_device": > > 1) Split ugen into two parts, /dev/ugenX and /dev/ugenX.X . > 2) /dev/ugenX is created by "usbd_new_device()". > 3) /dev/ugenX is removed by "usbd_free_device()". > 4) /dev/ugenX.X is a regular device that attaches when "uaa.iface != NULL" and > "uaa.usegeneric == 1". Maybe you have to remove > "USBD_PROBED_GENERIC_AND_FOUND". > > There should be no problems in the USB stack regarding duplicate device > attachment. If two devices start a transfer on the same interrupt endpoint, > they will be served alternately, for example. And don't forget to handle USB_SET_CONFIG properly... -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061226013541.GB75351>