Ladies and gentlemen, please welcome USB Technology Manager Craig Keithley. Good afternoon, everybody. Thank you for coming. Now is a very important time for us. Obviously, we're emphasizing Mac OS X, and as part of that, we'll be talking about some of the Mac OS X features for USB. I'm also going to do an overview of Mac OS 9 to give you an insight into what automatic, what standard USB drivers we have built into the OS, and to give you an overview of what that architecture looks like. That's mostly meant as a refresher because we are moving to 10. The other thing, too, that I decided Monday night as we committed to making the announcement about Aladdin Installer Maker supporting USB software locator is I cut out my five slides that I've been presenting for the last couple of years about what's inside a USB device. I figure by now you already know that. What you want to know is how to make USB software locator work. So we'll have some presentation on that. And at the end, we will go into doing driver development on Mac OS X.

There is some difference in USB under 9 and USB under 10. The APIs are slightly different. The structure is slightly different. But I think you'll see that it's a vast improvement over what we've had in driver architectures in the past. 10 with I/O Kit is a great leap forward. I'll also talk to you about our recommendations that we make to developers when they come in and they ask us, how should we create USB devices for the Macintosh? And those recommendations, by and large, to apply to both Mac OS 9 and Mac OS X. So let me talk about what we've done in Mac OS 9.

I'll go over what's new, I'll talk about the standard drivers, and I'll give you an overview of the architecture. So what's new in 904? Well, not a lot. I mean, we've been fine-tuning performance. We've been addressing some issues. The notable improvements, new features in Mac OS 904 and with the just released two day ago multimedia update, our good USB audio input works very well. And we also are pleased to announce that we built into Mac OS 9 USB controlled UPSs. So all those that you've seen in the press releases about having USB interfaces, not only we have a USB driver, we also have added functionality into our power manager to support UPSs automatically. It looks like a battery device. It's very cool and it's a great addition.

So what's the specifics about the audio driver? Well, if you haven't been working with USB audio, I can tell you quite simply it supports multiple frequencies, multiple sampling. We use PCM format, which is a particular way of representing the data in the data stream. We support both stereo output, stereo input, and monophonic input. We don't today support monophonic output.

We don't support vendor unique implementations for USB audio devices. If you're going to do a USB audio device, follow the USB specification. And you'll hear me say that a couple of times today. That's our number one recommendation. If you're going to do a USB device and you want it to be supported by Apple's drivers, please absolutely follow the USB spec for that class of device. That's the best way to get plug and play functionality on the Macintosh.

With power supplies, the major change, aside from a USB driver, is a new power manager. And this is in 904. It's in the new world-based Macintoshes. And it's Power Manager 2.0. And Power Manager 2.0, which is only on the iMac, iBook, PowerMac, PowerBook families, supports UPSs built in. This will allow you to connect any UPS that conforms to that spec. Another one of those great recommendations. follow the USP class specifications, will automatically work.

We also exported an API. And this allows third parties that want to do UPSs, vendor-specific control panels, monitoring of specific features that aren't supported by us, changing the thresholds. See, we have some specific thresholds. When it hits 50% of battery capacity, put up a warning dialog. When it reaches, I think, 10% or 20%, we do a graceful shutdown. But you may want to do a lot more than that. And you can do that by using these APIs that we've exported. It'll make for really great products. And there have been some product announcements in recent days. I saw a press release come out from APC yesterday that announced that they're supporting our new architecture in Mac OS 904 and using this new USB standard to control their UPS. And they added extra software and they used our API to add extra functionality.

By the way, the USB UPS stuff is part of the USB DDK. So you can go take a look at that, and you can see how to expand upon the basic features that we have. So what's in Mac OS 9? Well, HID devices, keyboards, mice, gaming, UPSs. Amazingly enough, UPSs are actually a HID device. Mass storage, except for CD and tape, we support a wide range of USB mass storage devices automatically. You follow USB spec, you plug it in, our driver loads and recognizes it and supports it. We support V.90, V.25 ter, roughly Haze compatible modems, built in support in Mac OS. You can just build your modem, comply with the spec, plug it in and it works. Audio, as I've already mentioned, we have audio input and output. We both support stereo and monophonic devices.

And printing, we've had for a long while, and this has actually turned out to be pretty powerful, both for people who are printing to PostScript printers and who just use our low-level printer driver with their own chooser extension to talk directly to the printer. We supply that. You don't need to write a low-level driver if your device complies with the USB class specification for printing.

So we've added, with the desktop printing utility, the ability to print directly to USB-connected PostScript printers. Very nice feature. And people who are doing non-post-script printers can still use our class driver to talk to the printer. So they just need to write a chooser extension. So what's in a class specification? I talk about that a lot, and I really need to go into it in some detail to continue to encourage people to follow those specifications. For one thing, it details how the device behaves. You don't need to reinvent the wheel. Please don't. We use those specifications, and quite often the discussions that take place between Apple engineering and developer technical support and myself usually end up down to the realm of where are we not following the specification, what can we do different? And that applies to both Apple and the developer. We appreciate feedback. When we hear that developers are having difficulty, they think the device meets the spec, we really value the dialogue that we have with the developers to ensure that we give the best possible support we can.

