[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 1/5] winebus.sys: Handle linux input event device via udev
From:       Aric Stewart <aric () codeweavers ! com>
Date:       2017-02-27 16:58:41
Message-ID: cc0ec539-e46a-bc5f-b5bc-770345ea8506 () codeweavers ! com
[Download RAW message or body]



On 2/27/17 10:52 AM, Sebastian Lackner 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).
> 

I am not a linux expert but according to quick web research udev has been default \
since about Linux kernel version 2.6.13. That is sometime around 2006. It became part \
of systemd in 2012. So I am reasonably sure that any modern linux system will have \
it. I am not sure how much we worry about pre 2006 systems. 

-aric


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


[prev in list] [next in list] [prev in thread] [next in thread]