Inputfd: Better Supporting Gaming Devices On Wayland

[phoronix]

Phoronix: Inputfd: Better Supporting Gaming Devices On Wayland

Linux input expert Peter Hutterer of Red Hat has published a draft proposal for a new Wayland protocol simply dubbed Inputfd...

http://www.phoronix.com/scan.php?pag...yland-Protocol

[Rob72]

Great news! Mice/touchpads have really benefited from libinput, so here is hoping for something similar for gaming devices.

But he should probably also speak to the Google developers working on adding wayland gaming input protocol support.

[dh04000]

This can't be done in libinput? Wasn't the point of libinput to handle all of this, so there is ONE complete input handling approach that can be targeted?

[lucrus]

So Canonical was right after all... " First, we are aiming for a more extensible input event handling that takes future developments like 3D input devices (e.g. Leap Motion) into account..."

Source: https://en.wikipedia.org/wiki/Mir_(s...e)#Controversy

[pal666]

So Canonical was right after all...

no. even if mir fiasco was for the sake of inputfd(it wasn't), clearly inputfd can be implemented in wayland without mir

[pal666]

Wasn't the point of libinput to handle all of this, so there is ONE complete input handling approach that can be targeted?

wasn't this for servers, not for clients?

[DrYak]

First, we are aiming for a more extensible input event handling that takes future developments like 3D input devices (e.g. Leap Motion) into account...

Leap Motion isn't even an HID input device (it doesn't issue event).
It's a glorified infra-red stereo web-cam, so it's well beyond the job of libinput.
At best it's a job for V4L2 and then an OpenCV stack that can process the two (lit/unlit) pairs (left/right) of stereo image into a depth field.
Same with occulus rift's position tracker (high contrast / high speed infrared camera that simply constantly record a 2D black/white image of the blink-codes emitted by all the IR leds), etc.
All these are interesting solution to problems but which are 99.99% handled in software post-processing, rather than in a firmware which converts it into suitable events.
So it's not really a good argument in the Mir about Lininput debate.
This kind of devices are more the target for a software processing daemon (That take the video input and emits input events on its own).
(Say as opposed to a touchpad, which under the hood is a glorified multi-channel capacitance meter, but actually process this input itself and can expose it to the laptop either in the form of a simple mouse pointer, or as a 2D touch surface. So that's definitely a candidate for libinput implementing extension that go beyond the "see it as a regular mouse" and handle all the additional gesture capabilities of this)


The thing is, in the near future, some constructor are going to go batshit crazy experimenting whatever weird idea they have.
Instead of having libinput needing to find a way to talk with which ever weird shit constructors come up with, the idea behind inputfd is letting the constructor write specific code handling the specific weird protocol used by the device. In other words, that is some sort of "libusb" but specific for input devices and without needing to muck with access right to raw USB device nodes.

In theory, it sound like a good idea : at least it enables quick bringing new devices' support for Linux. So newly released shit isn't Windows-only.

In practice, it will be problematic on the long term :

- it shift the onus to the game developers to support every last gizmo. We're back to the MS-DOS era (specially at the time of 3D Head-mounted display, and joysticks trying to speak digital over the analog port) where games needed to support every single last gizmo by featuring shitload of built-in drivers.
At least in modern times that can be mitigiated when using widespread engines (you know that (e.g.) Unigine, Unreal and Crytek are going to be a common target for gizmo-driver writer).

- survivability is going to be problematic. Currently, i can take any USB HID conforming joystick/gamepad and still use it in any game long after the constructor has went belly up, even if the gizmo is completly weird. (I could use ryhtme game bongos plugged into an appropriate USB converter to play quake3 if I weremasochistic enough).
Whereas devices with proprietary protocols over the serial port (such as 90s' 3D mouses, like Logitech's original CyberMan) are pretty much useless.
So lot's of devices relying on inputfd will be similarly facing impeding death once the game for which they were designed loses popularity : there's no guarantee that their non-strandard protocole will be re-used in other games/engines or will get reverse-engineered.

[tjwhaynes]

In theory, it sound like a good idea : at least it enables quick bringing new devices' support for Linux. So newly released shit isn't Windows-only.

In practice, it will be problematic on the long term :

- it shift the onus to the game developers to support every last gizmo. We're back to the MS-DOS era (specially at the time of 3D Head-mounted display, and joysticks trying to speak digital over the analog port) where games needed to support every single last gizmo by featuring shitload of built-in drivers.
At least in modern times that can be mitigiated when using widespread engines (you know that (e.g.) Unigine, Unreal and Crytek are going to be a common target for gizmo-driver writer).

I think you are missing another piece of the puzzle - libraries like libSDL handle gaming devices. It will not fall on the game developers to support every device - they will simply reach for the appropriate middleware library to map those devices into the game's unique needs.

This boils down to:

inputfd passes the devices to the game when it starts
game uses libSDL to turn the devices into buttons, axes, etc.
alt-tab (pausing the game) now stops the flow of device information into the game, allowing that device to be used by the newly focussed app.

[DrYak]

I think you are missing another piece of the puzzle - libraries like libSDL handle gaming devices.

If that's how it gets down it will be nice.
This is already the situation in other fields :

- scanners in SANE (for every stupid USB scanner manufacturer that isn't capable of making a standard class-compliant device. You used to need a separate reverse engineered kernel driver - which is something hard to keep maintained in mainline due to the obscurity of such hardware. At some more or less recent point of time, SANE switched to using libusb and maintain their own set of drivers in user-land. Given the obscurity of all the concerned scanners, it's really making sense.)

- other types of sound devices in pulse audio : if it's not a standard ISA, PCI/PCIe, or USB Audio-class device, it's not handled by ALSA kernel drivers. So instead pulse-audio handles it directly (example: talking with A2DP Speakers over bluetooth using standard BT channels/sockets, talking with dedicated studio audio equipement over FireWire using libieee, etc.)

(there are even a few HID diveces handled this way: the Logitech forcefeed-back mouse, and eMagine's 3D Visor VR googles have libusb drivers. No way to put such one-of-a-kind old junk into mainline).


But I am afraid that game developers are going to go the "roll-your-own" route, on the reasoning that they can share code with their similar "roll-your-own" support on Windows. So you'll end-up with tons of buggy unmaintainable closed-source code spread across games, each employing their own single use "Bongo"-controller or Toy-robot controller (winks to Nintendo).