assign input buttons to X-Plane 11 functions

Question

I have a small (custom) Arduino-based box I built for use with X-Plane 10.  On X-Plane 10's configuration screen, the button inputs appeared in a big matrix, and I was easily able to identify the inputs and assign them to functions.

This is not the case on X-Plane 11.  I see no inputs except for the commercial products (CH Products Yoke and Rudder) I've bought.  My own custom radio controls are nowhere to be found.  There appears to be no "advanced" menu or separate app I can use to configure the controls.

So, how can I go about getting my existing controls working with the new X-Plane 11?  I've done a lot of searching on line and have come up with very little information.

To answer some questions that might come up:

- This is on OpenSUSE Linux.

- Yes, X-Plane 11 is otherwise working great here.

- CH Products Yoke worked right out of the box.

- CH Products Rudder required a little bit of udevadm work due to bad device permissions.

- I can see and read my custom buttons in /dev/input/by-id using my own application.

- I just can't see them appearing anywhere in X-Plane 11, though they worked with X-Plane 10.x

Download file

 

Comments

Please attach a log.txt for investigation.

---

Attached to original question.  I don't think it's going to help.  There's no hint that X-Plane even notices this driver, though it's clearly present and available:

% ls -lL /dev/input/by-id
total 0
crw-rw----+ 1 root input 13, 83 Aug 12 17:27 usb-CH_PRODUCTS_CH_FLIGHT_SIM_YOKE_USB-event-joystick
crw-rw-r--+ 1 root input 13,  1 Aug 12 17:27 usb-CH_PRODUCTS_CH_FLIGHT_SIM_YOKE_USB-joystick
crw-rw-r--  1 root input 13, 82 Aug 13 13:30 usb-CH_PRODUCTS_CH_PRO_PEDALS_USB-event-if00
crw-rw----  1 root input 13, 68 Jul 15 12:10 usb-Logitech_USB_Receiver-event-if01
crw-rw----  1 root input 13, 67 Jul 15 12:10 usb-Logitech_USB_Receiver-event-mouse
crw-rw----  1 root input 13, 32 Jul 15 12:10 usb-Logitech_USB_Receiver-mouse
crw-rw-r--  1 root input 13, 84 Aug 13 13:33 usb-knobs\@workingcode.com_X-Plane_Knobs-event-if00

This means it's recognized properly by Linux as HID, and the permissions are fine.  I've used other programs (such as qjoypad), and they're able to see these buttons without trouble.

And, as I mentioned, it worked great on X-Plane 10, which provided a separate page to allow mapping of any unrecognized buttons into X-Plane functions.  All HID advertising buttons showed up there.  The new dumbed-down "easy" interface in X-Plane 11 is nice for the commercial gear -- it just pops up and works without a bunch of configuration.  That's great.  But it completely shuts out custom hardware, and that's a giant step backwards for me.

Answer 1

Hi there!

I'm Tyler, the X-Plane developer in charge of joysticks for X-Plane 11. Here's how you can do some additional troubleshooting on the device:

1. Launch X-Plane with your custom device unplugged.
2. Open the art control editor (from the in-sim menu: Plugins > Dataref Editor > Show Art Controls) and set hid/debug/joys to 1.
3. Plug in your device.
4. Your Log.txt will be populated with a bunch of additional info about the device (the lines will begin with "[time] D/HID:")

If you get *no* HID debugging info for your device, it's probably because the device doesn't look "joystick-like" to X-Plane. Here's the code we use to determine if a device looks like a joystick on Linux:

 

int IsJoystick(int fd)
{
    // Allocate arrays bit enough to hold the event bitmasks
    unsigned long evbit[NBITS(EV_MAX)]       = {0};
    unsigned long keybit[NBITS(KEY_MAX)]     = {0};
    unsigned long absbit[NBITS(ABS_MAX)]     = {0};

    // Get the event bitmasks
    if((ioctl(fd, EVIOCGBIT(0, sizeof(evbit)), evbit)             < 0) ||
       (ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(keybit)), keybit)     < 0) ||
       (ioctl(fd, EVIOCGBIT(EV_ABS, sizeof(absbit)), absbit)     < 0))
    {
        return 0;
    }

    // Require that the device have at least 1 absolute axis
    if(!(test_bit(EV_ABS, evbit) && (test_bit(ABS_X, absbit) || test_bit(ABS_Y, absbit))))
    {
        return 0;
    }
    return 1;
}

