Please keep the comments on-topic guys. We don’t like having to moderate and remove off-topic responses.

The developer’s blog is not an open topic forum and it’s especially not intended as a way to solicit information from the developers on status.

I second the question… it’s been long without betas or releases eh?
Also is x64 windows code coming as you guys said would come?

Any ETA Terrence? June ?

Very excited, long wait. As you mentioned

http://www.youtube.com/watch?v=vVA66HAxn5k

There is no change to the dataref interface or UI behavior in 10.10.

When we redo the UI, we will continue to support the existing datarefs.

In the long term there’s probably a better way to allow for third party hardware but that’s not a short term priority.

We already suffer some issues (like X-Plane thinking there’s no Joystick and drawing a “nice” cross for flying with the mouse, or, as far as I can tell, different settings (like linearity) not being applied to our inputs, so wanted to ask if at least we will be keeping same functionality.

Essentially our cockpits talk with X-Plane using a TCP connection and a plugin, which exposes our HW to all data refs. For us, elevator is no different than throttle, so would rather keep using a dataref rather than emulating a Joystick.

We are using HIDAPI on Mac/Lin to talk to HID devices, but not Linux – for Linux we have to use input.h. The problems on Linux are three-fold:
1. HIDAPI doesn’t feature a HID report descriptor parser (and descriptor parsing is not trivial). So it doesn’t provide the pre-parsed data that we need.
2. In some cases, the device permissions to view an input device as HID (and not as the more specific input/joy) require root permission. We do not want to have to walk our users through modifying udev to use their joystick – it really has to just work.
3. It appears that most modern distros come with hidraw, but the regular hid driver (the one where the OS parses the descriptor) is often compiled out.

If anyone ever resolves these issues we could use HIDAPI on three platforms instead of two, which might be nice for sharing presets across platforms. But we’re prepared to ship with input.h for now.

Chris and I should have started a betting pool as to how long before someone said “why not SDL.”

We looked at SDL but its functionality (in multiple areas) is often not rich enough to build the user experience we want. Sometimes the SDL API does less than our OS specific code now, and in sometimes it’s about the same but doesn’t contain the new features that we want. In some cases, modifying SDL to do what we want would be _highly_ non-trivial.

For example, for input devices we want to be able to track the addition/removal of hardware on the fly for hot-swapping devices, and pull as much meta-data off of the device as possible so that we can pre-initialize a device sanely, or load a preset for a known device.