On 4/30/2016 10:24, Hans Petter Selasky wrote: > On 04/30/16 17:08, Karl Denninger wrote: >> >> >> On 4/30/2016 09:15, Hans Petter Selasky wrote: >>> On 04/30/16 16:06, Karl Denninger wrote: >>>> So I have managed to get access via ugen to one of the USB devices I >>>> want to talk to. >>>> >>>> I would like to generalize that in a library, but am confounded by a >>>> /second /device that comes up "looking like a modem", although it is >>>> not. This is convenient if you want to open and deal with it like a >>>> modem, but unfortunately that attachment appears to prevent me from >>>> successfully using it with the ugen interface at the same time, as the >>>> attachment looks like it "eats" the inbound byte stream. >>>> >>>> Is there a reasonably-easy way to /prevent /FreeBSD from declaring >>>> this >>>> device eligible to be attached as if it was a character-style modem, >>>> leaving it only on ugen? I have figured out how to use devd to change >>>> permissions on attach, but not how to prevent it from attaching a >>>> generic USB device to a specific driver. >>>> >>> >>> Hi, >>> >>> Did you try: >>> >>> libusb_detach_kernel_driver() or >>> >>> libusb20_dev_detach_kernel_driver() >>> >>> --HPS >> >> I can probably code that into the application but what I'm looking for >> is something that can be stuck into devd's config (or similar) that will >> prevent the attachment in the first place when the device is plugged in. >> >> The issue is that I have multiple "things" that I want to talk to in >> this application at the same time, multiplexing them via threads and >> select(). One of them is only a serial driven thing, and thus I have to >> live with the reality of a USB serial dongle for those machines that >> don't have a built-in serial port. Ideally, I'd like to talk to >> everything that can come up on USB native via the ugen interface, which >> (for my purposes) is quite good since I don't mind having a second file >> handle open for write and, what's better, is that since I can open the >> control instance without blowing things up if someone else has the >> device open for some purpose I can make very sure I have the right >> device with the vendor and product Ids before I start trying to talk >> to it. >> >> Unfortunately if it's a serial port all I can do is try to probe it, and >> hope that my off-baud (if I get it wrong) inquiry strings don't cause >> the device to go insane since (and here's the really bad news) the >> serial-only one doesn't honor modem control lines as a means of insuring >> a hard reset. Unfortunately since serial USB interfaces have no >> consistent order, especially if plugged in after boot, I can't hard-code >> a config file entry either. >> >> If I can prevent this other device from attaching in the first place to >> a modem port via umodem then at application start I can iterate over the >> /dev/usb/x.y.0 nodes and, when I find the rights ones, open them up. >> This leaves me only one possibility in the supported interfaces for a >> device that appears as a serial interface which will greatly reduce the >> risk of making that particular device insane. >> >> While I can "detach" at program start this doesn't help me with a >> hot-plug possibility; if I can't prevent the attachment in the first >> place then I may as well live with the risk of fraggling the "wrong" >> serial device since if someone plugs or unplugs while it's running I >> have to accept that risk anyway. >> > > Hi, > > This sounds like an USB quirk. We currently don't have such a quirk, > but feel free to make a PR for it. > > A temporary workaround is to unconfigure the device in devd, until the > real driver comes around: > > usbconfig -d X.Y set_config 255 > > We could possibly add a quirk to leave devices unconfigured after plug. > > --HPS
Is that persistent (and if so, where is it written?) I didn't find documentation on that command in usbconfig's man page... I don't think sending a PR for this is the right thing to do since other people who use this same device may *want* the serial interface emulation..... -- Karl Denninger [email protected] <mailto:[email protected]> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
