> The protocol definitions for Xinput are incomplete and buggy in 1.11. > That's why it is disabled by default.
I see. I thought that XCB-Xinput has matured well enough and was made available to the general public (tm) by now. Guess I was wrong. > In the next major release (1.12), the Xinput protocol definitions will be (almost) complete. So, maybe we'll activate it by default then. That's good to hear. It will take a while until that reaches Debian though, libxcb still on 1.10 now - even in sid. > If libxcb-xinput is already used with release 1.11, we need to take care of ABI compatibility when releasing the fixes in 1.12. > We have to solve that for XKB, too, so there is no way around this anyways. > > One possible solution is to do symbol-versioning for this and provide compatibility wrappers for old symbols, with appropriate symbol-versions. > (like the glibc does it, for example) > > I hope we can come up with some automatic or semi-automatic way to do this. > > Symbol-versioning will provide ABI compatibility but not API compatibility. > Maybe that's acceptable: If the interface of an API function is buggy, the client-source-code will need be fixed anyways. > ABI-compatibility is important, of course, so that existing binaries continue to work after upgrading libxcb-xinput. It looks like Fedora ships the Xinput extension, and some people are already starting to use it (as evidenced by the KF5 wacomtablet port). But since it is still an experimental API, the additional work on compatibility may not be worth the effort. Developers that use the the extension now should likely expect to make changes to their code later. Thanks for the heads up though!