These specifications can be found at www.usb.org. I'll talk later about our recommendations in detail, but for right now, if you want to know what's in a spec, go to www.usb.org. So let me talk about the architecture now in Mac OS 9. If you haven't heard this before, I apologize, because I'm going to go quickly, because we have other things we want to show you. The three or four major components are the USB manager, there's a USB expert, a USB services library, and the USB interface module. Now, I think I've got a graphic. Yes, I do. At the very bottom of this whole architecture is actually the USB host controller.

Above that is the USB interface module, or a WIM. And the WIM actually does the translation from the basic USB commands, APIs, to the hardware. So that's our hardware abstraction layer at that lowest level. Above that is the USB services library, the USB manager, and the USB expert. And they all play different roles. So the USB services library takes calls from your drivers and translates them down into the USB interface module. So doing bulk reads, bulk writes, interrupt reads, interrupt writes, and so forth take place through the USB services library.

The USB Expert and Manager are closely related in that they deal with allowing outside applications to request information about what devices are connected, receive notification about what devices have been removed, locate devices, and match drivers to devices when they're connected. All that layer is not necessarily available to all clients. I mean, we couldn't prevent you, but we really, drivers should talk to the USB Services Library, applications, shims, control panels should talk to the expert and the manager as appropriate.

Above that, you can have either a USB shim, which is a special type of code fragment, it's a specific type of a library actually, that gets loaded before the init parade and allows you to set things up if you later on in your init parade need things to happen for you. We give you a good example of that. Serial, USB serial adapters. Quite often you'll have some other init later in the init parade that needs to open a connection to a serial port.

And if you don't initialize or provide the.an,.aout,.bn,.bout interfaces at that earlier point in the initialization process, then when the init comes along, it can't locate them. It won't locate them. So we provide shims, which are a very early way to get in and install extra drivers that you'll need later on during the init parade. Unit table drivers could be located in shims. They could be located just about anywhere. And they provide a translation layer, if you will, between applications that need to do classical I.O. through device drivers. Serial port, again, is a great example. We provide in our modem driver a class driver, sorry, a device driver, a standard unit table device driver that allows legacy applications that are used to using the COM toolbox or just using the.in and.out drivers to talk through to the USB device. Now above that, Mac OS and applications, they pretty much talk to either the USB shim or they talk to the unit table driver. When we talk about the manager and expert, and I mentioned this a few moments ago, one of the things that we stress is that we follow the USB standards rules on how do you match drivers to devices. And you need to go look at the USB spec to get the full details on this, or in our USB API reference guide for the Mac OS. I think there's six acronyms in there. We describe that matching process, and it includes looking at the class and subclass of the device, the protocol of the device, the vendor and product ID, and the best possible match wins. So when you write your driver and you create your driver description structure in Mac OS 9, you define what kind of device it supports. And when the Mac OS detects that device being attached, it will look inside your device driver to see what's supported.

We also allow for people who have registered, either in a shim or unit table driver, to be notified when a device is connected. That's also the responsibility of the USB manager and expert. They cooperate in terms of locating drivers, installing the drivers, and notifying people above them that there has been something connected or disconnected.

When you're writing a USB device driver, The things that you need to do pretty much always are select the configuration of the device if you need something different from the first configuration, find the interface you care about, if it's a vendor-specific driver, find the pipes or endpoints within that device, and then accessing those pipes. That's the responsibility of the driver. We actually think of USB device drivers predominantly as being just data transport layers so you create this driver that then will push or pull data up to a higher level the shim or the unit table driver A device is connected, and this is one of the little magical parts of how USB works. The part that actually detects it, the hardware portion that actually detects it, is in the hub. The hub itself is electrically monitoring what devices are connected, or at least that a device is connected is a better way to put it. And our hub driver will receive notification that a new device has been attached. And when it does, it goes out to that device, it enumerates the device, it examines the device, and reports what kind of device it is up to the manager. When the manager, sorry, the expert detects this, it will then go off and locate an appropriate driver and send notification. As that's happening, the device itself, the driver itself, is actually called through its validate hardware routine to verify that this actually is a good device. It then calls the initialization routine, and the driver starts functioning. As soon as the device driver is initialized, that's when we send notification to people who have requested it. I described previously that driver matching depends upon looking in the driver itself. Now, in Mac OS 9, we have a driver description structure. In Mac OS X, we have an XML bundle. In many ways, functionally, they perform the same duties. That is, they describe what's in the device driver, which devices it supports, vendor name-- sorry, vendor ID, product ID, et cetera.

In 9, the expert uses that data to determine whether the driver is vendor-specific or if it's generic or standard classes. Now, so far, Apple's been the only people providing standard device drivers, and we like it that way. We'd prefer that if you're writing drivers, please only write vendor-specific drivers. And they take precedence over Apple's standard drivers. So if you have a device that's a standard class, but you really want to add your own special features or functionality, you can do that. It will take priority over Apple's standard drivers.

