I propose writing a daemon that will run on Linux, MacOS, and FreeBSD/OpenBSD and have access rights to /dev/input . It will create files in the /dev/gamepad/ directory using Unix sockets. The directory itself will be world-readable, but not writable. It will contain files/sockets that can be read and written by anyone. For each detected gamepad (and for virtually created ones), a file/socket with a name in the format uid_idx will be visible. Where uid is the number in the database, idx is the index needed when connecting two identical gamepads. These files will be binary and have a specific structure. I won't reveal it in full now, but here's an example: allocate several bytes for buttons. For example, 32 bits should be enough for everyone; 8 bytes per stick (vec2) (I think 4 sticks should be enough for everyone), 4 bytes per pedal (float) (the maximum number needs to be considered), and more. Let me explain right away: a "stick" is a normalized vector2, ready for use in an application. A "pedal" is a number between 0.f and 1.f; it's for triggers, pedals, and the like. For example, INF can be used as a value for hardware that doesn't exist. When an application attempts to read from this socket, the daemon creates the necessary structure according to the rules for the given uid and the file(s) associated with it from input and returns it. When an application attempts to write to this socket, the daemon sends a command to the device, if it supports such a command. The rules can be borrowed from the sdl project, but in the future, this idea should completely eliminate the need to process input in sdl. It's important for the project to be cross-platform, and for the license to be compatible with any Unix-compatible OS out of the box. This is necessary to standardize gamepad input across different operating systems and simplify app development. It's a Unix-centric answer to xinpit, and it's much more functional. It supports backlighting and a gyroscope. The format of the read/write structures needs to be discussed extensively; it will be complex, but it could become a standard for centuries. The road emerges beneath the feet of those who walk. Sorry if this isn't quite the right address, but the kernel, Wayland, and specific distributions have refused to accept such initiatives in the past (I've read other people's proposals), but this project is conceptually quite close, albeit on a smaller scale.
I propose writing a daemon that will run on Linux, MacOS, and FreeBSD/OpenBSD and have access rights to /dev/input . It will create files in the /dev/gamepad/ directory using Unix sockets. The directory itself will be world-readable, but not writable. It will contain files/sockets that can be read and written by anyone. For each detected gamepad (and for virtually created ones), a file/socket with a name in the format uid_idx will be visible. Where uid is the number in the database, idx is the index needed when connecting two identical gamepads. These files will be binary and have a specific structure. I won't reveal it in full now, but here's an example: allocate several bytes for buttons. For example, 32 bits should be enough for everyone; 8 bytes per stick (vec2) (I think 4 sticks should be enough for everyone), 4 bytes per pedal (float) (the maximum number needs to be considered), and more. Let me explain right away: a "stick" is a normalized vector2, ready for use in an application. A "pedal" is a number between 0.f and 1.f; it's for triggers, pedals, and the like. For example, INF can be used as a value for hardware that doesn't exist. When an application attempts to read from this socket, the daemon creates the necessary structure according to the rules for the given uid and the file(s) associated with it from input and returns it. When an application attempts to write to this socket, the daemon sends a command to the device, if it supports such a command. The rules can be borrowed from the sdl project, but in the future, this idea should completely eliminate the need to process input in sdl. It's important for the project to be cross-platform, and for the license to be compatible with any Unix-compatible OS out of the box. This is necessary to standardize gamepad input across different operating systems and simplify app development. It's a Unix-centric answer to xinpit, and it's much more functional. It supports backlighting and a gyroscope. The format of the read/write structures needs to be discussed extensively; it will be complex, but it could become a standard for centuries. The road emerges beneath the feet of those who walk. Sorry if this isn't quite the right address, but the kernel, Wayland, and specific distributions have refused to accept such initiatives in the past (I've read other people's proposals), but this project is conceptually quite close, albeit on a smaller scale.