KB_Keystroke in <AXIS> def causes cap to stop working

[quantum69]

specs:
Spacepilot Pro. Windows 7 x64 pro, I7-5960X cpu, 32GB mem, 24TB harddrive space, 2x 980's, Gigabyte mainboard, Logitech G19s & G13, partridge in a pear tree.

This works as expected.

Code: Select all

			<Axis>
				<Enabled>true</Enabled>
				<Input>
					<ActionID>HIDMultiAxis_Rx</ActionID>
					<Min>-512</Min>
					<Max>511</Max>
				</Input>
				<Output>
					<ActionID>HIDMouse_Wheel</ActionID>
					<Scale>1.00</Scale>
					<Reversed>true</Reversed>
				</Output>
			</Axis>

This causes the cap to not work (fully explained below)

Code: Select all

      <Axis>
        <Enabled>true</Enabled>
        <Input>
          <ActionID>HIDMultiAxis_X</ActionID>
          <Min>0</Min>
          <Max>511</Max>
          <Deadband>200</Deadband>
        </Input>
        <Output>
          <ActionID>KB_Keystroke</ActionID>
          <RepeatStyle>PressAndHold</RepeatStyle>
          <Keystroke>
            <Key>8</Key>
          </Keystroke>
        </Output>
      </Axis>

As soon as I add an <Output> that uses KB_Keystroke on an axis, that side of the axis no longer works. It does not generate any keystrokes. I have created a default notepad.xml file and tried this numerous times. This did not work in 10.1 and still doesn't in the recent 10.2 software. The above change causes that side of the cap to stop working. If I change the range to the other side then that side stops working and the other side still operates as the HIDMouse_Wheel.