So what's inside of a USB driver? Well, the driver description structure, obviously, with all the information, product ID, vendor ID, class, subclass, et cetera. A driver dispatch table, which has entry points in for validate hardware, device initialization, interface initialization, a notification routine where we can send you power management messages, et cetera, and a finalize routine. And it's very straightforward to take a USB driver and add these functions in and get them to work just by those five basic entry points. One change that we did make back in Mac OS, I think I'll say 8.6, was that we created with USB 1.2 the ability for you, the developer, to put multiple drivers into a single file. We parsed through that file looking at all of the drivers and finding the best match. no longer starting with 8.6 anyway, do you need to have multiple driver files? And we would prefer you use 8.6, use this feature in 1.2. That's a better way of saying it. Use the feature in 1.2 to contain multiple drivers. Don't put multiple driver files in the extensions folder anymore. And what we've been telling to people in general is we really want you to-- focus on eight six if somebody has eight five or eight five one it's a free upgrade to eight six you can just go to the apple website and tell your customers that's where your customers can download it that's what we want people to do is to have them upgrade if they're at eight five or eight five one to eight six to at least get to usb one point two Inside of the driver description structure, there's a number of important tags. And as I said, this matches the XML bundle description in that it has a vendor and product ID. It has a class, subclass, and protocol for the device.

It has a class, subclass, and protocol for the interface. You can match either as an interface driver or you can match as a device driver. And we have some driver loading options. These driver loading options allow you to tag that this driver should only be loaded for a, as a vendor specific driver.

It shouldn't be loaded as a standard class driver. We ask that you set that bit appropriately. And if, whether or not it should load as an interface driver, and there's a tag in there also that says must match protocol. So we provide some pretty powerful means for you to clearly define which device your driver should load for.

So how do you get started with Mac OS 9? Well, you go get our USB DDK from the Apple Developer website, developer.apple.com. It's got an entry point in there for hardware. You follow that to USB, and we have a nice getting started page for writing USB drivers. There's also a USB mailing list, which is on that website, that you can join in. And that is a nice collaborative environment where a lot of developers share experiences and discuss solutions. And both myself and the USB engineering team watch that very closely to see if there's things we should jump in with and help with where we can. And of course, we want you to go to the USB website, the www.usb.org, and get those specifications. I've listed the websites here. I'll stay on this slide for a few moments if you want to copy it down. So the exact web address for USB developers is developer.apple.com/hardware/usb/devinfo .htm. We want you to join the mailing list. We have a link there to a page where you can find information on joining the mailing list. And our DDK is also available. Our DDK we've been very aggressively releasing and I believe we will do our best to continue in the same way we've been doing for the last two years. We get that DDK out in beta form early for you so you can test your devices with it. The other corollary to that is that as ADC members, we really want you to go to the ADC seed site and get the other updates that are available for the OS, whether they be multimedia update if it's released, software updates for the OS, et cetera. Please watch very closely USB-DDK and watch very closely the Mac OS updates as they come on the ADC seed site.

One of the reasons why that's very important to us is we hate with a passion hearing after we've gone GM with an OS update that there is all kinds of new problems that have been revealed with that update. We want you to report those problems to us far in advance of us going GM. That's the only opportunity we have to fix them. So please get the DEK. Please go to the ADC seed site and get the OS updates.

So that concludes my initial presentation. And I want to invite Rich Kubota up here. One of the things-- like I said, we pulled the inside USB hardware section to talk to you about the USB software locator. You might have seen the announcements earlier this week. We have intentionally worked very hard to be proactive and listen to your feedback on USB software locator. We did research, and we found that the reason people weren't adopting USB Software Locator was because only the Apple installer was supported. We took that feedback, we ran with it, and I'm pleased to announce that we will be giving out, at the end of this session today, beta CDs, beta copies of the Aladdin Installer Maker for free for USB Software Locator. This is a special deal, in fact. In fact, it's a free, for USB devices only, one year license to Installer Maker. The CD itself is the coupon. So if you get a free CD, hold on to that CD. If you lose that CD, that's your coupon. You got to have that to get the free update. So with that, Rich, do you want to come over and do your presentation on the -- thank you.

Well, I'm here to discuss the updates to the USB software locator, and first I would like to acknowledge the efforts made by Aladdin Systems to make all of this possible. They've streamlined the process, so we've really simplified the software locator process to make it easier for you to adopt. What I'm going to do is describe first the process by which the software locator works and describe the specific details you would need to take in order to adopt this solution. The way that the software locator process works takes advantage of two important changes that have been made. The first change is implemented in System Software 904, and that is that the software update now supports the recognition of disk copy images. It's important for a reason I'll get into in a second. And the second is the fact that Aladdin Systems has enhanced their installer maker application to work in cooperation with the installer engine. First of all, when your user attaches your device and there is no USB driver found, what will happen is that a message is sent to Software Update by USB Software Locator to ask, well, let's see if we can find a device.

