WWDC2003 Session 509

Transcript

Kind: captions Language: en you don't have to install any drivers it works automatically so I'm going to demo for please just a couple of quick devices I want to show off these are these are products that are coming to the Mac thanks the first one is made by a company called 3d connection ignores a lab tech label on here 3d connection bought them the six degree-of-freedom controller and it allows you to move objects in three-dimensional space automatically I have a demo app here coach on one thing which will bring up a cube rotating and then by moving this odd by pulling out and pushing in and like the key will rotate it's not moving up I love demos when they don't work still not working Jeff all right well I'm going to skip that demo I can assure you that it does work okay see the other products that we have from the same company 3d connection is a keyboard that has one of the 6th degree freedom controllers built in which is very cool these kinds of keyboards can be used to do video editing almost anything where you need a jog shuttle would work but what I'm mostly interested in seeing happen as cad cam applications adopt six degree-of-freedom controllers afterwards if you've got an interest in that please come up and talk to jeff lowe and i would be really keen to work with you to make that happen the final of sample device that i have i want to show off and it is from a TI so probably a lot of you think that a TI makes really great video cards may be occasional TV tuner but they also make a remote and the remote has buttons on it that will bring up web browser it will play music as well oh I'm going to the apple internal website you can play music you can control watching control the TV if you get a TV tuner it's a really great little remote so with that when we turn it over to guys and they will go into hidden force feedback thanks [Applause] I am rob yepez from the city manager engineer and the I okay team for Apple and today we're just going to briefly go over the head manager basically we'll do is we'll talk about what it is the hit implementation on Mac OS 10 some improvements that we've added since Jaguar 10.2 and some techniques for using the hit manager hopefully what your learn here is how it'd fit since Mac OS 10 and how to effectively use the head manager so first off what is hit well hit stands for human interface device is a specification developed by the USB implementers forum to cover devices that humans use to interact with the system some examples are your standard keyboard and mouse front panel controls which actually might be your controls on the front of your monitor or controls on your USB speakers gamers simulation devices like the steering wheel over here or devices don't actually require human interaction so that would be like uh north oral uninterruptible power sources or credit card swipers or badge readers so let's cover some brief terminology the first thing is a hit a report and basically what this is is the raw data that's actually sent to or received from the device it can actually pulled or interrupt ribbon and there's really three types of reports input report which basically reports that a receipt from the device and it's pretty much read only an output report is a report that's sent to the device and it's right only and the feature report is actually combination of the two it can be sent to or received from the device the next term is an element and basically an element covers the apartheid on the report the behavior is actually covered by its usage and usage page and there's really two different types of elements the data element which there's three subtypes of the input output and features that we covered earlier and a collection element and collections actually are useful for representing relationships between two or more data objects and there is five different types of collections the physical application logical report and names array but first two will actually cover in more detail so there's an example descriptor bra of a hid mal so the first item we're looking at here is actually the application collection and what this does is actually tip off the system of what the intended behaviors decides is the next collection is a physical collection for the pointer and basically what we're doing here is we're grouping together the buttons and the axes because it makes sense for them to be group together that way in the next example here is the declaration of the actual button element but those you see here we've got a a report count of three and the report sides of warrants base what we're doing here is declaring three objects that are of one bit each and basically what this will represent is buttons one through three the next items that we're declaring here are the x and y axes and basically these are two 8-bit values that represents both the x and y axes now one thing you'll notice is that the buttons the input was actually absolute and for the axes are relative so basically the absolute type elements are based on a fixed origin or absolute is based on absolute is based on a fixed origin and relative is based on changing origins from different from our changing actions so an example of this would be a mouse would be a relative type of value whereas a tablet would probably want a fixed origin or absolute coordinate system so now that we've got a pretty much a basic understanding of what hit is will kind of jump into how the stack is actually implemented on OS 10 and the hit manager so basically the hidden manager is the abstraction layer of how to interact device for receiving the raw end it basically consists of three layers the hid drivers at the lowest layer the kernel architecture and the user space API and this is kind of a diagram showing how these actually interact with each other the application being up at the top portion communicating with the i/o had live which then again crosses the kernel boundary and communicates directly with the devices so basically a hit driver is an i/o service at subclass loss of i/o head device the transport is not actually restricted to USB and it actually provides an opportunity for other developers to provide support for cereal and firewire devices one thing is we are normalized on the USB HID specification so then if you are creating a third-party driver we do ask that you translate the report descriptor and reports to actually work with the USB spec so that it could work fully with the head manager so an example of a device that might want to be have its own hit driver is a serial whiteboard device right now by default when you plug it in it will not work with the system but if somebody writes a specific driver and goes ahead and creates a USB report descriptor and handles and translates the report it will go ahead and behave like you similar to a USB tablet so the next layer is the i/o head family and it is actually the kind of the meat of the whole hit manager it's just fun people doing a lot of the work and essentially what it does this will parse the hit reports and split them up into the individual elements that make more sense to an application developer it also reacts or interact directly with the i/o head lib and allows like the bridging between the application and the device itself it maintains the shared memory that contains the current values of the elements and it also is responsible for publishing the properties of that device in the i/o registry so this is useful for when you want to actually match up the device to locate a device or locate the different elements within a device so when going through the registry there are certain key value pairs that are defined and these are located in IOH keys eh so for device wide constants they start with k io hit and element wide constant start with Kayla head element and this will show up later on as we show examples of what these things look like in the IR registry so this is the example I Oh registry entry for a hid device right here this is just a mouse and you know it has the vendor ID the location transport and any other properties you'd expect for a USB device or any other devices to it divides the two properties that you're going to be interested in as an application developer are the primary usage and primary usage page and essentially what this does is it is the top-level application collection and what it is is the tips off to you the developer what this device actually does so right here the primary usage page of one is the generic desktop and the primary usage to is a mouse as you see also the bottom there's an element property as well and that's pretty much the the i/o register array of elements that are defined as well and so when we go to the next example here this is the collection element and how it looks inside the registry pretty basic it has an element cookie which is basically our unique identifier for that particular element and describes the usage page and usage see here this is the application collection that has the the use of page of 1 and 2 so pretty much the the mouse or describing the behavior of the mouse and then here is a example of the registry entry for an actual data element so once again it does have an element cookie again so this is the unique identifier for this particular button this is actually button one of a mouse and it shows all the other properties such as the type the size of the min-max and you know unit exponent anything that would be more helpful for you to actually use that particular element so now we'll go to the higher level portion of the hid manager and this is mostly what you'll be concerned with as an application developer is the io his lip and basically its CF plugin texture sort of like the USB CF plugin or firewire see a plugin that communicates directly with the device itself or with the i/o head family and it's broken up into three different interfaces the i/o hid device interface the i/o head Q interface the output transaction interface and each interface is actually defined by a uuid or universally unique identification so the first interface of course is the i/o head device interface and basically with the service is to see if plug-in interface that communicates directly to device and establishes its connection to the device you use this to read and post element values directly so there's basically two types of AP is the standard ap is which rely on the parsed items or polished elements of the device and this is something as an application developer probably you're going to use more because you're not really concerned about how data is actually laid out in terms of the report now for more advanced api's get report and set report these are intended for developers that actually know that devices are communicating with and actually know how the data is laid out and so you're probably wanting to use these more advanced api's so the next thing is the Q interface and this is extremely useful for applications that need to respond every hit event so for example it would be a suppose given a first person shooter mup game you don't want to actually respond to the current value of that element or you know the trigger button but in fact you want to queue up the trigger button events coming in so this will allow you to effectively do that it connects the Q can be set up to be pulled or receive a sink and it certifications and we actually recommend that you use async notifications as your applications do less work pulling the Q and you almost received events almost instantaneously and the last kind of interface we have here is the output transaction interface and essentially what this does is it kind of consolidates the number of reports that you're setting to the device so let's say for example you have a keyboard device and you have basically three LEDs to find on there and you want to toggle the capslock LED and the numlock LED well you if you use this the IO hid device interface you'd set the element values for the caps lock and set the element value for the num lock or what this does is actually send two separate reports to the device and you might actually be blocking what we do here is you would just add it to the output transaction and now instead of sending two separate reports to descend the one down and this is kind of a replacement for sup report for less advanced users you don't actually care about how it's laid out in terms of the report so we've had some improvements to the hidden manager since Jaguar or 10.2 and one of the major things we've added is the ability to seize a hit hit events from a device and essentially what this does is suppose you have a credit card swiper or a barcode reader these devices actually behave and look similar to keyboards and so when you swipe a key you know a credit card or you you read a barcode or whatever it actually spews out key events to the system and this isn't necessarily behavior that you actually want to occur but the system has no idea because it behaves and looks just like a keyboard so if you just want your application to interact it directly and only see those events you would go ahead and sees that device and make sure that the events only come to you you've also added some improvements to the API of course as you may have known in 10.3 to support course feedback we added two new API s4 get report and set report which are the more advanced ApS that I mentioned earlier and then new encounter what I've added is the copy matching elements and essentially what this does is instead of you having to traverse through the registry to find what the capabilities are of the device all you would do is set up a matching dictionary like you do for finding a particular device to find an actual element or see if that device contains the behavior that you're expecting and another API that we've added is set interrupt report handler callback and essentially what this lets you do instead of pulling a device via get report to get the current like report to that device this allows you to actually be notified every time an incoming report comes in from the interrupt in pipe of the device so extremely useful for people who need to do that advanced behavior and so let's start off with some basic techniques on how to use the hid manager in some sample code so if you guys have already messed around I oak it and know how to actually match an advice essentially what we're doing here is go ahead a job creating a matching dictionary to find an hid device what we're doing though is refining the search to actually look for a a mouse they're all mice devices on the on the key on the system so we've done here is create a usage page and usage number rough and then added it to the matching dictionary and then gone ahead and try to find all services matching that particular dictionary or criteria now that we've gone ahead and grab the iterator we go ahead and try to like cycle through all the devices that we found or services that we found not only from founded a device and we've run that particular device the first thing we'll have to do is actually create the iocs plug-in interface and there's something you might be used used to if you mess around with USB devices or firewire devices from user land once you've acquired the vio CF plug-in interface let's go ahead and create an interface to the hid device itself and so we query the interface of that plugin to acquire the the interface of the device now that have required the interface the first thing we need to do is actually open a device for communication so like I mentioned earlier we have actually two different options here for opening the device we can do a standard open which it will just allow it to communicate like it does before and everyone all clients receive events or you can actually perform the Seas right here which will just maintain that you will get direct communication with that device if you do actually aren't able to seize the device you will get in there a return back to you now that we've added the bicep and we actually want to find the capabilities of this device and so let's go ahead and set up a matching dictionary to find all the elements so we do here is you know go ahead and allocate CF dictionary and then add let's see here that we want to find all the button elements on this device so we do is go ahead and add a usage page item inside the dictionary covering the buttons page and then go ahead and try to call copy matching elements to find all the buttons on that device and what it should do is return back to you a CF array containing all the CF dictionary you know registry entries for that device or for that element particular element now that we found all the elements we essentially want to store all the cookies and the cookies are the unique identifier to actually communicate with that particular element and so we just kind of cycle through the the array and store all the cookies into our own internal storage it's kind of a quick test we should just go ahead and grab the value or current value of the first button that we saw and you could easily just do that now that we basically interact with the device we kind of want to see how to actually create a queue interface or you know grab all the all the values from that button behavior that we've seen before so we want to do is add first create the queue so we always the cue from the device interface and then we go ahead and create an internal key with in there and so in this example we're only really creating a cue that's about eight field deep and that's pretty much what we really need or it's all it's essential for us to interact with that device now let's go ahead and cycle through all the buttons that we've collected before and add them individually to that q now that we've added the elements to that q we go ahead and set ourselves up for asynchronous operation so what we do first is create the async event source and what we do is we use this in conjunction with CF run loop and kind of what we set up here with the head manager of his expect us to work only with a CF run loop so after we've added the the event source with to the run loop we go ahead and sent the event call up and this is the callback function that will call in to your your applications to you'll go ahead and drain the queue so as soon as you know events come on the queue we go ahead and trigger your application and we call your callback and now they've got this callback being called you go ahead and cycle through the queue and determine and do whatever operations you want to do on that particular event and it's pretty straightforward so now that we've covered both device and end cues let's go into the output transaction interface and for this one we're not actually going to be using the mouse we described earlier but instead kind of a keyboard and the theme that we've set it up in the same manner so essentially what we have here is the keyboard has both a caps lock and led and a scroll lock or a Catholic led a scroll lock led at an unlock led so we do is go ahead and create the transaction interface and then add those items to the the transaction also what I'm going to do is set the default values so basically what this is is after you've committed a transaction this is the value that this element will revert to and for the next time or a subsequent commit that you do I this transaction so right now we're just going to zero that all out now that we've gone ahead and set the default values and added those elements to the transaction we want to do is set the element values so basically all we're concerned about the thing here is setting the LED values for the caps lock and unlock so we go ahead and turn those on and then set the values after we've done that we go ahead and commit the transaction and essentially what will happen here is both the num lock LED and the Catholic LED will turn on and the scroll lock LED will rain off how do we not actually included the scroll lock led into the transaction its value would have remained the same value that it would have been prior to commit because wastefully what we do is we do not go ahead and change that value it just remains the same value so basically in summary I hope you better outstanding of what a human interface device is kind of a basic understanding of how it is implemented on Mac OS 10 and basic techniques for using the hid manager some additional references are you can look at the hid pages that we have on our developer tech pubs or you can look at how to write a device driver if you're so inclined and if you want a more in-depth knowledge of how it actually works you can look at the USB is hid pages with that I'll turn it over to Fernando veena for USB team to cover for feedback thank you rob we're going to change gears a little bit here and i'll talk about a force feedback and what we've done on michael s then i will start with a brief introduction on what force feedback really is and how we implemented an architecture to support force feedback in our system then I'm gonna give some hints to application developers on some of the api's and what they need to do to support force feedback and then for those who view is there any that i have for feedback devices that are not supported on the system right now what you will need to do in order to provide support for your devices you'll see how force feedback fits in our system hopefully you'll understand why we did what we did and the way we did it and perhaps you also know how you can now take advantage or force feedback and how you as I mentioned will be able to develop a plug-in to work in our system so what is force feedback the official definition by those who know is that it is a technology that enhances the human-computer interface by engaging your sense of touch over here on the podium we have this a force feedback steering wheel but it is important to note that force feedback devices are not limited to gaming devices immersion has this medical device that is used to Train medical professionals on how to perform or how to put an injection on a on a person and it actually provides feedback when the needle pierces the simulated skin and once it goes through the skin when it actually finds the vein and it's it's really cool you know i am not a doctor nor do I play one on TV but it feels just like the real thing and personally you know I would like more nurses to use this types of devices I mentioned the immersion they are the leader in force feedback technology they have several patents and they actually license their technology to several hardware manufacturers so you'll see four sweet back devices that do not have the immersion are not produced by immersion but they have their what they call their toxins technology logo on the box before we delve further into the API so I would like to go through some terminology so that you can understand better what I'm talking about later on a force feedback device is first of all a USB hid-compliant device now the USB HID working group has a specification for what they called physical interface devices which are force feedback devices for speed rack devices do not have to be compliant to this physical interface device a specification in order to work in the system that's why we as we're going to see later have this Hardware plug-in architecture these devices are capable of creating a force or what is called an effect that the user can feel when they're using the device the effects themselves have to be played through software you have to do something in order to make that device create that that feeling and they can be done in either of two ways you can have a programmatic interface where you download the effects and then you massage it modify it starts top etc or actually if you can download something to the to the device and have that device respond automatically to an action by the user so you know the most obvious one is when you have a shoot-'em-up game and personal plane hits the trigger and you get a recoil right away and it's a benefit that the device doesn't automatically because you don't have the latency of going up to the application coming back down and setting up the effect there are really four basic types of effects a constant force effect not surprisingly is a constant effect that varies in any one direction a ramp effect is on effect that increases in strands or decreases in strength in again in one direction not surprisingly a periodic effect is one that varies over time or over strength and then the final one are the condition effects that are as shown on the slide the spring the or the damper and those effects increasing force as the device moves away from the center line so you know if you have a spring effect and you're pulling away from the spring that you know the fourth is going to increase as you're going further and further down briefly some examples of effects on a racing simulation you can have the pavement very and your feedback is going to change depending on whether you are driving on the paved road or your gun of off road and urine on a dirt dirt road and if you have a flight simulation if you have turbulence of course your stick and start shaking and earthing again this is not limited just to gaming simulations there are some programs that make use of force feedback on educational setting and you can have a pendulum or a spring that the application can use to the force feedback device to actually show the user what the effect of that spring actually is so you know it's useful not just for fun so how does force feedback work on our system last fall we decided to work with immersion as I mentioned they are the leaders on force feedback technology and we work with them in order to bring forth feedback support on Mac os10 what we arrived at was a two strong approach there's a force feedback framework for application developers and that force feedback framework uses some hardware vendor specific drivers which we'll see later that are actually just see of plugins to abstract the hardware so that the force feedback frame where itself can use any type of force feedback device we actually ship support for sports feedback in the december of last year the 10-point 2.3 release and initially we have support for several devices with immersion touch sense technology from logitech from immersion themselves from scitech and several others and a couple of weeks after release two games came out actually supporting ports feedback and that was the f1 championship series and NASCAR racing 2002 our goals when we started looking into supporting force feedback on Michael Westen was number one we had a time to market item that we wanted to be out there as soon as possible so that we could start getting more games and people excited in our platform the number two goal that we had was that our target developers were companies that were porting gains from the window world to our world this were everyone Championship Series and NASCAR you know those games existed on the PC we wanted to bring them over and have wheels work with them and of course we wanted hardware manufacturers to be able to support their device on on Mac os10 fairly easily I'm a big proponent on not having to reinvent the wheel when there's something that is acceptable and work unfortunately we had at a partner immersion and they have a large expertise in supporting force feedback in different systems and they knew what worked in other platforms and what didn't work so we were fairly lucky to work with them and leverage their expertise in this field we came up with in the following architecture as you see here at the top we have an application v8 a game or an educational title and of course it is using a hit manager to control the device that is shown at the bottom in this case is it's a steering wheel and over on the right is our force feedback support that we added as I mentioned we have this force feedback framework that the application calls and these are the four sweet what framework calls that we'll see in the next few slides the framework itself then uses this hardware vendor driver in purple which is a TS plugin that abstracts the hardware from the framework itself we defined an API there if which is defining the IO force feedback lib the vendor driver itself then uses mostly said reports and this is why we had to add this advance api's to the head manager to send reports over to the device so that it can do its effect over the bubble on the right is the vendor specific code likes cake stand as we'll see later for hardware developers it's just a method of allowing the force feedback framework to find the driver that is used by a particular device so let's go into the force feedback framework itself and what it is first of all it is fairly similar to the force feedback API that is fine found in other architectures we have three basic types of api's in the framework 11 section is a system-wide ap is and for your convenience we name them to start just with FS for not surprisingly force feedback then we have a device wide api's the bill just with our effects on one device and those start with FF device and finally we have effect yjp eyes that again not surprisingly deal with effect on a single device and those API name starts with FF effect and try saying that three times fast system-wide force feedback api's there are really only those three AP eyes that are on the slide the most important one actually the FF is force feedback API and it as noted on the diagram earlier the application is already using hid device to get input from the from the user and so you can use the axio service object for that device to inquire from the force feedback framework on whether that device actually has force feedback support or not and what the force feedback framework then does as we'll see later is look for the cs plugin for that device and see if it exists and if it's available etc but of course if it's not supported then this will return false and you don't have to provide for speed back then the other two calls are enough you'll see there later everything matches you have a create device and once you're finished with it you have a release device device white API are those that are deal with effects on a single device these are some examples of VIP eyes themselves again we have a creative act and a destroy effect or release effect api and some of the type of other AP is that you encounter are the like the get force feedback capabilities that will allow a game to actually know what the device can do not all devices support all types of effects at all and if you know you're a racing game I you need to know which affects you can support and VAP is also allow you to actually send an effect to a device now in fact why api's allows you to actually send the effect down to the device and then to start stop it modify it and essentially manage that effect on the device these devices are fairly complex themselves and they have memory and you know memory there's just a limited amount until you sometimes have to manage that memory yourself the plug-in will do some of it for you but you have to manage some of that yourself in some cases again some of the examples of this API is you know download the effect unload the effect get the current parameters for that effect that is already in the device so that you know what you need to change and you know you can start and stop it I'd like to say that the devil and in all these api's are these structures and they're quite complex if you're not familiar with the force feedback implementation and however you know you have to set up all these different structures to have the right data so the devil is in the details or in the structures used by the API fortunately these structures are very similar to the structures that are used in other platforms and if you remembered my earlier slide were one of our goals wats to make it easy for porting houses to add for Speed Force feedback to their to the mac OS 10 version of their gang you can understand why this is so we have had ER doc the header files pretty extensively and so you'll be able to grasp some of the details from that and as I understand it the Microsoft developer site has an extensive and quite complete documentation on force feedback this is not to scare you but it's just a sample of what sort of things need to be set up in order to create an effect and when we were working with immersion immersion created a tool to test the force feedback API and now i'm going to give you a little demo of this tool as you can see it's you know almost as complicated as as the slide i just showed but it allows you to test you know well it allowed us allowed us initially to test whether I our API was working then hardware vendors used it to test whether their hard work plug-in was doing the right thing because it's an easy way of setting up all the all the parameters and I can tell you it's all the parameters we are going to make this the binary for this tool available on the developer website in the very near future and then later on actually we're going to release the source code to to this tool I'm just going to go through a quick demo it will be hard maybe for you to see the wheel shaking but but I want to make sure that you know that it is real here on the right are the API is related just like I mentioned in the earlier slide just force feedback the api's device and effect API so first thing that you need to do is create device and this actually is going to go and tell us whether this is a force feedback device on over here on the Left itself that does is this is the logitech mobile force it doesn't tell us that it's the nice leather version of it it's the expensive one so we went and we created a device the next you know I'm just going to make a simple call that use the default values and so we go and we create an effect that is a square effect square wave effect and we go and start it and it looks so we can go and release that effect and maybe change the magnitude here so instead of 3,000 units it's nine thousand units so now it should shake a little harder and we'll go ahead and make it a sine wave and we create the effect again and we started now it takes a little harder and finally we are going to change the duration from three gazillion 29 gazillion and I need to release that effect and create and start and now it'll go ahead and run for a longer period of time so again for application developers this is useful sort of to test the kind of effects that you can use on that the device that you're targeting support and of course for hardware vendors is a way of verifying that their plug-in does everything that they expect it to do so we can go back to the slide now I'm going to go and talk for a little bit about what hardware vendors need to do in order to support their devices in our architecture as I've mentioned earlier the hardware plugin abstract the hardware so the fort feedback framework can use any type of force feedback device second bullet not surprisingly again this is very similar to the force feedback drivers that are supported in other architectures so you if you have experience with those you'll feel right at home and I actually you know in with some of the hardware vendors that I work with when we were developing this their drivers in our support of one of them it has exactly the same code base for both the window platform on our platform and of course that is a big win and he was able to give us his uh his driver in a very short amount of time but compatible and everything it is a CF plugin just like I you hit live by iusb lib like I mentioned on the diagram how we use to inform the force feedback framework that a particular device supports the force feedback is we use this code Lexi X and if you're not familiar with USB matching criteria that is used in our system there's a Q&A 1076 if I'm not mistaken that abstracts what the USB common class specification 1 point 0 says with respect to how USB devices should man interfaces should match and we use this to a Nikolic text just means that it's a text with no binaries it just a peerless and we use this Phyllis to merge a dictionary into a UN USB interface node of the device and the force feedback framework later will find this node and no and what this dictionary has is a uuid pass key value pair that tells a force feedback framework where the plug-in for this is for these devices and what the uuid it is so that you can go ahead and open it this is a project builder sample of the seal is for a code like text and actually it is a sample project the whiz-bang force feedback device that we have as you can see highlighted we have a dictionary the iocs plug-in types dictionary and again this is a standard i okayed name for this dictionary and it has a uuid and a pass to the plug-in and in this case it lives a sample for feedback docx notice that it starts as at the text level so you don't have to put system library extensions it assumes that it that it is there and so it needs to be there again the matching criteria over here is the matching criteria criteria for on Io USB interface device you should also note that our class for this driver is the system supplied IO USB HID driver condotta padre pio USB HID driver and because we added support for said report and get report in ten point two point three you have to depend on version 1.9 point four of the hit driver and on version 1.2 point one of the hit manager just so finally the last item there is the OS bundle required and it says that it is safe boot and you have to do this because our system supply hit driver is safe food as well and if you didn't do it then you wouldn't participate in the matching for your device and it won't work finally the hardware plugging it as I mentioned earlier in the vio force-feedback lived or H defines the interface for the plug-in it is CF plugging architecture so it's a calm interface very similar to other platforms you need to generate your own uuid for your plugin universally unique unique identifier do not use the uuid that is in the sample project in fact it won't compile without having to remove a comment from the uuid that I provide there so as you know that you have to go and generate your own if not it's not unique and another vendor that uses it you'll cut a clash with it and things won't work the system provides a tool to generate a uuid and so all you need to do is your ID gin and there you go it has it the as I mention so the interface file itself is pretty well header ducked up the Microsoft developer site has again some good information on force feedback and we will be making available a sample force feedback plugin project that you know there's a lot of overhead involved in creating a TF plugging and you know it doesn't change between implementations so this is just a skeleton project that provides the required methods and you just have to go and do the hard part and fill in the blanks to actually use your device so I hope that you've gotten an understanding of what force feedback devices are and why you would use them in our system how we actually implemented for feedback in Mac OS 10 and if you are an application developer or a hardware of developer you know how to start using force feedback again I would like to thank immersion for their partnerships in in developing the force feedback framework we did it in i believe record time it was like three months or four months from when we started when we decided to support for feedback and when we actually delivered it and we missed on up earlier update just like that much so just for the DVD benefit those are some sessions that would be useful for for you if you are learning about force feedback and with that there's the emails of the usual suspects