Space Navigator PE Driver Development Thread

[inh]

Cool

Yea i guess for other front ends it would be helpful to have the front end tell the driver what part of the skin it was on.. But i mean really, who uses other frontends?

Cant wait for this to be released glovepie was great to play with the sapce nav in RR but a native driver will be 1000x better

[turbocad6]

I think being able fine tune it is a good option for sure & I think gestures are a great idea, for example all the way up followed by an all the way down can trigger a predefined action I guess, but since this thing is so sensitive & doesn't have a very solid center return, what are the chances of performing gestures accidentally? I think it might be good if gestures required a full travel one direction then another, so it would be very unlikely for a false gesture...

also, it would be cool if gestures could be used with more than just 2 successive inputs, like for a control-alt-delete, could require an up/down/up/down for example...

I could see this getting pretty complicated to use if many gestures are implemented, but that just means more control for those who want it, & for those who want to keep it more simple, then gestures can be limited...

I'm not sure I understand how this can be function changed depending on the screen it's in, but if that can be done in RR it would be awesome... I guess this is one of the advantages of writing your own program?


I have used the shuttle express which reminds me of this thing... one way it does progressive travel is through key presses, but the further through the axis the control is, the faster it repeats the key press, so a slight twist would press for a volume up say once every half second, & the further through the travel the faster they would repeat.... everything was set with a program that gave a nice user interface & had the ability to save different profiles... it could do different actions depending on the program it was used in, but nothing like changing functions depending on the screen.... I'm guessing this is going to be a matter of doing this only in roadrunner?


wish I knew a bit about programming to be of more help... I am ordering one of these now finally

[liquid_smoke]

Per your PM request.

I think if possible, you should try to strickly follow the standard ini format of Section, Key, Value
[SECTION]
key=value
There a few reason why i say this, one it being easier to read/edit and also more importantly easier for an external application to read and edit.
I can whip up an autoit script that would read and set all the values and also intergrate this into RR with nice graphics to visualy see what you are editing.
Others can do the same for there frontend also, or even make a stand alone app to do the same.
It looks like your using xml now, but in either case i dont think you should create a format but yet use an existing format.

Where the section would be the name of the context

[CONTEXT GLOBAL]

and the keys names specifly what you are editing

AXIS_PAN_X=binary, 0.1
ACTIONS_CONTEXT_SWITCH_UP=BUTTON_R

note i reversed the way it original was so the value is always on the right of the = sign
and also removed the [AXIS] section and put it as a prefix to the key
This way there aren't any duplicate section names that will confuse any .ini editor or external app that tries to read the file as to where to read/write data.
So everything that is under a specific context applies to that context until it reaches another context.

I see the CONTEXT_SWITCH action but im unsure of how this exactly would work.
Do i state what context i want to switch too?
like
CONTEXT_SWITCH=GPS
if so where would i state the gesture or button that activates this switch?

I have a few ideas on how the context switching should be done.

1. Manual switch where the context_switch would be tied to a specific button or gesture and overrides any other setting for that button or gesture.
When activated it would cycle to the next CONTEXT in the configfile, top to bottom in the order they are listed.
This could get click happy though and require multiple button presses to get to the context you want.

2. Another way would be for the app to look for window titles to determine what context it should be in.
I belive this is the best method but would require more work than the first.
So if i wanted to have my GPS context to only work if my gps application is in "focus" and not just found. It may look like this

[CONTEXT_GPS]iguidance
where "iguidance" is the apps window title


3. Another way would be for the app to accept command line switches that would switch the context.
So if im using my favorite frontend , Road Runner, i could have it send a command to the driver app to switch to the GPS context when i enter the gps screen and another command to switch back when i leave.
"RUN;driverapp.exe|CONTEXT_SWITCH GPS"
This would require a little bit of work for skinners, but i personally dont mind, others may balk at the extra work.



Im a little confused about what BINARY and PULSE modes are, and the difference between them.
I think, binary is a simple send key or action that happens once where pulse is kind of like a repeat mode? So If i have the letter K tied to a action with pulse it would send the letter K over and over until i stop the action?


in any case, whatever you decide to go with, the end result is the only thing that really matters.
Looking at the file, it seems the end result is what I would like, so if i had to sit and edit the config file in its current state i wouldn't mind at all.
Its not confuseing to me or anything, i just know i wouldn't be able to write a frontend to the configfile.
But in practice, once you get everything setup the way you like, you rarely if ever will touch the file again.
My biggest question that im still a little wondering about would be exactly how the context switching happens.