The user is presented with a dialog asking whether you want to search the Internet, and assuming they click OK, then we search the USB database, which will return information about whether a vendor has registered a driver package for that device. That information is returned back to the user and they are then presented with the choice of either downloading the package or not. So let's assume they download the package. With the 904, assuming that a disk copy image of the package has been provided, that disk copy image is downloaded, it is mounted onto the volume and our Apple installer engine is launched.

It will look within the disk copy volume for an Apple installer script which we are providing and that installer script consists of a single code resource whose purpose is to look for the Aladdin stuff in installer maker document, sub launch it and allow that document to proceed. Now one of the enhancements, an important enhancement to the installer maker application is that we can now send it Apple events to tell it to hide any user interface so that it can operate seamlessly with the Apple installer engine. This was a demonstration that Jay presented in the hardware keynote address on Tuesday. So as soon as the installer maker installer completes, control is returned back to the installer script code resource, which will then look for whether a USB shim has been installed and activate it. And by doing this activation there is no need to restart the system. Control then comes back to USB and it will perform the operation of matching the newly installed driver with the device that is present.

So what do we do to get started? The first thing I'll tell you about this is, this is probably where you will spend most of your time, because if any of you have used Installer Maker, it's a very simple application to run. So first of all, I would recommend that you get the USB Tech Note, the software locator Tech Note. It is available as part of the USB DDK. It's been there since the 135 release. It's there in the 141 release. And it will give you the important information about the process by which you register a package. The web address is located there, but if you already have the DDK, you will have that tech note as part of the DDK. You then need to get an Apple Connect ID, and assuming that most of you have already registered with the ADR or Apple Developer Relations program, you have one, so that should be very easy. But if you don't, there is a free online registration process by which you can get an ID. You do not have to become paid members to get this. We just need to be able to have a way to track you entering into the database. The next part is that we need to have you registered with DTS. You send a request to DTS asking that you want to be registered for a specific vendor ID. Now at this time we do request that the representative of the company for the specific vendor ID be the one to register that access. Next, you create your installer maker document. And that's pretty much running installer maker. You first want to download the package. You will be getting the package as part of the CD at the end of this talk. And you also have the option of downloading it from their site. You then -- if you're going to -- if you do have a shim as part of your installation, we want to create a very simple text file. It's named install.dat. And the purpose of that is that the code resource will look for that document and look for the name of the shim so that we know what file to activate. You add an installer script which is part of this package and then you put everything in a folder and with this copy you would create a disk copy image. You would then use installer maker to encode the image into bin, Mac binary or.hqx format and then finally place it on an HTTP server or you can also do it on an FTP server. We strongly recommend that you place it onto a web server primarily because a lot of users may be behind firewalls and may not have their system set for passive mode to access an FTP server. The next interesting part is using the USB editor web page. At this point I will do a demo to show what the USB editor web page looks like. Primarily its purpose is to provide information about the device ID that you're going to support and then also to indicate the software package will be downloaded. And you can also specify information about what protocol it is, what version of USB is required, and other particular pieces of information to provide back for the system to check to see that the current requirements are present. So, the simple part of testing the update is, once you've done all this, plug the device in. Assuming you have system 904, but I forgot one important step. As part of the USB software locator toolkit, which we provide in the DDK, we need you first to set the software update so that it will look at a production server. We've designed our software update process so that there are two different servers. There's a production server, which everybody in the world will see, and then we have a staging server that's specially designed for test processes. By default, the software update process is designed to look for the production server. So that's all the users with 904. But we want you to be able to test this without having your users worry about it. So there is an option, but it's not provided with the system to tell you a software update to look at a staging server and not at the production server. So with the software locator switch, you can set this option.

You would then connect your device and if everything is set up, you'll get the two dialogues I mentioned and then the download process will begin. You will momentarily see a disk copy image mounted and in a second later it will indicate that the software package has been downloaded and ideally your software driver should be active for your device.

Now for a quick demo, could I have demo two active? Thank you. So the web page I mentioned takes you to this, and this is where you would enter your account name. So here we have Rich Kubota. I-C-H-K-U-B-O-T-A. And I enter my Connect password. Click Connect. I happen to-- I'm demonstrating an Anchorchips site right now. So I've gone in here. I've already-- if this is the first time you would add a device, I have already created a device for a sample USB driver.

You mention the name of the driver or the device you're going to support in the name field. You specify the class of the device. Now, one thing I should mention, when you registered, you mentioned a product ID, a vendor ID. So we've already associated this vendor ID with the record here. So now at this point, you're here to define your product. You specify the type of class. There's a pop-up to display the various types of classes that we support, the subclass of the product, and for vendor-specific, it would be 255, the product ID field, and this will be in decimal, not in the hex, which USB Prober would display, and the protocol field and your version. You would save this information, and once you save this information, you can now add a software package to support the device. I've already created one here. And here you specify where the driver will be downloaded from, what size it is. But there's also an important part of this entry, and that is the field that says move to production. Once you have everything working, you would set the pop-up to yes. And it will then, next time that we're scanning for the updates, we will see that this is now set to yes, and we will move the information to the production server, and it will be live to your users. Indicate the name of the product in the file name field, the size of the download, and destination folder where you want it to go. In the current process, it's going to go to a temporary folder off the desktop, and it will be trashed the next time you reboot it. The software is required to use the device. You do not require a restart after installation, and then you can specify the language. And then in this download URL, you would enter the name, what the address is to access the software package.

