"Game Controller" does not call back on all axis
Re: "Game Controller" does not call back on all axis
It must be something more specific to the way the Saitek operates then because after the first fix my TPR set work fine on all 3 axis. So it’s not a generic rudder pedal issue. It seems a bit weird but there is bound to be a logical answer.
Air Manager panels at https://www.experimentalsimavionics.com
Youtube Channel https://www.youtube.com/channel/UC8ZqXX ... kfZMq5BKig
Air Manager API Tutorial Video Series https://youtube.com/playlist?list=PLNr0 ... baT4gJKg5D
Youtube Channel https://www.youtube.com/channel/UC8ZqXX ... kfZMq5BKig
Air Manager API Tutorial Video Series https://youtube.com/playlist?list=PLNr0 ... baT4gJKg5D
Re: "Game Controller" does not call back on all axis
Hi,
I think the logical answer is to not try to look at certain manufacturers specific inputs and declarations as they are non standard in most cases and entirely up to the manufacturer in their descriptors and interpretation.
I would say it is better to use a single format for all. If that was the case, then it would certainly appear to be the generic joystick class - 8 axis, 32 buttons and 2 hats. Standard axis naming is X Y Z rX rY rZ Dial Slider. then of course the buttons an the hats.
Possibly a way to do this is to have AM react to an axis movement - in a setup way - to assign it to a specific axis ?. (as per most manufactures 'setup' programs.)
As an example, what would be the result of a generic USB Joystick on an Arduino 32U4, or, a Bonder board, where absolutely none of these 'rudder' etc conventions apply ? - this would surely need complete manual intervention of assignments as what you connect to what axis of these boards is entirely up to you.
Joe
I think the logical answer is to not try to look at certain manufacturers specific inputs and declarations as they are non standard in most cases and entirely up to the manufacturer in their descriptors and interpretation.
I would say it is better to use a single format for all. If that was the case, then it would certainly appear to be the generic joystick class - 8 axis, 32 buttons and 2 hats. Standard axis naming is X Y Z rX rY rZ Dial Slider. then of course the buttons an the hats.
Possibly a way to do this is to have AM react to an axis movement - in a setup way - to assign it to a specific axis ?. (as per most manufactures 'setup' programs.)
As an example, what would be the result of a generic USB Joystick on an Arduino 32U4, or, a Bonder board, where absolutely none of these 'rudder' etc conventions apply ? - this would surely need complete manual intervention of assignments as what you connect to what axis of these boards is entirely up to you.
Joe
Joe. CISSP, MSc.
-
- Posts: 236
- Joined: Sun Feb 14, 2021 6:55 pm
Re: "Game Controller" does not call back on all axis
I do not think it is specifically a Saitek only issue. As Joe mentioned there is probably no game controller that adheres to all conventions but the most simple ones or those using cheap generic boards. I have used one myself with unconventional circuitry, like connecting a resistor ladder and multi pole switches instead of a potentiometer to the analog axis inputs.
On the X52 the axis are currently assigned like this:
X is axis 0 (Joystick left/right action)
Y is axis 1 (Joystick push/pull action)
Z is axis 2 (Throttle lever)
Xr is axis 5 (Small dial)
Yr is INOP (Large dial)
Zr is axis 3 (Joystick twist action)
slider is axis 4 (Slider action)
hat is axis 6 (POV multiway switch left/right) and axis 7 (up/down)
I would support Joe in his statement that "it is better to use a single format for all" and do the differentiation in the instrument code.
When we get it working I would upload my own 4 instruments for the community. I even thought about creating a wiki page for each of them.
Paul
Re: "Game Controller" does not call back on all axis
Maybe I used the wrong words. By specific I think I really meant different. I suppose other devices could have the same issue if configured in the same way as whatever is causing the issue with the Saitek. I guess I used specific because I haven’t heard anyone else reporting issues with other devices but that may be because this feature is simply not used that much in AM.
I wasn’t suggesting a custom solution for each manufacturer but simply that however the Saitek is configured it’s obviously different to say my set of rudder pedals. It may just be something like it’s using an axis that mine is not or perhaps it’s not using sequential axis and that is where the bug lies. I’d be interested to know what axis the Windows game controller app says the Saitek is using. I know when I coded the HID for my 6 channel custom throttle quadrant I just had to pick the 6 that made most sense but as Joe suggested the functionality is the same and the axis is just a name really.
I wasn’t suggesting a custom solution for each manufacturer but simply that however the Saitek is configured it’s obviously different to say my set of rudder pedals. It may just be something like it’s using an axis that mine is not or perhaps it’s not using sequential axis and that is where the bug lies. I’d be interested to know what axis the Windows game controller app says the Saitek is using. I know when I coded the HID for my 6 channel custom throttle quadrant I just had to pick the 6 that made most sense but as Joe suggested the functionality is the same and the axis is just a name really.
Air Manager panels at https://www.experimentalsimavionics.com
Youtube Channel https://www.youtube.com/channel/UC8ZqXX ... kfZMq5BKig
Air Manager API Tutorial Video Series https://youtube.com/playlist?list=PLNr0 ... baT4gJKg5D
Youtube Channel https://www.youtube.com/channel/UC8ZqXX ... kfZMq5BKig
Air Manager API Tutorial Video Series https://youtube.com/playlist?list=PLNr0 ... baT4gJKg5D
-
- Posts: 236
- Joined: Sun Feb 14, 2021 6:55 pm
Re: "Game Controller" does not call back on all axis
The Windows game controller app does not report axis information for the flight rudder pedals. It just uses the names as shown here:
'Axis and Ohs' reports:
Left Toe Brake as 'Flight Rudder Pedals X'
Right Toe Brake as 'Flight Rudder Pedals Y'
Rudder action as 'Flight Rudder Pedals RotationZ' (the same as the X52 reports for joystick twist action).
'MSFS 2020' reports:
Left Toe Brake as 'JOYSTICK L-AXIS X'
Right Toe Brake as 'JOYSTICK L-AXIS Y'
Ruddder action as 'JOYSTICK R-AXIS Z'
Paul
'Axis and Ohs' reports:
Left Toe Brake as 'Flight Rudder Pedals X'
Right Toe Brake as 'Flight Rudder Pedals Y'
Rudder action as 'Flight Rudder Pedals RotationZ' (the same as the X52 reports for joystick twist action).
'MSFS 2020' reports:
Left Toe Brake as 'JOYSTICK L-AXIS X'
Right Toe Brake as 'JOYSTICK L-AXIS Y'
Ruddder action as 'JOYSTICK R-AXIS Z'
Paul
Re: "Game Controller" does not call back on all axis
I have been digging through some stuff I have here - my old copy of the Bible - USB Complete Jan Axleson, some old code.. - and some references to the 'page' types. also of course, to USB.org
Where I am coming from is to suggest that using the GENERIC DESKTOP PAGE (0x01) - as opposed to the SIMULATION CONTROLS PAGE (0x02) is a far better option as there seems to be no standard usage of the PAGE (0x02), or, to put it, perhaps, more correctly is that devices using the PAGE (0x02) and a chosen sub type may incorporate multiple pages of different types in the same device (nightmare!)
What it would tend to mean is that whatever comes in is broken down to basic axis only... and then resent as PAGE (OX01) types, although this may not even be possible as it would appear that AM is acting as a middleman to grab info - I presume taking HID in, and then re-sending the original back to the OS ?
In that case, as the flight sims tend to ignore the PAGE (0x02) and break it down to axis by identification of axis movement in the setup. The only way I could see this being done is by a 'recognition' program or section within AM where each control, axis, button, hat etc is moved an the result mapped within AM.
HATs for example have been mentioned, and as Paul says, some have used combinations of resistor ladder types and button options to serve a similar purpose, often because the device has more of this type of control than is normally provided for.
Under a standard PAGE (0x01) then 0x30 to 0x39 would give all the axis AND the HAT - HAT being 0x39. - also, HAT in this case being a 4 button arrangement that does not take away from the 32 buttons available.
It is a nightmare to act as a middleman me thinks. IN fact, HID is a bloody nightmare and still gives me sleepless nights
https://www.usb.org/sites/default/files ... 1_12v2.pdf (check around page 22...)
Joe.
Where I am coming from is to suggest that using the GENERIC DESKTOP PAGE (0x01) - as opposed to the SIMULATION CONTROLS PAGE (0x02) is a far better option as there seems to be no standard usage of the PAGE (0x02), or, to put it, perhaps, more correctly is that devices using the PAGE (0x02) and a chosen sub type may incorporate multiple pages of different types in the same device (nightmare!)
What it would tend to mean is that whatever comes in is broken down to basic axis only... and then resent as PAGE (OX01) types, although this may not even be possible as it would appear that AM is acting as a middleman to grab info - I presume taking HID in, and then re-sending the original back to the OS ?
In that case, as the flight sims tend to ignore the PAGE (0x02) and break it down to axis by identification of axis movement in the setup. The only way I could see this being done is by a 'recognition' program or section within AM where each control, axis, button, hat etc is moved an the result mapped within AM.
HATs for example have been mentioned, and as Paul says, some have used combinations of resistor ladder types and button options to serve a similar purpose, often because the device has more of this type of control than is normally provided for.
Under a standard PAGE (0x01) then 0x30 to 0x39 would give all the axis AND the HAT - HAT being 0x39. - also, HAT in this case being a 4 button arrangement that does not take away from the 32 buttons available.
It is a nightmare to act as a middleman me thinks. IN fact, HID is a bloody nightmare and still gives me sleepless nights
https://www.usb.org/sites/default/files ... 1_12v2.pdf (check around page 22...)
Joe.
Joe. CISSP, MSc.
Re: "Game Controller" does not call back on all axis
Hi,
That goes way too deep. Windows has API's you can use that handle all that stuff.
This is also something we can have a look at next Friday I guess
Corjan
That goes way too deep. Windows has API's you can use that handle all that stuff.
This is also something we can have a look at next Friday I guess
Corjan
Re: "Game Controller" does not call back on all axis
HI @Corjan - sorry, my post overlapped with yours - I will leave it for info though for anyone playing with Arduino hid descriptors etc.
To add a little more that may be helpful ?
There some rather complex USB hardcore in depth look and capture programs. However, for what most use for simulation can mostly be viewed (as far as what axis is actually assigned to what - try a really nice old program I have in my collection. - again, it is old, and alpha.. but still better than windows CPL for most uses.
link is -
http://www.planetpointy.co.uk/joystick- ... plication/
Grab the program if doing anything with HID at a basic level but bear in mind it is 7 years old, but still very informative.
Here is a screen shot of an example showing a quick HID unit I knocked up on a pro micro - the unit has 2 hats. Notice the win cps doesn't show the second hat, whereas the Pointy's program does. The pro micro is actually programmed as FOUR joystick / game controllers in one device (just for a test) - only two are shown in the win cpl whereas all 4 are shown in the Pointy's program.
It is also possible, so I found out! - to use the same hex type multiple times in the descriptor. nice... for example you can have 2, or however many 'sliders' or whatever by simply adding more to the descriptor with the same hex designation.
https://forum.pjrc.com/threads/23681-Many-axis-joystick
I don't intend to go off topic at all with this, I am merely pointing out the immense amount of assignments available and hence the hurdles to overcome.
Joe.
To add a little more that may be helpful ?
There some rather complex USB hardcore in depth look and capture programs. However, for what most use for simulation can mostly be viewed (as far as what axis is actually assigned to what - try a really nice old program I have in my collection. - again, it is old, and alpha.. but still better than windows CPL for most uses.
link is -
http://www.planetpointy.co.uk/joystick- ... plication/
Grab the program if doing anything with HID at a basic level but bear in mind it is 7 years old, but still very informative.
Here is a screen shot of an example showing a quick HID unit I knocked up on a pro micro - the unit has 2 hats. Notice the win cps doesn't show the second hat, whereas the Pointy's program does. The pro micro is actually programmed as FOUR joystick / game controllers in one device (just for a test) - only two are shown in the win cpl whereas all 4 are shown in the Pointy's program.
It is also possible, so I found out! - to use the same hex type multiple times in the descriptor. nice... for example you can have 2, or however many 'sliders' or whatever by simply adding more to the descriptor with the same hex designation.
https://forum.pjrc.com/threads/23681-Many-axis-joystick
I don't intend to go off topic at all with this, I am merely pointing out the immense amount of assignments available and hence the hurdles to overcome.
Joe.
Joe. CISSP, MSc.
Re: "Game Controller" does not call back on all axis
Hi Corjan
what happens 'next Friday ?
Joe
Joe. CISSP, MSc.
-
- Posts: 236
- Joined: Sun Feb 14, 2021 6:55 pm
Re: "Game Controller" does not call back on all axis
Hey Joe
Friday is remote debugging day...
Friday is remote debugging day...