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