There's the product name, and then you can specify here that you want to require USB 1.4.1 to be present. This can be important because by setting this field, people with 9-0 systems will not be able to have this software package offered as a possibility. You specify the binhex file name, and again, this can be a Mac binary file name, and the version number of this download. You would save this information.

I'm not going to save it here, and return back. And that's pretty much the registration process right there. At this time, I'd like to recognize a fellow member of the USB team. In the Apple directory, he's simply listed as a senior software engineer. But for all of us, he is the architect for USB on Mac OS X. Rhodes Hollowell.

So Rich, I've got great news. So MindVision has just come to us and said that they will be adding support for USB Software Locator in a very short while. So not only will the Apple installer work, Aladdin installer maker, and MindVision as well. So I'm very pleased to congratulate MindVision for their participation. All right. Thanks, guys.

I'm here to talk about where we are in Mac OS X with USB. A lot of this is a review of stuff that you've seen in the I/O Kit presentation or in the Firewire presentation because it's very, very similar. Within Mac OS X, this is sort of an overview. Drivers, USB drivers in Mac OS X will be using I/O Kit and will be generally written in C++, at least the USB classes that we provide in I/O Kit in Mac OS X are in C++. I'm going to talk a little bit about the difference between kernel mode drivers and user mode drivers, very similar to the FireWire drivers. I'm going to talk a little bit about how Mac OS X does driver matching and loading. about the benefits of having blocking I/O in Mac OS X and a little bit about the multi-threaded drivers.

Comparing Mac OS 9 and Mac OS X, in Mac OS 9, the driver description is in the code fragment of the driver, whereas in Mac OS X, it's part of the XML bundle for the driver. Scheduling under Mac OS 9 is all done asynchronously with callback routines in Mac OS X. You're not required to use asynchronous drivers because you can do blocking I/O.

programming in Mac OS 9. We pretty much--all of our interfaces are C interfaces. In Mac OS X, we use embedded C++, just like the rest of I/O Kit, and it's object-oriented programming with all the benefits therein. The driver framework inside of Mac OS 9 is specific to USB, whereas in Mac OS X we get all of I/O Kit to work with. So, for example, whereas in Mac OS 9, the notification of the addition or removal of USB devices is handled by the USB manager, in Mac OS X it's handled by I/O Kit. In I/O Kit, I/O Kit provides us with many services that were in the Mac OS 9 were provided by the USB system itself, which frees up USB to be, well, much simpler. The XML bundle in the Mac OS X driver contains the driver information necessary for I/O Kit to match and load a driver, and because we were written in C++, it speeds the development time by allowing object inheritance from standard I/O Kit objects. makes the APIs just a little cleaner.

So when you're developing a USB driver in Mac OS X, similar to FireWire drivers, you want to ask yourself, first of all, do I need to write a kernel mode driver or a user mode driver? Does my driver live in kernel space where resources are expensive or in user space where resources are relatively cheap?

And to answer this question, you need to ask four basic questions, very similar to Firewire. Is your driver used by the kernel? If so, it needs to be a kernel driver. Is your driver used by very many of the tasks in the system? If so, it needs to be a kernel driver. Does your driver require access to primary interrupts? If so, it should be a kernel driver. And do you need tight synchronization between various tasks that your driver performs? And if so, you need a kernel driver.

So some concrete examples of drivers that would be kernel mode drivers versus user mode drivers. Keyboards and mice need to be kernel drivers because they are used by just about every task, every user visible task in the system. A mass storage driver would need to be a kernel mode driver because the kernel would use the mass storage for storage. Whereas a scanner driver would be a user mode driver, or a printer driver would be a user mode driver. A CDR driver, again, we go back to the FireWire example, the CD part of it where you're just looking at a CD in the device would tend to be a kernel mode driver, whereas the part of the driver that actually wrote to the CDR device would be a user mode driver.

The USB stack inside of I/O Kit shares in the rest of the I/O Kit stack in that you can perform blocking I/O. It has, it's multi-threaded and so you can block, from your driver can block without blocking the rest of the USB system. This simplifies driver designs by not making a requirement that you have all kinds of callback routines in your driver but callback routines are available if you need them.

Part of an I/O Kit driver, and therefore a USB driver, is an XML driver description. This is a file that is originally edited with text that contains all the information that otherwise appears in Mac OS 9, it appears as in the driver description table, and contains information such as product and vendor IDs, class, subclass protocol of the device, and gives the information necessary for I/O Kit to match a driver for a particular device or a particular interface within a device.

