Hi Jingkui, I heard about your team's efforts on the wayland gaming input protocol proposal. I wasn't on the list prior and had difficulties replying to the thread directly, so sorry for likely starting a new thread.
I applaud work being done in this field and we had a close look over the spec. Ourselves we are quite interested in gamepad / joystick support in Wayland for various use cases. We carefully reviewed the spec and understand some of the decisions made, but overall we feel the spec is a bit limiting for general gamepad support. First, I will go over general feedback to the 'core gamepad functionality' and then into more extended features, which should be considered as well. The spec uses a 'standard gamepad' as described in the W3C spec. Use of a standard gamepad simplifies the whole axis and button mapping situation, which is a pain. However, mapping gamepads to this standard gamepad is in my opinion not a good idea. The majority of controllers for Xbox / PS3 / PS4 and some of the common PC models kind of map to this. Speaking of my company's Dualshock 4 it for example has an extra button which the spec doesn't handle. The Steam Controller for example has extra triggers also not handled. Aside from this there are many existing controllers which should work like the Wii Mote or the recently announced Joypads for the Nintendo NX, but they don't provide enough buttons or axes. I see the client side ultimately getting implemented across SDL2, Wine and other applications and if really meant as a general gamepad interface, I don't think it is a good idea. I don't have a good alternative yet, except for giving up on the standardized gamepad and maybe bubbling up hardware ids (so applications can do the mapping, though probably undesired) or maybe proposing a general axes / button mapping, but even that is tricky as well. The second half of my feedback is more centered on extended functionality. These features are not always available on each device, but this kind of data should come from a gamepad API as applications shouldn't use another channel to get this data. Some of it which has been common for quite some time: - Rumble / Force feedback - Led support - Motion sensors - Touchpad Rumble / force feedback has been supported since at least PS2 days or before and is common on gamepads. Led support is in general about the LEDs found on many controllers for Xbox, PS3, PS4, Wii and others. Depending on the model this can at minimum be used for showing the player number (often 1-4) and on some devices even for color animations (e.g. on DS4). On Linux this is currently often done through sysfs and I think libinput may be able to read this now as well. Motion sensors have been supported on DS3, DS4, Steam Controller and others. Typically this are accelerometers and gyroscopes presented as raw or calibrated data. Touchpads are more recent features as found on DS4 and Steam Controller. Speaking for the DS4 we currently report that on Linux using hid-sony as a device separate from the controller (has to do with evdev limitations). Not sure how a gamepad API needs to handle that whether it needs to merge the devices or not. If reporting as separate devices, we would need a way to 'tie' them together from an application perspective if there are multiple gamepads. Some sort of hardware id or something could be used. To summarize for core gamepad functionality, I think the gamepad API as is is a bit limiting. There many other devices which we could support fine on e.g. Desktop Linux and there are popular existing devices which don't map exactly. Then there is the situation about extended features and how to handle them. Myself I'm new to Wayland and need to see what other protocols for like tablets and other devices are doing, but maybe some sort of capability bitmap could make sense. My team and I ourselves need most of this functionality as well, so we won't mind helping out in some way. Thanks, Roderick -- Roderick Colenbrander Senior Manager of Software Engineering Gaikai, a Sony Interactive Entertainment Company [email protected] _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
