Brian Buhrow <buh...@nfbcal.org> writes: > Isn't it possible to do most of what Jason proposes by using the drvctl > interface to > detach a driver from a specific USB device? Then, some glue could be added > to the ugen driver > to allow it to be attached to arbitrary devices using the same drvctl > interface? That seems a > lot easier to me than building a registry of devices and device IDs, which > will be woefully > out of date before it gets published. It also has the advantage of allowing > the user to do > creative stuff that the developers didn't think of. Am I missing something > obvious? > > -thanks > -Brian
I don't think that the detach part is a problem, but the second part is murky. The only thing I know of that can do the second part is a rescan call against the USB bus. Unless the ugen driver is allowed to have a higher priority than the specific device driver, the specific wins during the rescan of the USB bus. The use of ugenif was mentioned, and this is a way to do the "make ugen have a higher priority" game, but ugenif requires a custom kernel. See the ugen man page for the hint on how to use ugenif. There is the concept of tags that can be passed in a rescan, but to use those effectively for this problem is messy. You may end up having to put the "detect that ugen has a high priority" in every driver or at the very least the [uoevx]hci drivers and even then, it isn't tied to a specific device really, just the concept of "on this rescan, have ugen take priority" and ANY device found would get ugen. Jason's notion of using ugen as a bus instead of a leaf has merit and may be the better approach. The devil will be in the details, however. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
