In #164, among other changes I introduced DeviceEvent to represent raw input events not associated with any particular window. This allowed applications to access much-needed high resolution unfiltered sensor data e.g. from mice, allowing for interactions such as high-fidelity first-person camera control. However, as the events are not window-related, it is somewhat at odds with the need to limit winit's scope to the task of handling windows.
Further research has since made it apparent to me that raw input can be handled entirely by an external crate without winit's cooperation on Linux and Windows, by creating an independent X or Wayland connection and (so long as winit does not indiscriminately consume events for windows not its own) HWND_MESSAGE window respectively. Such a crate would also be better positioned to handle firmly out-of-scope, but widely required, functionality such as game controller and joystick input.
If/when such a crate is written, winit's scope could therefore be narrowed and more clearly defined by the wholesale removal of non-GUI-related events, replaced with a recommendation to use the external crate. This strikes me as an ideal factoring of the problem.
I'm not sure whether it's appropriate to remove DeviceEvent in the mean time--I don't think it's had time to see much use in the wild yet, so future breakage could be limited by acting quickly, but the information it exposes is important and there is not yet any good alternative crate with which to access it.
In #164, among other changes I introduced
DeviceEventto represent raw input events not associated with any particular window. This allowed applications to access much-needed high resolution unfiltered sensor data e.g. from mice, allowing for interactions such as high-fidelity first-person camera control. However, as the events are not window-related, it is somewhat at odds with the need to limit winit's scope to the task of handling windows.Further research has since made it apparent to me that raw input can be handled entirely by an external crate without winit's cooperation on Linux and Windows, by creating an independent X or Wayland connection and (so long as winit does not indiscriminately consume events for windows not its own)
HWND_MESSAGEwindow respectively. Such a crate would also be better positioned to handle firmly out-of-scope, but widely required, functionality such as game controller and joystick input.If/when such a crate is written, winit's scope could therefore be narrowed and more clearly defined by the wholesale removal of non-GUI-related events, replaced with a recommendation to use the external crate. This strikes me as an ideal factoring of the problem.
I'm not sure whether it's appropriate to remove
DeviceEventin the mean time--I don't think it's had time to see much use in the wild yet, so future breakage could be limited by acting quickly, but the information it exposes is important and there is not yet any good alternative crate with which to access it.