Hi,<br> I'm puzzled that Xinput 2 removes support for the concept of extension devices that the original used. For touchpads, styluses, and the like, the new code makes perfect sense to me, but what about LPFK, Dials, SpaceBalls, etc, that aren't meant to send pointer events?<br>
<br> I ask because I have, and use, a SpaceNavigator. The events it sends are interpreted by applications that are aware of it. Currently, the state of SpaceNavigator support in Linux is rather fragmented - some applications open it directly as an evdev device, some use the proprietary driver. I think that treating it as an extension device, as the original xinput design appeared to support, is the right idea. The focused application receives the input events from it, allowing two open applications to share it.<br>
<br> Floating slaves don't quite cover this use case. Applications would have to arbitrate for control, and since simply following the keyboard focus is the desired behavior, this seems excessive. Is it possible to support extension devices as a third class of devices, as we currently have keyboards and pointers?<br>
<br> I'm up for writing and testing the SpaceNavigator driver itself (and I have started already), but the modifications to xinput to support it are nontrivial and I'm really out of my depth.<br><br>Thanks,<br>Jen.<br>