If I had to guess, I'd say perhaps your device has no absolute axes?

Comments

Thank you so much for your reply!

Indeed it does not have an absolute axis.  It's a box with two concentric rotary encoders with detents that I use as radio control knobs and that I present as up/down button presses after decoding the quadrature output.  I have several other ordinary SPST momentary buttons that can be assigned for other functions.

I also have two plain rotary encoders that I intend to use as course select and OBS.  Currently, I decode those as up/down button presses as well, because that's what X-Plane 10 wanted.  I can certainly convert them to axes instead; that may well be a better encoding, *if* X-Plane 11 can deal with OBS as a smooth value rather than as up/down presses.

Why the test for axes at all?  I think it's perfectly valid to have an HID box that has only buttons on it -- think, for example, of a box that provides just a row of switches that can be used as emulated circuit breakers.  Is that a necessary test ... ?

(And, yes, I'll do that test tonight and post the results.  Again, thanks for the pointers!)

---

Yep; no output at all, so it's ignoring the device.  I'll go rewrite the device software to produce at least one axis.

It'd be nice, though, to have some control (a configuration flag?) over that test.

---

I agree that it's valid to have no-axis devices. On Windows & macOS, we get HID usage information, telling us what sort of device we're looking at, but our Linux implementation has no such data. We need some way to exclude things like keyboards & mice, and the "has an absolute axis" test seemed like the best option. :/

---

I figured it was something like that.

For what it's worth, at least on my system (I'm running OpenSUSE Tumbleweed), it looks like mice are accessible only to UID=root or GID=input, so there's no risk at all there.  The X Window System display manager has them open, not the user.  I'd be mildly surprised if there are any Linux variants that allow unprivileged users direct access to mice.  (Only "mildly," of course, because there are so many wacky variants.)

Why not *permit* access to everything but use your heuristic to limit automatic usage?  In other words, if it's missing an absolute axis, then it still shows up in the drop-down list of devices that someone could configure, but it's assigned no functions by default.  (And, perhaps, if you wanted, the GUI could warn something like "this device exists and we can read it, but we don't know if it should be used, so it's unassigned by default.")

Even better would be something to notice that permissions deny access to things in /dev/input/by-id/, so they can be reported in the GUI as "we know this is here, but the OS isn't letting you have access; see <insert-doc-reference> for details."  That would have saved me -- and quite a few other people -- a lot of time when the CH Pro Pedals didn't work on first boot up.

By the way, thank you again for your clear and to-the-point response.  You've earned another sale for XP11 ... as soon as I can get home and place the order.

---

Just a short follow-up.  I was able to make my box appear in X-Plane's list by making sure that the device description includes X and Y axes in the data.  Specifically, in my HID descriptor, I added usage page "generic desktop" (0x01) usages X and Y (0x30 and 0x31).  Interestingly, the more appropriate usages would have been RX and RY (0x33 and 0x34), because these values are rotation angles, but with those usages set, X-Plane still ignored my box!  It has to be linear X and Y or nothing.

More amusingly, the descriptor I'm using now is essentially identical to the one that a canonical USB mouse would report.  If the X-Plane code was trying to avoid accidentally including mice, then the test is precisely backwards because the only thing that it allows is, in fact, mice.

I think the X-Plane code as it stands is incorrect.  It shouldn't be making this test at all.  Please consider this a plea to change the code.  (And if you need a separate bug report, let me know, and I'll figure out how to file that.)

Also: thanks again for the details!

---

I've talked this over with the rest of the team, and we're going to try removing the IsJoystick() check for the upcoming 11.10b1. Assuming all goes well, in 11.10, you won't need to hack these axes into your device.

Thanks so much for your patience, Carlson. I think X-Plane on Linux will be better for it. :)

---

Me, too.  Thanks!  I'll run some experiments when that release comes out.