VKB-SIM

i am looking to upgrade from 16000m to VKB Gladiator NXT's (HOSAS setup) but i currently run manjaro linux (arch based). Will each stick register as differently or will it register the same twice? bottom line will duel stick properly register on linux

So, full disclosure, I haven't actually tested this exactly, but:

Even with the same VID:PID combo (so, enumerating as same stick), Linux doesn't care - it still differentiates between them. In order to get predictable enumeration (joy0 is always joy0) you may need to plug them in in a certain order because udev rules won't be able to tell the difference, but they will work. This should be exactly the same situation as your current HOSAS setup, as they would work the same way.

BUT

I believe I saw, somewhere in the software, the ability to set a custom PID. Now, the downside is that you'd need Windows (or a VM) to do this, but the upside is that you'd only need to do it once. Then you can set up your udev rules to get predictable device assignments. Thing is, I can't remember where, and I can't find it in the manual, and my joystick is actually a Christmas present from my mom and so I tested it to make sure it all worked and then wrapped it up for me to open on Christmas morning and be surprised. So, I can't say "it's this setting, right here".

I've used this. It will put into whatever order you like your controllers to be in a game. Give it a try.

https://github.com/briankendall/devreor ... devreorder

Think there's a guide in the zip.

mattcaron wrote:Even with the same VID:PID combo (so, enumerating as same stick), Linux doesn't care - it still differentiates between them. In order to get predictable enumeration (joy0 is always joy0) you may need to plug them in in a certain order because udev rules won't be able to tell the difference, but they will work. This should be exactly the same situation as your current HOSAS setup, as they would work the same way.

BUT

I believe I saw, somewhere in the software, the ability to set a custom PID. Now, the downside is that you'd need Windows (or a VM) to do this, but the upside is that you'd only need to do it once. Then you can set up your udev rules to get predictable device assignments. Thing is, I can't remember where, and I can't find it in the manual, and my joystick is actually a Christmas present from my mom and so I tested it to make sure it all worked and then wrapped it up for me to open on Christmas morning and be surprised. So, I can't say "it's this setting, right here".

the 16000m have a left/right switch in the base which i "thought" differentiated them in the udev rules but like you stated i have to plug them in using a specific order to get the keybinding correct... i actually never dug deep into it as they worked out of the box. assigning it a separate PID through software sound like the way to go... i know ill need to use a VM at some point as i have not seen a way to update firmware in linux which is a shame. i do like how the NXT's can be calibrated via hardware without the need of any OS. im wondering if it as accurate as calibration via the software... hmmm

Drano wrote:I've used this. It will put into whatever order you like your controllers to be in a game. Give it a try.

https://github.com/briankendall/devreor ... devreorder

Think there's a guide in the zip.

the link gave me a 404 but i found it reguardless at https://github.com/briankendall/devreorder it look to be directed at windows but ill look into this further here in the near future... thanks

I just copy/pasted the link. Must not have gotten part of it. I just skimmed the post and missed you're using Linux, but this will work with windows. Maybe it can work with Linux?

Basically, how this works is you're editing a file with a text editor and cut/paste the device IDs in the order you want them within a game folder you're putting this program into. It doesn't work system-wide, only game specific so you can have different device orders for different games. Been a while since I've used it but it's one of those set it and forget it things once you get it where you want it.

Oh and be advised, the VKB IDs all seem to have a space at the beginning for some reason. So if you see that, it's not just you.

ClawOverdraw wrote:the 16000m have a left/right switch in the base which i "thought" differentiated them in the udev rules but like you stated i have to plug them in using a specific order to get the keybinding correct... i actually never dug deep into it as they worked out of the box. assigning it a separate PID through software sound like the way to go... i know ill need to use a VM at some point as i have not seen a way to update firmware in linux which is a shame. i do like how the NXT's can be calibrated via hardware without the need of any OS. im wondering if it as accurate as calibration via the software... hmmm

Thinking on this more:

1. I fired up my VM and the config software, but it doesn't do anything without a stick plugged in.

2. According to the initial tracking information, my Gunfighter (Christmas gift from my wife) is to arrive Monday. Even if we reasonably expand this to "sometime this week", it is hopefully in your timeframe. I am going to unbox, assemble, and function test it before disassembling and wrapping it up for Christmas. When I test it, I will try to find the screen with the PID assignment on it.

