Menu
▾
▴
#2212 35 Buttons for Joysticks
New
nobody
Low
2024-11-05
2020-04-16
No
My flight yoke has 35 buttons and 4 axis. In FG property tree the buttons stop at 31 (plus the 0), so I am missing the last three buttons. The jstest-gtk program shows all buttons work. The missing buttons are for mag-left, mag-both & start.
Is there a limit on the number of buttons and if so is there a way to increase this limit?
Thanks !
FlightGear 2018.3.2
Raspberry Pi4
Honeycomb Aeronautical Alpha Flight Controls - Yoke
Currently there's a hardcoded limit of 32 buttons
The relevant code is flightgear/src/3rdparty/joystick/js.h
CODE: SELECT ALL
define _JS_MAX_BUTTONS 32
I'd need to discuss this with James to check if there's any issue with increasing the limit. Could you create a ticket via the bugtracker and include the information above please. That will make it easier to track.
Thanks!
-Stuart
- Bindings for Honeycomb Aeronautical Alpha Flight Controls - Yoke
*
* - Axis 0: ailerons
- Axis 1: elevator
- Axes 2 and 3 (hat): view direction
- Button 0: YOKE white-Trigger left-handle
- Button 1: YOKE white-top-Button left-handle
- Button 2: YOKE white-top-Button right-handle
- Button 3: YOKE red-top-Button right-handle
- Button 4: YOKE outer-Rocker down left-handle
- Button 5: YOKE outer-Rocker up left-handle
- Button 6: YOKE inner-Rocker down left-handle
- Button 7: YOKE inner-Rocker up left-handle
- Button 8: YOKE top-Rocker inward right-handle
- Button 9: YOKE top-Rocker outward right-handle
- Button 10: YOKE bottom-Rocker inward right-handle
- Button 11: YOKE bottom-Rocker outward right-handle
- Button 12: BASE Master Alternator up
- Button 13: BASE Master Alternator down
- Button 14: BASE Master Battery up
- Button 15: BASE Master Battery down
- Button 16: BASE Avionics Bus1 up
- Button 17: BASE Avionics Bus1 down
- Button 18: BASE Avionics Bus2 up
- Button 19: BASE Avionics Bus2 down
- Button 20: BASE Beacon up
- Button 21: BASE Beacon down
- Button 22: BASE Land up
- Button 23: BASE Land down
- Button 24: BASE Taxi up
- Button 25: BASE Taxi down
- Button 26: BASE Nav up
- Button 27: Base Nav down
- Button 28: BASE Strobe up
- Button 29: BASE Strobe down
- Button 30: BASE Off
- Button 31: BASE Right Mag
- Button 32: BASE Left Mag
- Button 33: BASE Both Mag
- Button 34: BASE Start
Related
Quick answer is, I have no clue if we can just raise th enumber or if something will explode :)
Of course if you use HID-input you can have unlimited buttons.
I just checked, and we only use MAX_BUTTONS on BSD. On Linux we query the count via JSIOCGBUTTONS iocto. So 32 might be a kernel limit. Again my recommendation would be to use HID input if you're brave, but this is a fairly undocumented option for now.
Where do I start to learn about HID input?
The js-test-gtk functions perfect with 35 buttons. However I would be happy
to learn HID input.
Thanks,
Jeff
On Thu, Apr 16, 2020 at 5:47 PM James Turner jmturner@users.sourceforge.net
wrote:
Related
Tickets: #2212
Jeff, I did a bit more looking, we actually had a hard-coded limit in another place. So we can 'just' raise that. Unfortunartely I can't test Linux very easily, so I'll need to raise it and then get @stuartbuchanan to test, unelss you are able to build from Git yourself.
James, at this time I can not build from Git and will not benefit from the revision at this time. There is no rush, I can hack the hardware if needed. Do what is best for FG and your resources ! !
If HID input is the future, I would be happy to try to use it and write a WiKi of my struggles :) -- However, I do not know where to start.
Thanks,
Jeff
On Saturday, April 18, 2020, 08:06:39 AM EDT, James Turner jmturner@users.sourceforge.net wrote:
Jeff, I did a bit more looking, we actually had a hard-coded limit in another place. So we can 'just' raise that. Unfortunartely I can't test Linux very easily, so I'll need to raise it and then get @stuartbuchanan to test, unelss you are able to build from Git yourself.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/flightgear/codetickets/2212/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
I'll dig out some example files for you. However, until we make a new release, HID input also won't work for you, I realised : so once 2020.1 is out (in the next few weeks, you can try then) - and yes documenting the process would be very welcome.
I did some experiments with extending the number of buttons in the old code. The core functionality was quite easy to change, but we have a lot of secondary code (configuration UIs, test programs, etc which assumes a maximum of 32 buttons. So I broke all of those, and fixing them would be more work.
Do you have a branch with the work in progress somewhere, so I or somebody could try to take it further?
I'll rebease the branch and push it. The summary version is that to avoid re-writing many places, I added a 'get the first 32 buttons in the old format' helper, but the core reading of the Joystick device and firing the bindings should work with any number. But debugging axes , confgiuration GUI, etc will need more effort to show the extra buttons.
I gave it a shot myself over the weekend, because the 48-button Honeycomb Aeronautical Bravo Throttle Quadrant is not usable otherwise. The current code wraps the button around so button 32 registers as 0, 33 as 1 etc., and many of the high buttons on the Throttle Quadrant are switches that report one button in each position, so they make also the low buttons unusable.
I went the other way and intentionally broke the interface by replacing the
intwith astd::vector<bool>. It didn't break all that many places, so I also patched up (except some formatting) the js_demo and the similar code in jsinput (is that used in fgjs? fgjs is of little help for these aeronautical “joysticks” anyway). I've noticed a couple of issues:Okay, that's the same approach I was taking actually.
For Windows we should stop using the joystick interface (which is anxcient) and use USB-HID: there is code to support that (HID-event-input) but for other reasons it's complicated on Windows. But that's what DirectInput, etc would use to support an arbitrary number of buttons on Windows.
The scroll wheels can be exposed via HID again as dials/rotaries (HID has proper type codes for all these controls), but some APIs will make them appear as several linked switches, unfortunately. And of course HID is an event based API :)
To rpoceed: do you want to push your code to a branch somewhere, and I can try it on macOS and Windows, and merge any parts from my similar branch?
I've pushed it here: https://github.com/jan-hudec/flightgear/tree/topics/joystick-2212
I didn't include the tweak to remove libc++ from CMakeLists.txt that I needed to compile with clang on linux (clang on linux uses gnu stdlibc++ for compatiblity with gcc), which I needed because I was getting an ICE from gcc. I have to retest that; it's a separate issue.
Re-ping: just reviewing the code for this, it looks okay, I worry that in the public APis we should assume 32 buttons minimum even if the real OS returns fewer (eg BSD) : otherwise we might not create properties for say buttons[12] and some other code may assume such properties exist.
I.e use std::max(realNumButtons, 32) to size how many buttons we report.
Related: for js_demo, won't this screw up the column formatting? Or does it just work out ok?
I've returned to this after a while and concluded that since other platforms don't support that many buttons in their joystick API, but the HID API is available everywhere, it will be better to use that.
… except that at that moment I noticed a discrepancy between the FGLinuxEventInput and FGHIDEventInput implementations. I'll discuss the details elsewhere, but in short both detected the same device and use different event names.
I also intend to make a small fix to just eliminate the button aliasing (on x86 and amd64 the right argument to << is taken modulo 32, so button 32 aliases button 0, button 33 aliases button 1 and so on).
Unfortunatly while linux-Event uses HID underneath, it does seem to do some renaming. I've never done enough work with EventInput to figure out if I am doing something wrong in the HID code, or there is an intentional re-naming in the Event layer.
I'll try to dig into it. It's been a while since I did anything to the Linux kernel, but I hopefully can get my way around it well enough to check.
The problem is that on Windows only the HID implementation is available, but on Linux the HID implementation requires tweaking udev rules to get access to the /dev/hidrawX device and the LinuxEvent implementation does not. So there would be some benefit in making the two behave consistently rather than just unifying on the HID version.
Related
Tickets: #2212
Right I had the idea to use libEvent for most devices, and then offer 'raw HID' as an option: needed for some devices. This would be much easier if the names / indices were 100% compatible between the two.