I have uninstalled/reinstalled, enabled/disabled, checked Device Manager, Devices and Printers, LGS off/on (yes, it doesn't like the LCDM that comes with the SPP). All the combinations I can think of to no avail.

BTW: the [HID\3DXKMJ_HIDMINI&Col01] hardware id in Device Manager was under the [Human Interfaces Devices] branch in 10.1 and after completely reinstalling with the 10.2 it is now under the [HID-compliant mouse] branch.

The SPP works under all the products I run so it's not a hardware malfunction. The cap stops working as soon as I try to set an axis <Output> to <ActionID>KB_Keystroke</ActionID>.
If I delete my notepad.xml and let the 3Dx properties generate a new one, the X-axis works as it shows, it emulates the mouse wheel scrolling. If I assign a KB_Keystroke to either side of the X-axis range then that side stops working while the other side continues to emulate the mouse wheel. If I change the range then that side stops working while the other range functions as the mouse wheel scroll.

Also, in the Devices and Printers, there is an [unspecified] device shown as 3DX_KMJ_01 that has nothing under the HARDWARE tab. It goes away when uninstalling and comes right back with each reinstall. No yellow flag so it's not considered a failed driver install, it's just there. Just a curiosity.

Following the various suggestions given on this board by the mods/admins, I have tried the enable/disable with the [HID\3DXKMJ_HIDMINI&Col01] device entry, but that only removes the SPP from the Game Controllers listing. It has no impact on this issue that I've seen.

With just the G19s keyboard and SPP plugged in it still breaks the cap functionality once I try to use the KB_Keystroke on an axis assignment. I have tried it under the <Name>Standard 3D Mouse</Name> devices section as well as changing that section to <Name>SpacePilot PRO</Name> and it doesn't make a difference. The examples given on this board using axis generated keystrokes always seem to have all the definitions in a <Name>SpacePilot PRO</Name> (device name specific) section as opposed to the generic Standard 3D Mouse section.

I use win_tail to observe the 3DxService.log file. Before adding a KB_Keystroke output, the log shows that the cap generates pressure events on the X-axis as expected. After adding a KB_Keystroke to the X-axis that side generates no events and the opposite side continues to work as expected. I have tried applying KB_Keystroke outputs to the other axis but they stop working as well. I know the software is working because any change made to my test notepad.exe file is reflected in the service log events as well as the behavior of the cap. This narrows it down to KB_Keystroke as an output on an axis. All the buttons still function regardless of axis changes.

From the various threads on this board I've found this information to be quite helpful: (excerpts from mods/admins passing on info to others)

Code: Select all

TRANSPORT_PROTOCOL is a hint to the driver of how an application is planning on communicating with the driver.

NO_TRANSPORT	means nothing in particular is specified. Either MWM or S80 will be handled.
MWM_TRANSPORT	indicates that the application will use an old Windows messaging protocol
		that is only used by a few applications.
S80_TRANSPORT	indicates that the application is using the 3Dx C/C++ SDK mechanism.
PXY_TRANSPORT	indicates that the application uses a Proxy DLL
		(UdPxy directory DLL -- a callback mechanism used by 3DxOffice).

WIN32_KEYBOARD 	is the only one that absolutely needs to be specified.
		It indicates that this application is only supported by throwing 
		keyboard macros at it. All the other protocols will register with
		the driver to indicate that they are interested in receiving events.
		WIN32_KEYBOARD applications are "write only". They never contact the
		driver. It is up to the driver to notice that they are in focus and
		start sending keyboard events to them.

Joystick (and Keyboard and Mouse) emulation is for applications that don't support the 3D mouse properly. Some of those applications, especially flight sims, support the joystick. In those cases, we can throw joystick events at them. It works very well. See some of the videos on youtube.

The current list of Transports is:
KMJ		(Keyboard, Mouse, Joystick emulation)
HID		(HID API from Microsoft)
RawInput	(Microsoft Raw Input API)
DirectInput	(the Microsoft DirectInput API)
S80		(current 3DxWare SDK API)
MWM		(ancient 3Dconnexion API)

Since the default files, in particular the KeyboardWASDTemplate.xml, don't work when I migrate them to my user config then I know it's a syntax issue.
Yes, I :::
changed the AppCfgTemplate to AppCfg
changed default to false
changed executablename to notepad.exe
made sure the transport was KMJ
faced the full moon and swore like a sailor

Everything works except KB_Keystroke.

If the suggestion is that I take this back to the store before my 30 days is up I'm open to that as well. I've tried all I can think of that made sense and even a few things that were entirely irrelevant. Reinstalling with it plugged-in/not plugged-in, removing LGS and only using LCDM, copying and pasting from the default files, trying all the different transport options, watching the service log entries scroll by (it's a lot better than paint drying or grass growing but still as pointless).

I looked (grep'd) all the <ActionID> entries in the default files to see if there was another kind of KB_* , there are, but they are references to earlier defs in those files and don't seem to be a *command* type like KB_Keystroke, HIDJoystick, etc.

It's a neat gadget that works well with the "supported" software I use. There are other products that it *could* be useful for if I can find out how to make it behave.

I do design work and animation/presentation so there are other packages that I'd like to use it in rather than having it be a very esthetic paperweight while I'm using those.

Here's hoping for a simple and expedient solution. I can't believe I'm the only one having this particular problem or haven't found the answer somewhere hidden in all these threads somewhere. I searched for KB_Keystroke and read the ones that addressed it's usage, I've copied verbatim those entries, the cap stops working as soon as I save the file.

Thanks. Happy Holidays

[quantum69]

Ok, apparently the reinstalls changed where the 3DxService.log was being written to.

This axis definition:

Code: Select all

      <Axis>
        <Enabled>true</Enabled>
        <Input>
          <ActionID>HIDMultiAxis_Rx</ActionID>
          <Min>-512</Min>
          <Max>511</Max>
        </Input>
        <Output>
          <ActionID>KB_Keystroke</ActionID>
          <Keystroke>
            <Key>8</Key>
          </Keystroke>
		</Output>
	  </Axis>

generates these in the 3DxService.log

Code: Select all

00000020 7:54:55.938: KMJTrans: Single key: originated from=HIDMultiAxis_Rx, keyCode=0x0, modifiers=0, pressLevel=0.500489, pressReleaseType=3
00000080 7:54:55.938: SendKeyRelease: releasing usageID 0
00000020 7:54:55.970: KMJTrans: Single key: originated from=HIDMultiAxis_Rx, keyCode=0x0, modifiers=0, pressLevel=0.509286, pressReleaseType=3
00000080 7:54:55.970: SendKeyPress: pressing usageID 0
00000020 7:54:55.985: KMJTrans: Single key: originated from=HIDMultiAxis_Rx, keyCode=0x0, modifiers=0, pressLevel=0.516129, pressReleaseType=3
00000080 7:54:55.985: SendKeyRelease: releasing usageID 0
00000020 7:54:56.016: KMJTrans: Single key: originated from=HIDMultiAxis_Rx, keyCode=0x0, modifiers=0, pressLevel=0.503421, pressReleaseType=3
00000080 7:54:56.016: SendKeyPress: pressing usageID 0

So after all this it apparently is now generating or at least recognizing the cap pressure event. The problem seems to be that "keyCode=0x0" entry. 0x0 is NULL in my realm so it's set as <Key>8</Key> which would be...
let's walk the string
A = 4
B = 5
C = 6
D = 7
E = 8

so, <Key>8</Key> should generate an ascii E, all things being equal, which seldom are. Why A = key 4 we'll never know. What you guys did to 0-3 is probably best left unsaid. Is "keyCode=0x0" you're value or is it supposed to be an ascii value?

[quantum69]

You tell me, it just started working. Apparently copying and pasting from the default files is something it didn't like. It also didn't like the copy/paste from these threads. No idea. Also, and no idea why, but saving as ANSI and not UTF-8 seemed to give reliable results during testing.

Ok, got it working. Couple things that came up. 1) if you change an axis in any way, realize you changed the wrong axis, change the axis reference to the correct one (i.e. HIDMultiAxis_X then correct it HIDMultiAxis_Rx), it seems the 3Dx driver caches the HIDMultiAxis_X if you save the file. Even after changing it back to Rx the X axis then had it mapped. A start/stop of the driver fixes it but so does just adding the correct _X axis entries and saving the file.

Someone in another thread suggested that having the <Min><Max> pairs for each entry far enough apart would negate the need of using the <Deadband></Deadband>, I've found out that doesn't work. Here's why.

While working on the file I noticed it would fail to open the 3Dx properties dialog if I didn't have

Code: Select all

  <CfgProperties>
    <InheritsFrom>STR_DEFAULT_KMJ</InheritsFrom>
  </CfgProperties>

as an entry after the </AppInfo> when I had only 1 axis definition. Guess the 3Dx software likes to know all of those axes are defined in the file. The default xml the 3Dx properties page will generate automatically puts that in there if you just check/uncheck a single axis on the Advanced Settings page. So by default it inherits the other axes and generates the default _Rx entry of HIDMouse_Wheel. Remove that inheritance line and 3Dx will complain about a config not being defined correctly. Ah well, it's a learning experience all the way around. So if you're writing a file and the 3Dx Properties won't start and complains about <Cfg... something or other not being set, this inheritance line fixes that by making sure whatever you're missing is replaced/read from the default definitions file. Most of the examples I've seen on this board had omitted this entry. Perhaps because they didn't post the entirety of their xml file, which could leave others starting down this path of exploration wondering why when they define a single axis (well, anything less than all 6 I've found) the 3Dx Properties validation will cause the file load to fail. Can't the 3Dx software just *guess*

Ok, so that leads to why the <Deadband> doesn't seem to work properly while editing/saving and not cycling the 3Dx driver. If you have <Min>-512</Min> <Max>-100</Max> for one side of the axis and <Min>100</Min> <Max>511</Max> on the other side, you might be thinking that -100 to 100 range isn't going to react. Well, looking at the tail of the 3DxService.log the cap is still generating pressure events (which it should) and any defaults that occupy that range (such as the HIDMouse_Wheel by default) will be active in that range until it exceeds the <Min> of either side. I just created a *middle* range (as shown in my code below) to capture that output so it's well defined and leaves no gaps. The <Deadband> didn't seem to work, at least not for me, so covering the entire range this way prevented stray output noise during testing.

Here's the Rx axis code

Code: Select all

      
<!-- roll cap forward -->
<Axis>
        <Enabled>true</Enabled>
        <Input>
          <ActionID>HIDMultiAxis_Rx</ActionID>
          <Min>-512</Min>
          <Max>-200</Max>
        </Input>
        <Output>
          <ActionID>KB_Keystroke</ActionID>
		   <Deadband>200</Deadband>
			<KeyStroke>
				<Key>4F</Key>
			</KeyStroke>
        </Output>
      </Axis>
<!-- do nothing interesting in the middle -->
<!-- this makes sure to capture any stray default noise while testing -->
      <Axis>
        <Enabled>true</Enabled>
        <Input>
          <ActionID>HIDMultiAxis_Rx</ActionID>
          <Min>-200</Min>
          <Max>200</Max>
        </Input>
        <Output>
          <ActionID>HIDMultiAxis_Rx</ActionID>
        </Output>
      </Axis>
<!-- roll cap backwards -->
      <Axis>
        <Enabled>true</Enabled>
        <Input>
          <ActionID>HIDMultiAxis_Rx</ActionID>
          <Min>200</Min>
          <Max>511</Max>
        </Input>
        <Output>
          <ActionID>KB_Keystroke</ActionID>
		   <Deadband>200</Deadband>
			<KeyStroke>
				<Key>50</Key>
			</KeyStroke>
        </Output>
      </Axis>

So yes, I it's working. Annoying to have to fight with it so much but it forced learning a lot about the device. Not a bad thing overall, just annoying as hell during the fight.

Hope this information might help others during their first foray into the wonderful world of adapting the 3Dx device into their own convoluted software collection begins. Plus, lots of search hits for KB_Keyboard should they be looking for it.

Thanks gang. Happy Holidays.

Quantum
Be good or be good at it, failing that, run faster!

[jwick]

Yikes! You had nothing better to do on a Sunday? You get an A for persistence. Sorry about all that.

The <Key>'s are HID Usage IDs, not ASCII. They are basically the kb scan codes. Microsoft has a table you can look at, or even better, just record a macro for a 3Dx device button and copy the code it writes over to your axis.

The Deadband subtracts the input value from the axis. It's meant to silence drifting devices, especially in shaky environments.
So, a half-axis that would have had a range of [0,350] would now have a range [0,250] and it would start moving after move pressure is applied. This filter is done first. What it does at each of those new values is defined by the other entries. In your case, you still left [0,100] open to the default usage.

The half-axis emulation hasn't been tested since support for it was removed from the GUI. It may be broken or get broken.

When working with KB emulation (or any manual Cfg editing) baretail (better than wintail) on the log file is your best friend. In particular, as you noticed, values are inherited from various places. I list where everything comes from in the log file.

[quantum69]

Thank you for responding and for the explanations. I decided since it was Sunday to try my hand at making it work. Took a few hours of beating on it and lots of coffee but got it to behave.

I found a nice win kb scan codes doc that gives the dec/hex for the keys that I can use to validate what I'm seeing in the log and the response from the KMJ transport. All is well in the world.

I cleaned up my entry, noticed I had a couple of residuals in my original post that might be confusing and comments about the directions were flat out wrong. Since I'm covering the entire +/- range with definitions I removed the <Deadband> entries. At this point it works without issues. The log shows the transitions are nice and smooth as are the responses. Neat gadget.

Code: Select all

<!-- capture the twist left- event -->
      <Axis>
        <Enabled>true</Enabled>
        <Input>
          <ActionID>HIDMultiAxis_Rz</ActionID>
          <Min>-512</Min>
          <Max>-50</Max>
        </Input>
        <Output>
          <ActionID>KB_Keystroke</ActionID>
			<MaxEventRate>60.00</MaxEventRate>
			<KeyStroke>
				<Key>50</Key>
			</KeyStroke>
        </Output>
      </Axis>
<!-- do nothing between -50 and +50 -->
      <Axis>
        <Enabled>true</Enabled>
        <Input>
          <ActionID>HIDMultiAxis_Rz</ActionID>
          <Min>-50</Min>
          <Max>50</Max>
        </Input>
        <Output>
          <ActionID>HIDMultiAxis_Rz</ActionID>
        </Output>
      </Axis>
<!-- capture the twist right+ event -->
      <Axis>
        <Enabled>true</Enabled>
        <Input>
          <ActionID>HIDMultiAxis_Rz</ActionID>
          <Min>50</Min>
          <Max>511</Max>
        </Input>
        <Output>
          <ActionID>KB_Keystroke</ActionID>
			<MaxEventRate>60.00</MaxEventRate>
			<KeyStroke>
				<Key>4F</Key>
			</KeyStroke>
        </Output>
      </Axis>

Anyone wanting the KB scan codes doc, it's http://download.microsoft.com/download/ ... ancode.doc
Near the bottom of the doc there's a table, Page 28, section Appendix C: USB Keyboard/Keypad Page (0x07). Those dec/hex values are the point of interest. 0x04 = A, hazzah!
Yes, 0x4F = right arrow, 0x50 = left arrow and 0xFF = paints chickens and balances your checkbook. (ok, maybe not, but you'll never use 0xFF anyway)

I think I'll stick with specifically defining any partial/unused regions as I've done here. I like the results. If I ever want to divide the bands further I know right where my *middle* is.

Now for something completely different yet related:

For anyone using the G19s and/or G13 keypad; If you run the LGS so you have programmable keys you must exit/quit/stop the LCD manager that comes with the 3Dx software. This will mean the 3Dx screen is blank as soon as you turn LCDM off. What you can do (and what I do) is to copy the applet from the 3Dx directory to the LGS directory and add it to the G19s screen. This way I have the Function Keys 3Dx applet running right in front of me on the G19s and don't have to look left at the 3Dx screen. It allows fully programming/using the G19s and G13 keypad profiles and the 3Dx is still completely functional. I have doubts Logitech will ever have their LGS acknowledge the 3Dx device in their software so this workaround gives all the devices operation with only the 3Dx screen being dark.

Just thought I'd throw that in there on the off chance it might help someone.

Take care, Happy Holidays and now off to write more xml's for more software. Yee-Haa

Quantum
Remember, there's no "i" in Team America...................yes there is

[quantum69]

Sorry, couple of things to add/ask.

1) My directions in my comments were derived from using HIDJoystick_ to see what deflecting the cap generated. When using KB_Keystroke they are backwards, but not always. Just something to watch for.

2) When 3Dx Properties parses the xml file, are you looking for \0x09 (tab) or \0x20 at the beginning of lines? I notice if I have leading spaces and not tabs 3Dx Properties doesn't like the file, if I replace with leading tabs it's fine.

thanks

[quantum69]

3Dx admins/mods

FYI:

with logging off, the 3DxService.log is showing this

Code: Select all

00002000 10:51:5.198: siappdll: __FILE__: .\src\appsi.cpp,  __LINE__: 4529, ErrorVal: 2
00002000 10:51:5.198: siappdll: __FILE__: .\src\appsi.cpp,  __LINE__: 4529, ErrorVal: 2
00002000 10:51:5.199: siappdll: __FILE__: .\src\appsi.cpp,  __LINE__: 4529, ErrorVal: 2
00002000 10:51:5.199: siappdll: __FILE__: .\src\appsi.cpp,  __LINE__: 4529, ErrorVal: 2
00002000 10:51:5.199: siappdll: __FILE__: .\src\appsi.cpp,  __LINE__: 4529, ErrorVal: 2
00002000 10:51:5.200: siappdll: __FILE__: .\src\appsi.cpp,  __LINE__: 4529, ErrorVal: 2
00002000 10:51:5.200: siappdll: __FILE__: .\src\appsi.cpp,  __LINE__: 4529, ErrorVal: 2
00002000 10:51:5.200: siappdll: __FILE__: .\src\appsi.cpp,  __LINE__: 4529, ErrorVal: 2

Just so you know.

[jwick]

Sorry, couple of things to add/ask.

1) My directions in my comments were derived from using HIDJoystick_ to see what deflecting the cap generated. When using KB_Keystroke they are backwards, but not always. Just something to watch for.

2) When 3Dx Properties parses the xml file, are you looking for \0x09 (tab) or \0x20 at the beginning of lines? I notice if I have leading spaces and not tabs 3Dx Properties doesn't like the file, if I replace with leading tabs it's fine.

thanks

I tested spaces instead of tabs for white space. 3DxSmartUI didn't seem to have any problems parsing the files. Perhaps you can PM the file that doesn't work to me.