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