The way driver loading works in Mac OS X is the following. The--there is a hub driver attached that-- that is driving every hub in the system, including--including the root hubs. And this hub driver can detect when a device is attached to the USB bus, and it enumerates the device. It tells the controller to create an IOUSB device object for that device, and then it registers that object with I/O Kit, causing that IOUSB device object to become what is called in I/O Kit a nub. That nub is now looked-- we look through the system, all of the XML files, basically, that are in the system, and I/O Kit finds the appropriate driver to load against that nub. It loads it, attaches it to the nub, initializes the driver, updates the I/O registry so that this nub now appears in the I/O registry, and then the driver starts running and can load other objects as necessary.

So here's a picture of what Mac OS kernel drivers would look like. At the bottom level, we have the USB nub for the USB controller itself, which is a PCI device. We have the PCI driver for that kernel, which we call Apple OHCI. We have a couple of USB devices. On top of those devices, we have drivers. and because they're kernel drivers, they both--they live below the kernel boundary. And there are other operating system objects that might be attached to those drivers to provide service across the kernel boundary up to the application or the user layer.

A user mode driver looks very similar for a while. You have the USB knob to which the USB controller object driver is attached. You have a USB device, and then the driver for that device is actually a user mode driver that lives above the kernel boundary. For example, a scanner driver.

So where does USB live? Those of you who've been to the I/O Kit presentation or the FireWire presentation recognize this slide. uh... the the u_s_b_ drivers the u_s_b_ stack lives with i'll kit in the in the kernel, next to the Mach kernel, and as William said, there's a dotted line which sort of indicates that it may be possible that a USB driver would not actually have to use the file system or networking or the BSD kernel in order to talk to the layers above the kernel boundary.

So now if you're like me, and I know that I am, there is a more concrete example for how we match and load a driver would be useful. So we're going to start here, and I'm going to talk about human interface devices, specifically mice and keyboards, because those are drivers that the source for these two drivers is in Darwin. So you can actually look at Darwin and follow along with what I'm saying here. So at the bottom layer, we have the driver for the USB controller. The name of this class that this object is is Apple OHCI, and it's a subclass of the IOUSB controller class. Once this object comes, it loads a root... It instantiates a root hub, loads the root hub driver, and that root hub driver then tells the controller to go out onto the bus and find all the USB devices. So it goes out and it finds a IOUSB... It finds two USB devices in this case and instantiates what are called nubs. These are IOUSB device nubs. One of them will end up having a name in the I.O. registry of, in this case, M4848, which is the old original Apple USB mouse, or M2452, which is the original Apple USB keyboard.

So these are not drivers. These are nubs that represent the device, and they contain inside of their objects information about the device. The I/O Kit then tries to load drivers for these devices, and as they are both composite devices, the driver that gets loaded is the Apple composite driver.

Each one of them gets a separate instantiation of the Apple Composite driver. The Apple Composite driver then goes out and sets and chooses a configuration in the device. And in this case it always chooses the first configuration. And then it asks for the interfaces that are part of that configuration.

These interfaces then appear. These are nubs that the, that are attached to the device. They contain information about the class, subclass, protocol, and so forth of the interface. And then are published to I/O Kit. I/O Kit then goes out and says, okay, now I need drivers for these two devices. Well, for the mouse, the driver that gets loaded is the Apple mouse driver. For the keyboard, the driver that gets loaded is the Apple keyboard driver. The Apple mouse driver is a subclass of the IOHI pointing class, which in turn is a subclass of the IOHI device class. The keyboard similarly is a subclass of IOHI keyboard, which is a subclass of IOHI device.

So at this point, we now have a driver that knows how to get information from that, through that interface from that device. So what is it going to do with that information? Well, within Mac OS X, there is, in this particular case, an object that was instantiated long before this occurred called the IOHID system. And the IOHID system tells itself, tells the system, tells I/O Kit when it is instantiated that it wants to know about any device that appears that is a subclass of IOHI device. So both of these are. It is notified about both of them, and it attaches itself to both of them.

The IOHID system has as part of it the IOHID user client, which is the part that allows it to pass information across the kernel boundary, and its client across the kernel boundary is the window manager. So in this, so, so as, because the mouse complies to an HI device or is a subclass of HI device and the keyboard is a subclass of HI device, they automatically get attached to the HID system or in fact the HID system gets attached to them and we get information passed up to the system without any other effort on the, on the part of the driver/writer.

So I want to talk a little bit about the various classes that make up the USB family in Mac OS X. The I/O USB controller class is the heart of the USB family, and it is through this class that the data transfer occurs to the actual hardware. This is what we would call the WIM in Mac OS 9. The Apple OHCI driver is a particular instantiation of this class that accesses the USB host controller driver inside of every Mac that we have today.

The I/O USB device class is a class that gets instantiated once per device on the USB bus. And this class is responsible for maintaining the node ID. It is matched by I/O Kit based on the USB vendor ID, product ID, and so forth. And its main job is to publish nubs of class I/O USB interface. the IOU SB interface class. There is one of these instantiated per interface on a particular configuration per device. And this class instantiates and distributes to the drivers objects of type I O U S B pipe.