Ill post more if i come up with any ideas or questions.

[sama]

First of all, thank you all for your valuable input. It's much appreciated.

Quote: Originally Posted by turbocad6

since this thing is so sensitive & doesn't have a very solid center return, what are the chances of performing gestures accidentally? I think it might be good if gestures required a full travel one direction then another, so it would be very unlikely for a false gesture...

Yep, the threshold value is the amount to ignore before that axis kicks in. So the higher you set that value, the more you'll have to push/pull that axis to perform that action

Quote: Originally Posted by turbocad6

also, it would be cool if gestures could be used with more than just 2 successive inputs, like for a control-alt-delete, could require an up/down/up/down for example...

I could see this getting pretty complicated to use if many gestures are implemented, but that just means more control for those who want it, & for those who want to keep it more simple, then gestures can be limited...

They can be. You'd define it something like:

GESTURE: TWIST+ | 100 | TWIST- | 100 | VERTICAL+ | 100 | VERTICAL- | 100 | ...

Which is a bit like a mortal combat special move... but there you go

Quote: Originally Posted by turbocad6

I'm not sure I understand how this can be function changed depending on the screen it's in, but if that can be done in RR it would be awesome... I guess this is one of the advantages of writing your own program?

Tha's the idea, yep. The mechanisms to do this are something that I'm hoping to figure out in these discussions.

Quote: Originally Posted by turbocad6

I have used the shuttle express which reminds me of this thing... one way it does progressive travel is through key presses, but the further through the axis the control is, the faster it repeats the key press, so a slight twist would press for a volume up say once every half second, & the further through the travel the faster they would repeat.... everything was set with a program that gave a nice user interface & had the ability to save different profiles... it could do different actions depending on the program it was used in, but nothing like changing functions depending on the screen.... I'm guessing this is going to be a matter of doing this only in roadrunner?

To begin with, I would imagine so, but having read what liquid_smoke has said below about doing it based on active window, this may not be the case.

Quote: Originally Posted by turbocad6

wish I knew a bit about programming to be of more help... I am ordering one of these now finally

at last

Quote: Originally Posted by liquid_smoke

I think if possible, you should try to strickly follow the standard ini format of Section, Key, Value
[SECTION]
key=value
There a few reason why i say this, one it being easier to read/edit and also more importantly easier for an external application to read and edit.
I can whip up an autoit script that would read and set all the values and also intergrate this into RR with nice graphics to visualy see what you are editing.
Others can do the same for there frontend also, or even make a stand alone app to do the same.
It looks like your using xml now, but in either case i dont think you should create a format but yet use an existing format.

Where the section would be the name of the context

[CONTEXT GLOBAL]

and the keys names specifly what you are editing

AXIS_PAN_X=binary, 0.1
ACTIONS_CONTEXT_SWITCH_UP=BUTTON_R

note i reversed the way it original was so the value is always on the right of the = sign
and also removed the [AXIS] section and put it as a prefix to the key
This way there aren't any duplicate section names that will confuse any .ini editor or external app that tries to read the file as to where to read/write data.
So everything that is under a specific context applies to that context until it reaches another context.

Good call. I did try a hybrid ini/xml format, so that I could gain structure and readability. I find that ini files are nicer to read than xml, but xml provides structure. You're right though about other programs using it, and that outweights the value of the structure element. Using prefixes for organsation as you've mentioned is the way to go.

Quote: Originally Posted by liquid_smoke

I see the CONTEXT_SWITCH action but im unsure of how this exactly would work.
Do i state what context i want to switch too?
like
CONTEXT_SWITCH=GPS
if so where would i state the gesture or button that activates this switch?

The idea I had there was that using a button would cycle through the gestures top to bottom. but then I wasn't sure how the user would keep track of the context they're currently in. I then thought that a mechanism is required to inform the user, like perhaps an overlay bit of text.

Quote: Originally Posted by liquid_smoke

I have a few ideas on how the context switching should be done.

1. Manual switch where the context_switch would be tied to a specific button or gesture and overrides any other setting for that button or gesture.
When activated it would cycle to the next CONTEXT in the configfile, top to bottom in the order they are listed.
This could get click happy though and require multiple button presses to get to the context you want.

