Space Navigator PE Driver Development Thread

[cherrybomb]

Okay, been making some good progress on the capture part of our driver/utility.

It's still in a VERY early state but you can download it below.

Here's the vital stats thus far.

• It should run on Win2k - Vista (Tested on Win2k Pro, XP Pro, and Vista Ultimate).
• It can control the LED, though right now it just turns it on when running, and off when done.

Right now all this does is simulate a mouse. It uses the tilt axis' for movement, and left and right buttons as (you guessed it) left and right mouse button clicks.

The proper way to exit this is to type something (anything) in the console, and press enter. You must then move the SpaceNavigator, or press a button, or something, since it won't exit until it receives another input report from the device.

More to come, but I wanted to let people know that some progress is being made. ;-)

http://www.nslms.com/downloads/Space...HIDCapture.dll
http://www.nslms.com/downloads/Space...HIDTestJig.exe

[sama]

works a treat cherrybomb.

As for my part, I've been extremely busy this last week. I'm in the middle of moving house and been put on a much busier team at work. I'm still on the case, but won't resume till next week at least.

[cherrybomb]

This project is now available on SourceForge, and you can download the latest version there.

SpaceNav SF Project.

Nothing really new, just some behind the scenes cleanup. It also now exits when you ask it to, rather than waiting for another input report from the device.

Going to try to work on having this actually do something more useful over the weekend.

Sama, it'd be good if I could look at some of the source you've written, as you've probably made more progress on that end of things than I have. If you get an account on SF.net I can add you as a developer on the project.

[cherrybomb]

Had a little time to play with it some more today.

I've now got it sending window messages to RR. It's sending the command twice per second whenever any axis is over 50 in either direction.

Going to try to tweak it this weekend to actually be configurable via the INI file format described earlier.

Probably going to support key presses, exec, and windows messages initially.

[psyrex]

I've been following this thread and you guys' work is so inspiring that I actually went and bought myself a SN. But after browsing 3dconnexion's forum today, I found this: http://www.3dconnexion.com/forum/viewtopic.php?t=336

I thought it was interesting, but wondered if you guys saw it and what you thought of it.

[inh]

damn! looks like very close to what these guys are working on..

[sama]

Cherry, I will do very soon matey. I've not got Cygwin instead of minigw. I'll give that a bash with Eclipse CDT and if it's a no-go, VS it is.


psyrex/inh, it is very similar indeed. In fact, he's created a joystick/keyboard and mouse device driver, that uses the space navigator. So the SN is a keyboard and doesn't emulate it. I like this approach, in it's own right. It allows better compatiblity with apps etc.

He also has context switching of types. it's called a layout, which is pretty much the same thing. I'm sure he can add support to switch the layout pragmatically or from the device.

I cant' see gestures in there, but that can live on top as a third party app.

I think we could integrate with this or carry on as initially planned. I'm still inclined to create a custom CarPC driver as I think the application is a different one. And I'm also still inclided for a custom solution to make multiplatform possible (especially since my FE is also multiplatform). what do you think Cherry? et all?



Right now, I'm packing the kitchen into boxes, and I'd say 60% of my life is in labelled cartons. I'm going to be homeless for 2 months! Please bear with me in these ****ty times whilst at least I get to a stage where I'm stable enough to get working again.

[cherrybomb]

psyrex/inh, it is very similar indeed. In fact, he's created a joystick/keyboard and mouse device driver, that uses the space navigator. So the SN is a keyboard and doesn't emulate it. I like this approach, in it's own right. It allows better compatiblity with apps etc.

He also has context switching of types. it's called a layout, which is pretty much the same thing. I'm sure he can add support to switch the layout pragmatically or from the device.

I cant' see gestures in there, but that can live on top as a third party app.

I think we could integrate with this or carry on as initially planned. I'm still inclined to create a custom CarPC driver as I think the application is a different one. And I'm also still inclided for a custom solution to make multiplatform possible (especially since my FE is also multiplatform). what do you think Cherry? et all?

You're absolutely right, he basically wrote a kernel driver that, instead of taking the input from the SN, and converting it to something else (like we intend to do in user space) he just fooled the kernel into think that the SN actually WAS some other device in kernel space.

This is a smart implementation for his uses, but it's limited. This basically only turns the SN into some other device, who's input must still be translated into something useful. For instance, going this route, would prevent us from (easily) running commands, like exec.exe for RR, or from sending window messages etc.

I think we're best off continuing down the road we're on, and making a user space tool.

Perhaps we should just call it a tool, or translator or something, instead of a driver, for clarity.

[cherrybomb]

I'd like to propose the use of XML for the config file.

We can use Xerces XML parser to read/write the file, and that's cross platform. Plus it should allow A LOT more configuration abilities, and I'm awfully familiar with it.

If people feel uncomfortable configuring it, I'll gladly write a config tool.

Also, I'd strongly suggest having some way of enabling and disabling the gesture recognition. For instance, I'd like to, say, press and hold the left button for two seconds, which would blink the LED's twice, possibly play a sound, and switch into "gesture" mode. Then you perform your gesture, and it either recognizes it and executes it, or not. Either way, it leaves gesture mode so you can't accidentally trigger one again unless you explicitly enter "gesture" mode.

Thoughts?

[inh]

I think you shoudl make it so you have to press and hold the left button while doing the gesture, to keep accidental gestures from happening. it makes it a bit more awkward but i dont think its too bad..

x2 on the XML config file, as well