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

[Aric Stewart]

I have a few moments heads up from my current task so I can circle back here at least a bit.

On 3/2/17 12:49 AM, Roderick Colenbrander wrote:
> 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.
> 

Well I am at first ecstatic that you did not read over these patches and just say "NO". I got most of this from dinput code and my very beginning reading about evdev. I am very much not a Linux or evdev developer. 

> 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.
> 

My vision is that for gamepad/joystick we will likely stick mostly with evdev.  I agree that seems to have the best support and I love being able to leverage all the kernel work. Then for other hid devices, scales, golf simulators, whatever, they can be hidraw devices as likely those applications already know they need to do whatever funky things they need to do to communicate to those devices. 

> 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).
> 

Yeah, I have been aware of composite devices, but presently have done no work on handling them. Mostly because my box of test devices have no composite devices in them and because it gets really tricky really quickly.  I have been designing with it in the back  of my mind so hopefully when we get demands for composite devices to work sanely it will be able to be worked in without extensive re-writing. 


Thanks!
-aric

> 
>>
>> Best regards,
>> Sebastian
>>
>>