x64 driver.
x86 driver.
Try it.
Win 7 Sensor Driver
Moderator: Moderators
Windows 7 Sensors API (http://msdn.microsoft.com/en-us/library ... S.85).aspx) is a new interface in Windows 7 that allows an application to use an abtract COM Api to communicate with devices.
It is basically an improved version of the raw input, COM based, designed to provide variant-definitions of the types that the device supports. There are a list of categories that might be used as sensors, including GPS, Environmental, Light, Orientation, Temperature and other stuff (http://msdn.microsoft.com/en-us/library ... S.85).aspx).
This means that with the same API, developers can access a variety of devices without device-specific code or complex raw input handling.
Okay, enough theory. What is the current stage of developement for sensors? Are there Sensor-Enabled applications yet ? Are there devices that provide Windows 7 Sensor drivers yet?
The answer is "not yet". There are 5 drivers I am aware of:
a) The sample Virtual Light driver that comes with Windows 7 SDK and simulates light conditions.
b) The U-blox GPS Driver
c) The sample complex driver that MS gave to Sensor API beta testers
along with hardware
d) My GPS NMEA driver that maps any NMEA compatible gps as a sensor.
and of course e) the driver I just created for the 3D mouse.
Can an application benefit from those drivers? The answer is still "not yet". As you might have guessed, I am always investing to new technologies (and particularly Windows 7 which has stuff like Direct2D and UI enhancements which we are now experimenting with at the Athens Uni) and I don't expect the stuff I am working at to be applied rapidly to the users and the market.
However, as Windows 7 will become more popular, the abstraction it provides with that API will surely encourage hardware developers to provide a Sensor driver with their devices.
So, if you are asking me who is going to use what I make, I can only tell you that it will be a part of my 3d navigation in the Virtual Reverb I 'm making. But perhaps after a year or two, you will have more Sensor API customers.
Best Regards,
Michael
It is basically an improved version of the raw input, COM based, designed to provide variant-definitions of the types that the device supports. There are a list of categories that might be used as sensors, including GPS, Environmental, Light, Orientation, Temperature and other stuff (http://msdn.microsoft.com/en-us/library ... S.85).aspx).
This means that with the same API, developers can access a variety of devices without device-specific code or complex raw input handling.
Okay, enough theory. What is the current stage of developement for sensors? Are there Sensor-Enabled applications yet ? Are there devices that provide Windows 7 Sensor drivers yet?
The answer is "not yet". There are 5 drivers I am aware of:
a) The sample Virtual Light driver that comes with Windows 7 SDK and simulates light conditions.
b) The U-blox GPS Driver
c) The sample complex driver that MS gave to Sensor API beta testers
along with hardware
d) My GPS NMEA driver that maps any NMEA compatible gps as a sensor.
and of course e) the driver I just created for the 3D mouse.
Can an application benefit from those drivers? The answer is still "not yet". As you might have guessed, I am always investing to new technologies (and particularly Windows 7 which has stuff like Direct2D and UI enhancements which we are now experimenting with at the Athens Uni) and I don't expect the stuff I am working at to be applied rapidly to the users and the market.
However, as Windows 7 will become more popular, the abstraction it provides with that API will surely encourage hardware developers to provide a Sensor driver with their devices.
So, if you are asking me who is going to use what I make, I can only tell you that it will be a part of my 3d navigation in the Virtual Reverb I 'm making. But perhaps after a year or two, you will have more Sensor API customers.
Best Regards,
Michael
The sensor driver is not something specific for audio applications. It is an abstraction for any type of application if it is sensor aware.
That means that the developers of a 3D application can take the 3D mouse data from the sensor API instead of the COM interface you provide which does the job all right, but only for 3d mouse devices, where the sensor api will work will all devices that support it in the same way.
Do you want me to create a sample C++ application that can use the 3d mouse with either the com interface or the sensor api ?
That means that the developers of a 3D application can take the 3D mouse data from the sensor API instead of the COM interface you provide which does the job all right, but only for 3d mouse devices, where the sensor api will work will all devices that support it in the same way.
Do you want me to create a sample C++ application that can use the 3d mouse with either the com interface or the sensor api ?
http://www.turboirc.com/temp/3dtest.rar
This is a small application that draws a cube on its screen and moves and rotates it depending on the 3D mouse movements. It uses either the 3DC api or the Sensor API.
Helpers are 3d.h (for 3d projection stuff), and func.h contains miscellaneous stuff. Z.h / mz.h are allocator classes.
3dcx.cpp/3dcx.h is a class that simplifes the 3D Connexion api in a small class that I use in my apps to get notifications from the 3DC api. As you will see, this code is familiar. It uses plain raw COM, not even ATL.
The main sensor stuff is in test.cpp. If my sensor driver is available, then test will use it, otherwise it will use the 3D Connexion driver. Aa you can see, a user has to implement the ISensorEvents to get sensor notifications and then, in the notification handler (in my case WM_USER + 50), to use the ISensorDataReport to get the values, for which the CLSIDs are defined by my driver.
The sensor API is certainly not easier than what you have offered, but your COM implementation can only be used by 3D Connexion devices while the Sensor API can be used with any device that supports it.
This is a small application that draws a cube on its screen and moves and rotates it depending on the 3D mouse movements. It uses either the 3DC api or the Sensor API.
Helpers are 3d.h (for 3d projection stuff), and func.h contains miscellaneous stuff. Z.h / mz.h are allocator classes.
3dcx.cpp/3dcx.h is a class that simplifes the 3D Connexion api in a small class that I use in my apps to get notifications from the 3DC api. As you will see, this code is familiar. It uses plain raw COM, not even ATL.
The main sensor stuff is in test.cpp. If my sensor driver is available, then test will use it, otherwise it will use the 3D Connexion driver. Aa you can see, a user has to implement the ISensorEvents to get sensor notifications and then, in the notification handler (in my case WM_USER + 50), to use the ISensorDataReport to get the values, for which the CLSIDs are defined by my driver.
The sensor API is certainly not easier than what you have offered, but your COM implementation can only be used by 3D Connexion devices while the Sensor API can be used with any device that supports it.