On 27.02.2017 17:22, Aric Stewart wrote:
On 2/27/17 10:00 AM, Sebastian Lackner wrote:
I assume this is meant as a fallback, if we don't have access to hidraw, right? If you plan to use this as a replacement for dinput, it would be better to implement it without fixed dependency on udev.
Likely users using HID for gamepads and joysticks will end up this route by default because all the permissions are automatically setup for us. Also then user will get to leverage all the work done in the kernel to handle devices that do not behave well on the HID side or which do not show up at all using hidraw (Xbox Controllers for example)
The dependency for udev is for common device discovery. I feel like I still want that dependency unless we write our own device plug and unplug discovery system.
Are you sure that there are no systems out there where we have linux events, but no udev? If yes the current solution is fine, but otherwise we should at least implement a fallback method similar to how its done in dinput (basically, just trying to open all devices in the range 0 .. MAX_JOYDEV).
Does it hurt when both hidraw and input event devices are found? If yes, it would be better to filter duplicates somewhere else, instead of using registry keys.
You can get duplicate devices, on being talking to the hidraw device and one to the linux event device, but both are the same physical device. I have explored a little bit to try to find if there is a good way to detect if a device is duplicated but it has not proven to be immediately easy.
If it can cause problems it is probably still worth the effort. There might also be systems where hidraw devices have access permissions by default, and we don't want to get duplicated input events then.
Also then the question because which device is preferred if we find a duplicate.
I think preferring hidraw might be slightly better. Some devices also offer their own control utilities, and those would probably not work when using linux input events. Nevertheless, its a matter of taste and we can certainly discuss about that.
Best regards, Sebastian