Hello, I have been working on a project that does its own report processing on various game controllers by opening the hidraw node; however, at the same time, the drivers keep generating reports on the regular hid nodes in /dev/input. In general, this is not a problem, but some controllers, like the DualShock 4, present a mouse and/or keyboard input. In games, that mouse input can cause problems if the game expects the touchpad to be purely available as raw input and not also a discrete cursor that it doesn't even know is from the same source. I've seen that the hid-steam driver has a check for if the hidraw is opened and unregisters the other hid nodes if that happens, but the more I look into implementing that approach in the hid-sony driver, the more it becomes clear that this goes against the grain of how hid drivers are expected to work: that driver creates a second, "fake" hid device that it then exposes only as a hidraw, prevents the real device from appearing as a hidraw, and uses an ll driver to tell when it's been opened. This seems like a heavy-handed kludge at best, as it goes pretty far out of the way of what these APIs are intended for, and I was wondering if there's a better approach, or if a better approach should be implemented. While I know that X.org and/or Wayland can probably be manually told to stop paying attention to these hid devices, it seems like some sort of ioctl to the hidraw may be preferable in this case, though no such ioctl exists at the moment. Possibly another approach would be to be able to tell when a hidraw is opened without a massive workaround so the driver can decide what to do. Either way, porting that kludge to another driver seems like perpetuating an anti-pattern, and I'm not really fond of that idea. Vicki
