Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: Codeless KEXT for CDC ACM device
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Codeless KEXT for CDC ACM device



On 06/03/2011 09:01 AM, Jim Wilcox wrote:
Since your device is declaring itself to be a networking device. [snip] When you use a Standard device type for some other use we have no way of knowing this.

I re-read the CDC spec again, and indeed using CDC ACM definitely implies the device is a modem, and one which understands "AT commands" (V.25ter).


However, there is no language in the CDC spec with implies CDC ACM is a "networking device", specifically networking protocols like TCP/IP. Certainly most modems in recent years have been used for dial-up TCP/IP networking, but if we're talking about the strict meaning of the standard, CDC ACM says nothing about what type of data will be exchanged other than the AT commands. It could just as likely be an 80's style dial-up BBS or other text-based console protocol. In fact, section 3.6.2.1 says "The Abstract Control Model can bridge the gap between legacy modem devices and USB devices."

Sadly, there is nothing I could find in the standard that would give any indication of the expected protocol the modem would use once connected. Krusti expanded upon what's needed better than I could, some mechanism, anything really, that we USB device developers could put in our descriptor which could indicate to OS-X that this CDC ACM device is definitely not used for networking.

It seems the CDC ACM path is going to remain stuck between an annoying dialog rock and windows-style password required hard place. I'd like to beg of you once more, for any sort of (admittedly questionably non-standard extension) way for USB descriptors to indicate the device is not used for TCP/IP or other networking and the user should not be presented with the network configuration dialog. Please, I'm begging, these microcontrollers are so flexible and firmware updates are so easy, I'm happy to put in an extra descriptor or change fields to give Mac users a great experience.

It seems so surreal begging Apple, of all possible companies, to think creatively to create the best end user experience and usability. I believe I've stirred the pot enough, and if I've offended anyone I'm sorry. I only long to create the best possible user experience.


-Paul





Jim

On Jun 3, 2011, at 7:46 AM, Paul Stoffregen wrote:

On 06/02/2011 04:39 PM, Rick Mann wrote:
I've tried that, and it has never worked. Couldn't figure out what I did wrong.
Even if this did work, it's hardly a solution for crafting a great user experience.

A great user experience allows the user to plug their new USB device in either before or after installing the supplied software.  The supporting software is an application bundle (on a .dmg disk image if downloaded) which the user installs by dragging to the applications folder, or any other location of their choice.  To the user, the software is a single file which they can mange like any other file using the Finder.  The software is NOT an installer.  The user is NEVER required to supply their admin password, not during installation and not while running, unless there is a genuine and clearly understood (by the user) need for the software to do system-level tasks.

If the USB device is already plugged in when the software is run, it's detected automatically.  If plugged in after the software is run, it's detected quickly by the software.  Unnecessary dialog boxes are avoided and the user is only ever prompted with questions that are directly relevant to their intended usage specific to their new USB device.

Requiring a kext at the very least breaks the case where the user plugs their new device in before installing anything.  Requiring an admin password, when the device and all other resources would otherwise not need admin access, is also pretty objectionable.

What's needed is some indication in the USB descriptors which tells the CDC driver and related infrastructure in OS-X that this device is NOT a modem and that prompting the user with a network configuration dialog is inappropriate.  In such cases, no user interaction should occur.  Software wishing to use the device can find it by the /dev/cu.XYZ node or by scanning the ioregistry.

I'm sure "there isn't a standard for that" will be the reason this is impossible or impractical.  Well, in the end, it's a matter of priorities.  As an independent USB device developer, I care only about the total quality of my customer's experience.  I only care about standards insofar as they facilitate long-term high quality user experience.

Sadly, before this network config dialog, CDC for non-network general purpose devices on OS-X had great usability.  I'm sure this makes the usability much better for the case of modems.  But with dial-up networking going the way of the dinosaur and USB-enabled microcontroller-based products becoming ever cheaper and more common, does focusing on dial-up modems and the expense of generic serial really make sense?


-Paul





_______________________________________________
Do not post admin requests to the list. They will be ignored.
Usb mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Usb mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Re: Codeless KEXT for CDC ACM device (From: Paul Stoffregen <email@hidden>)
 >Re: Codeless KEXT for CDC ACM device (From: David Frantz <email@hidden>)
 >Re: Codeless KEXT for CDC ACM device (From: Allan Nathanson <email@hidden>)
 >Re: Codeless KEXT for CDC ACM device (From: Rick Mann <email@hidden>)
 >Re: Codeless KEXT for CDC ACM device (From: Paul Stoffregen <email@hidden>)
 >Re: Codeless KEXT for CDC ACM device (From: Jim Wilcox <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.