(D’oh — I forgot to include the magic CFDictionarySetValue line, below. Now the code below is ‘complete’.)
> On Jun 5, 2015, at 9:19 PM, Carl Hoefs <[email protected]> wrote: > > Taking my cue from SerialPortSample, I abandoned my approach and got it to > work with the following constructs: > > // Obtaining the matching dictionary > > kern_return_t kernResult; > CFMutableDictionaryRef classesToMatch; > classesToMatch = IOServiceMatching(kIOSerialBSDServiceValue); CFDictionarySetValue( classesToMatch, CFSTR( kIOSerialBSDTypeKey ), CFSTR( kIOSerialBSDModemType ) ); > kernResult = IOServiceGetMatchingServices(kIOMasterPortDefault, > classesToMatch, > matchingServices); > > // Iterating through the matching dictionary > while ((modemService = IOIteratorNext(serialPortIterator)) ) { > CFTypeRef bsdPathAsCFString = > IORegistryEntryCreateCFProperty(modemService, > CFSTR(kIOCalloutDeviceKey), > kCFAllocatorDefault, 0); > result = CFStringGetCString(bsdPathAsCFString, > bsdPath, > maxPathSize, > kCFStringEncodingUTF8); > CFRelease(bsdPathAsCFString); > } > > The "bsdPath" variable contains a string such as "/dev/cu.usbmodem00054741” > > Thanks Roland and Jack for the insights! > -Carl > > >> On Jun 5, 2015, at 6:46 PM, Roland King <[email protected] >> <mailto:[email protected]>> wrote: >> >> Sending again because the message was rejected as too long .. err where did >> that get to 24kB? >> >> Code looks basically correct - I don’t use quite that method, I set up >> notifications so I get dynamic adds and deletes but the dictionary I use it >> set up the same way, just passed to a different function. I can’t really >> paste any more code because it’s quite an edifice of classes I set up at the >> time to handle generic IOKit stuff and the matching code is sprayed around >> the place. >> >> Couple of things. What’s kernResult? Is serialPortIter actually getting set >> to anything (don’t recall whether the IOIteratorNext() checks for nil >> pointers, I think it may). >> >> If you don’t add keys to the dictionary at all do you still get stuff, how >> about using a different class than BSD just to see if you can get some >> matches for something. >> >> Last idea - get your own master port with IOMasterPort just to see if that >> helps despite the documentation telling you to use the constant. If nothing >> else the error returns from doing that might tell you if you have problems. >> >>> On 6 Jun 2015, at 09:14, Carl Hoefs <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Thanks for the suggestion. I’ve tried the variants, including >>> kIOSerialBSD232Type and kIOSerialBSDAllTypes, but nothing is getting >>> matched... >>> >>>> On Jun 5, 2015, at 6:09 PM, Jack Brindle <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> You might want to try matching a kIOSerialBSDRS232Type instead of the >>>> kIOSerialBSDModemType you now use. >>>> I believe there are several types you can match. You might not be matching >>>> the right one. >>>> >>>>> On Jun 5, 2015, at 6:00 PM, Carl Hoefs <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> That’s my situation also. I have numerous such devices plugged in, and >>>>> I'm assuming the matching dictionary will come back with them all. I’m >>>>> hoping there’s a way to relate the device interface (as discovered in >>>>> IOKit using the VID & PID) with the proper entry in the dictionary. But >>>>> since I’m getting back a 0-entry dictionary, I don’t know yet how this >>>>> will pan out! >>>>> >>>>> -Carl >>>>> >>>>> >>>>>> On Jun 5, 2015, at 5:56 PM, Jack Brindle <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> So, what if the user has another USB serial device plugged in? Won’t you >>>>>> get it also? >>>>>> >>>>>> >>>>>>> On Jun 5, 2015, at 5:32 PM, Carl Hoefs <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> >>>>>>>> On Jun 5, 2015, at 4:57 PM, Roland King <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Usb mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/usb/newslists%40autonomy.caltech.edu > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/usb/archive%40mail-archive.com This email sent to [email protected]
