[PATCH 1/5] winebus.sys: Handle linux input event device via udev

[Roderick Colenbrander]

On Mon, Feb 27, 2017 at 8:52 AM, Sebastian Lackner
<sebastian at fds-team.de> wrote:
> 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.

For some devices hidraw is a decent option, but in general my strong
recommendation is to stay the hell away from hidraw. The HID spec
itself has many holes (e.g. no good button mapping) and many vendors
implement device specific methods to do certain things (e.g. for
controller rumble, sensors, ..). The Linux kernel has a generic HID
parser, but there are so many fixups for devices, quirks and custom
handling. It is best to have the Linux kernel's evdev framework do the
work.

However the downside of evdev is that there is no 1:1 mapping between
HID devices and evdev devices. More and more devices are reported as
composite devices through evdev including Wacom devices, Wii
controllers, Sony controllers and more. It means for each HID device
there are multiple evdev nodes with the same product/vendor/version,
but different capabilities. Some separate out touch functionality,
others do it for sensors. Ideally this patch series would 'merge'
devices, maybe based on EVIOCGPHYS or something (or serial number).


>
> Best regards,
> Sebastian
>
>