#2247 Linux event input subsystem does not handle reinit

[Colin Geniet]

Steps to reproduce:

• Start Flightgear
• Plug in a device using the linux event API (/dev/input/event* devices, not the HID system), or change the configuration file for such a device in $FG_HOME/Input/Event/
• Reinit input subsystem (e.g. with the Debug -> Reload input menu)
• The new device is not recognized / the configuration is not updated

Expected behaviour:
Reinit of the input subsystem refreshes event input devices and their configuration (as it already does for joysticks, HID input devices...).

[James Turner]

The event-input code is kind of unmaintained, is there a reason you'r eusing it over the HID version?

[Colin Geniet]

The event-input code is kind of unmaintained

Sorry then, I did not realise that.

is there a reason you'r eusing it over the HID version?

There's a number of reasons, yes:

• AFAIU, event-input reads from device files /dev/input/event* whereas HID reads from /dev/hidraw*. This may be specific to my setup, but the former already had appropriate permissions, whereas I had to add a udev rule for the latter.
• The HID system gives the raw values for joystick axes, with values in e.g. [0,255] (depending on joystick).
  The event-input system takes into account calibration (using the program evdev-joystick for instance), and reports values in [0,1], which I find more helpful.
• The joystick axes names reported by <debug-events>true</debug-events> with the HID system are non-sensical: throttle is abs-x-translate, rudder is abs-y-translate, aileron is abs-z-rotate...
  With event-input, I get the expected names: abs-x/y-translate for the stick, abs-z-rotate for rudder, abs-throttle for throttle.

Overall, I find that the event-input system works far better than the HID system for linux.
Of course I realise that the point of the latter is that it is platform independent.

[James Turner]

Well, some of these are fixable thins in the HID code - the goal is that eventually this will be able to replace all the other systems.

The 0..1 range thing is actually doable inside HID, patches welcome! And there is an alternative HID backend (via libusb) which avoids the permission issue, but it won't work for some input devices (for example my GoFlight panels, don't show up unless hidraw is used)

The axis naming thing is weird, might be a bug : it's supposed to be consistent. Again some help debugging why it's different would be appreciated.

[James Turner]

Hmm, I realised my previous answer might seem a bit glib, so to explain the overal situation a bit better:

• Event-input was added many years ago, by a developer who is no longer around
• It had a macOS version which was effectively using the macOS HID system (and it never had a Windows impl ever, so far)
• the HID input system is intended to be 'an implemention of event input using HID, for all platforms'

The idea of all of this is to replace the old PLIB joystick code (and config files) with a new set of config files based on event-input. I.e the same config XML would work with zero changes using event-input on Linux, or HID on any platform, or even DirectInput on Windows (if someone wished to write such a thing)

The problem is, basically no one actually uses the original event-input code, apart from, maybe ,you , so it's very hard to achieve the compatability goal. Since the HID devices I have don't work with event-input on Linux, I can really only test 'real HID mode', and I'm forced to add a udev rule regardless.

Given all this, it's absolutely okay to make the event-input code 'do more', but we also need to try to fix the comptability issue with the HID implementation, before they diverge, since really it's all supposed to be one system in the end.

Especially since I guess that like you, for normaly joystick devices, using event-input may make more sense (no permissions or claibration to worry about).

[Colin Geniet]

I'm starting to understand the history of these systems.

Given all this, it's absolutely okay to make the event-input code 'do more', but we also need to try to fix the comptability issue with the HID implementation, before they diverge, since really it's all supposed to be one system in the end.

What would be the (theoretical) plan here? To merge them? Or to port whatever is interesting from event-input to HID, and deprecate event-input?

The axis naming thing is weird, might be a bug

I will try to understand what's going on with that.

The 0..1 range thing is actually doable inside HID

I'm mostly concerned about the calibration part. But I don't even really know how programs such as evdev-joystick work, so I have no idea what to say here (except that I have a lot of doc to read).

[James Turner]

One thing is to port some things form event-input to HID: especially the ability to have values i the 0..0 range (as an option) : for some of the controls on my devices I want integer values becuase they are rotary delta encoders (they send -1 or +4 or something for each click, dependinghow fast you spin them)

Another thing would be to decide if we use HID-with-libusb or event-input as the default on Linux: if the former, then we should merge the event-input code into HID and deprecated event-input. But personally I only ever used HID with HIDraw on Linux, I don't know iof we can do both.

We need some solution so regular Linux with 'just a joystick' don't need to mess with UDev rules.

And to be honest, I was totally unaware about the calibration issue. I suspect the problem is we will need calibration inside FlightGear (for platforms where we use raw HID), but for platofrms where calibration is external, that kind of sucks.