Hi Dave!
Just starting to get some rain this week here after weeks without, so nothing like what you or Manitoba are getting - my brother there said he was sure there was a lawn somewhere under the lake around his property ....... !
Hi Mark, actually had 2 days in a row without rain, nice.
You're testing guide is fairly good, I did get lost in editing xeventsF1d.cmd, wasn't sure how to update it when it came to pressing buttons etc. I actually got 2 lines of output each time I did something, then something else came up and I got distracted. Other then that, it is pretty good.
Thanks
As mentioned previously, when Wim created the gamepad package, the xevents files provided were customized in nature, based on equipment that Martin had provided and information about my original Thrustmaster joystick. Wim has done an amazing job on this project, in most cases at least for me going solely on the testing data I send him and lsusb reports, but as he has mentioned a number of times, we are still in the highly experimental stage.
I realize now that the xeventsf1d file was probably not the best one to provide - it was written for a joystick that has 4 buttons, a hat and the typical joystick movement mechanism, as well as an additional 6 buttons on the base, a throttle slider (which generates output but is probably useless for our applications and is programmable only in Windows)
I have not added anything currently in the guide I compiled about modifying xevents.cmd, but given you sound like your pretty busy at the moment, I wonder if you can simply try this.
I've attached xeventsjoy.cmd below, which is a version of the original xevents Wim provided, with some tweaking based on things we've found so far during testing.
Go into the file, which is for my older joystick, and modify the following:
Change Line 9:
ddNameI='$THRUST$' ; ddNameO='GAMEPAD$'
to ddNameI=<name for your device>
(ie. the /N: name you gave it in CONFIG.SYS)
Change Line 13:
info='DEVICE=?:\OS2\BOOT\USBECD.SYS /D:0583:203#:0110 /N:'ddNameI
to add the specific /D: info for your game controller as entered in CONFIG.SYS
Save the xevents.cmd file at that point and run it from a windowed command prompt.
If the device drivers are working and that is successful, you should see output being generated in the open window similar to:
Ax=4900, Ay=5600, Bx=FF00, By=6F00, Buts=F000
The output will continue every time an action is taken with your game controller and will vary based on what control is pressed or joystick movement occurs. Closing the window will stop the command file
You could try something similar for Gamepads, using one of the files contained in the directories other than in RM203 (that is my joystick) in the latest of Wim's Gamepad device driver package.
I'm curious to see if you just make those minor adjustments, Dave, without changing anything else, whether the xeventsjoy file would work for others - the whole basic output of joysticks really has not changed for decades, so if your using a simple joystick for testing most if not all of the other lines should work without modification.
The only basic weird thing we noticed when I did the same experiment with the new joystick, modifying the original xevents file, came when the output in the window was coming out as:
Packet=00F0FF808080FF00,Huh?
Packet=00F0FF808080FF00,Huh?
Packet=00F0FF808080FF00,Huh?
Packet=00F0FF808080FF00,Huh?
etc.
From the lsusb report we learned that the new joysticks input reports are only 7 bytes long. With the older joystiock it obtained 8 byte input records and check the 8th byte for certain values. That is why those HUH? packets were encountered.
I fine day to you Dave and Best!
M