exactly, especially when done blind. unless notification is there also, then I would say this is a no-go.

Quote: Originally Posted by liquid_smoke

2. Another way would be for the app to look for window titles to determine what context it should be in.
I belive this is the best method but would require more work than the first.
So if i wanted to have my GPS context to only work if my gps application is in "focus" and not just found. It may look like this

[CONTEXT_GPS]iguidance
where "iguidance" is the apps window title

Interesting approch and I like it. However what of contexts that do not have an app window title? I mean, skins within RR say that do not embed an app? Does RR change it's title based on the skin page it's on?

Quote: Originally Posted by liquid_smoke

3. Another way would be for the app to accept command line switches that would switch the context.
So if im using my favorite frontend , Road Runner, i could have it send a command to the driver app to switch to the GPS context when i enter the gps screen and another command to switch back when i leave.
"RUN;driverapp.exe|CONTEXT_SWITCH GPS"
This would require a little bit of work for skinners, but i personally dont mind, others may balk at the extra work.

This is the approach I had in mind. Also, inh mentioned above that RR uses keyTBL and execTBL to allow context switching. So for RR, it looks like just pumping out some key presses from the driver may allow this to integrate with RR

Another way is to write a file somewhere, which tells the current context. This would allow many apps to get that info, but for FE's, this would require additional code.

I guess the ultimate way of making this work, is to request integration from FE writers.

Quote: Originally Posted by liquid_smoke

Im a little confused about what BINARY and PULSE modes are, and the difference between them.
I think, binary is a simple send key or action that happens once where pulse is kind of like a repeat mode? So If i have the letter K tied to a action with pulse it would send the letter K over and over until i stop the action?

exactly, and pulse mode allows you to tweak how often to pulse by providing parameters for a range (start pulse rate and end pulse rate) and how to accelerate through that range (linear or exponential)

Quote: Originally Posted by liquid_smoke

in any case, whatever you decide to go with, the end result is the only thing that really matters.
Looking at the file, it seems the end result is what I would like, so if i had to sit and edit the config file in its current state i wouldn't mind at all.
Its not confuseing to me or anything, i just know i wouldn't be able to write a frontend to the configfile.
But in practice, once you get everything setup the way you like, you rarely if ever will touch the file again.
My biggest question that im still a little wondering about would be exactly how the context switching happens.

agreed. I think starting with one mechanism, then changing as required is the best way to go.

[liquid_smoke]

cool, sounds good to me.

Quote: Originally Posted by sama

The idea I had there was that using a button would cycle through the gestures top to bottom. but then I wasn't sure how the user would keep track of the context they're currently in. I then thought that a mechanism is required to inform the user, like perhaps an overlay bit of text.

The text overlay is an idea, it would have to fade away or go away and not be persistent though. Maybe a gesture that shows you what context you are in?

Quote: Originally Posted by sama

Interesting approch and I like it. However what of contexts that do not have an app window title? I mean, skins within RR say that do not embed an app? Does RR change it's title based on the skin page it's on?

No RR keeps the same window title, but the only time you would need to change the context for RR to something different would be when you have an embedded application running, like GPS or the webbrowser. I really cant think of anything else you would really need to have a different set of commands.
RR is pretty easy to control as far as keyboard goes, LEFT, RIGHT, UP, DOWN and ENTER will navigate the whole app. I dont think in practice you with need to have different context on different standard screens in RR as they all can be controlled with those 5 keys. Only embedded apps would need a different context. If the driver app would accept commands from RR to switch the context everything would be golden on RoadRunner side of things.

Quote: Originally Posted by sama

This is the approach I had in mind. Also, inh mentioned above that RR uses keyTBL and execTBL to allow context switching. So for RR, it looks like just pumping out some key presses from the driver may allow this to integrate with RR

Yup, pretty much thats all thats needed and the ability to run an application with command line options.

Quote: Originally Posted by sama

Another way is to write a file somewhere, which tells the current context. This would allow many apps to get that info, but for FE's, this would require additional code.

I guess the ultimate way of making this work, is to request integration from FE writers.

I think all the top 3 FE's, RR, CF and SD (is there really anything else on the same level) all have some sort of keyboard control for all its functions. So i dont think this would even be necessary.


will there be a mouse mode?

[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]

Quote: Originally Posted by sama

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