The I/O USB pipe class is the object that the drivers will use to actually read and write data to and from the USB bus. There's one pipe-- there's one pipe-- per interface, sorry, there's one of these objects per pipe on each interface. And this object provides the methods for data transfer. So a driver will be attached to an I/O USB interface nub and will ask that interface nub to give it the pipes.

In our example that I showed a minute ago, if the device is an IOHI device currently in DP4, if that device is either HI pointing or HI keyboard, then the HID system will automatically attach to it, and there is an API that the HID system uses to pass keyboard and mouse data up to the user space of Mac OS X. So I want to switch to demo one.

And what we have here is a system running DP4, and I wanted to show the-- the--the--the HID stack that I was talking about using a tool that's in DP4 called I/O Registry Explorer. So with this tool, you'll see here that we have the Apple OHCI. That is the--the object in I/O Registry Explorer. That is the driver for the USB controller chip. And it has, and this is the I/O service plane, and it has four devices attached to it. It has the root hub. It has a hub inside the keyboard. It has the keyboard, which on my slide was M2452, and it has the mouse. So we will look at the mouse. The Apple USB mouse, this is, this is the class of this object is I/O USB device, but its name is USB Apple mouse. This is a nub, a driver was loaded against this nub. In this case the name of the driver was Apple Composite.

The Apple composite driver told the USB mouse to publish an interface. There's the interface. This interface was then published and I/O Kit matched the driver against it. The name of the driver that was matched against it is Apple Mouse. This Apple Mouse, the class name is Apple Mouse. The subclass was, is I/O HI pointing and the sub, and that in turn is a subclass of I/O HI device. So because it's an I/O HI device, we have the HID system that was automatically notified and matched against the Apple mouse and the HID user client is then used to pass the mouse information up to the window manager. And I think that's it for the demo. So we'll go back to the slides. And.

that's it for me. So I guess Craig comes back up. Thank you. Thanks, Rhodes. So let's compare the differences between Mac OS 9 and Mac OS X. Really not that dramatic. The APIs are essentially the same. I'm not going to claim that the names are identical, but the basic functionality is you have the ability to read and write on pipes. You have the ability to locate those pipes in the interface. You can use, if you need to, callback routines. So in many ways, the mechanisms that you use in 9 would be the same mechanisms for communicating with a device that you will use in 10. The driver description mechanism of vendor ID, product ID, class, subclass, protocol, we follow the rules in the USB specification for matching those devices. Thank you.

So what's in DP4? Well, as Rhodes pointed out, we have the keyboard and mouse. We also have USB printing to PostScript printers. So we certainly are going to do more later. One thing I do want to mention, though, is that we're fine tuning the USB driver and object names and expect them to change after DP4. We haven't finalized those names yet.

So what's going to be in the public beta? Well, what's in DP4 plus some basic USB mass storage? That's expected. That's what we're planning on doing for public beta, is to add basic USB mass storage, and that basically means things like Zuper disks, ZIP drives, et cetera. Very basic USB mass storage. So beyond Mac OS X, public beta, we're going to add much of the same functionality we have in 9 to 10. So, HID devices, hopefully you've seen some of the HID manager presentation that talked about what we're going to be doing in Mac OS X. We will have the support in the HID manager for USB HID devices.

So right now, as an example, you can use the HID parser in Mac OS, the HID support library in Mac OS 9 to do this. The same functionality would be achievable with the HID manager in Mac OS X, where you You can control USB-enabled UPSs, USB-enabled displays. If you have a HID interface in a USB display, you would be able to write a display control panel that would use that HID interface to control the display. Gaming devices, all the HID USB devices I've seen comply with the standard with very rare exception. And you'll be able to use the HID manager in Mac OS X to use that.

Tablets and graphical other pointing devices will also be accessible through the HID manager. We're still going to have USB printing to PostScript printers. We're going to have more USB mass storage devices. I'm not really able to predict exactly which ones will be just yet, but we're certainly going to add a lot more. And we'll also support USB audio.

Oh, and one last thing, that modem, that V.90, V.25, TUR, Hayes compatible modem will also be supported sometime after Mac OS X public beta. So what do I want you to take away from here today? As far as Mac OS X goes, we believe that C++, embedded C++ and I/O Kit is a great way of writing drivers. All of our drivers use I/O Kit. We find it very powerful. If you listen to Dean Lee's talk in the I/O Kit presentation, they were, they came up with the architecture and as they started writing drivers they became more and more pleased with the object inheritance and the ability to do blocking I/O.

We also updated, as you might expect, as you've seen on these slides, we now have a Mach kernel. We have a BSD kernel that allows for really great driver writing. We're blocking I/O and multi-threading, et cetera. And I can't tell you that you'll be able to just take your USB drivers from 9 and directly take the sources over into 10 and go forward. But based on your understanding of how your Mac OS 9 driver works, the same basic fundamental mechanisms of communicating across pipes and pushing data up to higher level objects will be very similar in 10 as it is in 9. So how do you get started with Mac OS X? Well, DP4. Go install it. Go play with it. Go look at it. Go investigate it.