3. Even with a different VID:PID combination (as is the case with my current CH fighterstick and throttle) I still need to plug them in the correct order because I never set udev rules for those either, and that works fine - plug in the joystick first, wait a beat for it to get js0, then plug in the throttle and it gets js1. Done. Even identical ones should enumerate differently way because the DEVPATH will be different - even different ports on the same hub will have different paths. For example, plugging the same stick into one port and then the other (next to each other) on the front panel USB ports on my gaming rig gets me:

and

Now, I can't test it really well because I don't have two of the same sticks, but it should be a reasonable proxy.

Making some assumptions as to how Manjaro is set up, you can test it by plugging in both your sticks and looking at the output from and the contents of and ensuring that they are different - despite possibly having the same VID:PID combination (which would show you.

4. As far as consistent ordering of things, if you can figure out a differentiator, rules should be able to take care of it, working in place of that DirectInput joystick mapper doodad. I'll try and look into this with my existing sticks in the next few weeks and will publish my results here.

5. Finally, I'd like Linux configurator support too - that's the one thing that FreeJoy has over VKB, IMO. Hell, I'd love to write a cross platform configuration utility, but I'm not sure the ROI is there, even if I were to do it for free (and if folks from VKB are interested, I'll happily send them my resume). But, I do most of my gaming under Linux (I have an SDD with W10, Fallout 4 and Cyberpunk 2077 on it, and I literally flip drives to boot it up and play those few games; everything else runs under DOSBox/Wine/Proton) so you can be certain that I'll be messing with it. I have some faith that, eventually, it will become worth it - Valve has certainly decided that it is with their Steam on Linux work, but, while I am exceedingly grateful for that work, Steam Linux is apparently barely over 1% (Source: https://www.phoronix.com/scan.php?page=news_item&px=Steam-Linux-9-Years-Since-Beta). Given that VKB is a much smaller concern, I can't imagine them pouring tons of time into a Linux configurator over such small numbers, especially when there is both a reasonable workaround (VirtualBox and a $100 Windows 10 license which most people have anyway) and stuff like the TECS to get out which actually drives real revenue.

As a general open invitation, anyone is welcome to contact me directly about Linux related stuff. I've been both running Linux and writing software and firmware for more than 20 years now. Always happy to help; worst I can say is that I don't know.

Alright, followup.

First, the GF + SCG arrived today. This is my first cam-based stick and I am simply blown away. Sure, I want to switch out cams and springs, and certainly the Gladiator NXT is no slouch either (it's feels like my CH flightstick after generous application of Nyogel 767A, only better), but the GF base is just a step above.. so I'll likely be swapping out that base for a GF base, but still using it as the HID controller for a SEM button panel arrangement (I'll just run it with no grip and then I'll still have the axis, 3 buttons, and 2 encoder wheels because.. MOAR buttons.

Anyway, hooked up the GF + SCG and function tested it, and what I was vaguely remembering was not the ability to set the VID or PID, but rather the ability to set the serial number and profile ID. Here's the default dump from `lspci -v`:


and here is the same dump after setting the SN to 0042 and the Profile ID to 1

The diff is as follows:

I assume the USB enumeration change is a result of writing the config (bus disconnect and reconnect), but the fact that the serial number is indeed different suggests to me that you can set different serial numbers for your left and right sticks, and then a udev rule should work.

Testing this, I set the serial to 0001 (for my right handed stick base, I figure 0000 is uninitialized, 0001 is right, 0002 is left, 0003 is button panels), and this works for that setup. Note that I will have a GF right and GNX left, so I could do it on VID:PID, but I wanted to test the theory.

Now, all that said and done, it works, but isn't really useful. `jstest-gtk` only shows up js0, and it doesn't seem like unless you are explicitly telling the software what to use, it will work. Digging in to this slightly (after trying to have udev set the device entry by the NAME keyword replacing SYMLINK), it would appear that one cannot do this. See https://askubuntu.com/questions/920098/udev-rules-name-variable-not-working and the sources they cite there.

So, coming back around:
1. Even if everything is identical, they should both be seen and, absent any other controllers, the first one plugged in will be `/dev/input/js0` and the second will be `/dev/input/js1`.
2. You can set the serial number, but I'm not sure that, given the above, there is any point to doing so.
3. My dreams of `/dev/input/jsright` instead of `/dev/input/js0` do not appear to be possible.
4. Even if 3 was, you just know that it would break something silly, like, say, every SDL game or DOSBox or something like that.

I think that about covers it.