Look at the KDK. Go take a look at the KDK. It has some example drivers in there today. Certainly we're working on improving the documentation. But in the meantime, please do the I/O Kit tutorials that come with the KDK and read through the USB header files. That will give you a very definite direction of where we're going and what we're doing.

So what do we recommend? Well, I don't know if I put it on the slide, but I will certainly re-emphasize, it's very key. Please, for Mac OS 9, get the USB DDK, Try it. Go to the ADC seed site. Get the OS updates that we do. Try those. Give us feedback. We really want to know what you think. We really want to get feedback. File bugs using ADC's online bug reporting system. Let us know before we go GM, because we can't fix a GM release after we've released it. Please try the DDK. Try the ADC seed site software releases. That's very key.

So what you need to do to be successful with USB is you absolutely need to be in compliance with the USB class specifications. Go to www.usb.org. Get the class specifications. Read them, follow them, implement your devices to them. Follow the standard classes. Follow the USB specification and device enumeration and power consumption and all of the communication protocols. That's absolutely crucial. We follow those specs as best we can. You should too. At least if you do, you'll tremendously improve your development time because you'll be able to use the standard Apple drivers.

If you look at those specifications and you find that they don't meet your needs exactly, then there's a good thing you can do. Join the USB-IF implementers forum. Go to the device working groups. Tell them what you want. Participate in the voting process. Don't just look at a class specification and decide this is not for me. It doesn't do what I want. If you feel passionately about getting some feature put into the class specification, join the EIF. Get your vendor ID. Go to the device working groups, participate in that discussion, and get your features added. I heard earlier today that, for example, that the video imaging, live video features of USB, that that spec is still being talked about. If you want to do a USB video device, please go join the USBIF, go to the device working groups, give your feedback on what you think video devices should be. It's important. As far as business planning stuff goes, tell this to your marketing people. License the Mac OS logo. Put it on your box. Make it clear and distinct that this works for the Macintosh. Follow the guidelines for the logo usage. Put it on your marketing collateral. Put it on your advertising. Mention it in your press releases. Do that.

That's the way that we communicate to our customers that this product works for the Mac. If your marketing people come to you and say, "Here's the box design and it doesn't have the Mac OS logo and prominently displayed on the front," tell them, Emphatically, go get the Mac OS logo license, and we can help with that. The logo license is free. There's recommendations on how to use it in terms of sizing and placement, but absolutely go get the Mac OS logo and use it. Put your products in the Macintosh products guide. As ADC members, that's free. Well, it wouldn't be expensive. It wouldn't accept you have to become an ADC member. Go become an ADC member. Get your products listed in the products guide. We take that products guide online database and we periodically press CDs and give those CDs out at Macworld. If you want your customers, your potential customers, to know about your products, get them in the products guide. You'll note that on our home page now, www.apple.com, in the very center, there's a Made for Mac click spot, a button. That takes your customers to the Macintosh products guide. If you want your products seen by customers, get it in the Macintosh products guide.

Support the USB software locator. We've listened really hard. We've worked really hard to understand what the issues are. We've talked to developers whose devices aren't in the software locator and asked them to tell us what the issues were. We took that feedback and we aggressively got Aladdin, and I'm very pleased to say again that MindVision has stepped up and they're going to do the same thing for their installer. You don't have to use Apple's installer. That's the feedback we heard. You didn't like using the Apple installer to use the USB software locator. We've addressed that, and you should now have no reason for your vendor-specific devices to not have your software on the USB software locator.

So how do you make a device class compliant? I should have put this slide a little earlier, but I'll do it now. Join the implementers forum. They assign USB vendor IDs. We have a number of products out there-- not ours. We see a number of products out there where they've the actual product or company name on the device is different than the vendor ID that's in the device itself. So you'll see four companies, entirely different devices, using the same vendor ID. Well, I tell you, with the USB software locator, we have a little bit of a problem. We try to match up your developer connection ID, connect ID, with the vendor ID. We don't want one developer going in and messing around with another person's software.

So please go join the USB-I app, get your own unique vendor ID, and use it. Don't create a device where you buy a chip from somebody else and just use their vendor ID. Get your own vendor ID. The other thing that they do that you should participate in is they have these periodic compliance workshops.

I think three quarters out of the year they're in Milpitas. The fourth quarter out of the year they're in Taiwan. And these compliant workshops are these great events where everybody walks around with their devices, plugs them into the OS, whatever that OS is, ours, somebody, some of our competitors, et cetera, and verifies that they function. And it's great feedback for us. We try to go when we've got no conflicts with our engineering schedules to meet with the developers and see what we can do to help make our software better and help make their devices better. Participate in the USB device working groups. If you feel passionately, join that process. Make your voice heard. And as I've said a couple of times, www.usb.org.