Re: [PATCH v2 3/5] winebus.sys: Process device reports for linux event devices

[Roderick Colenbrander]

Hi Aric,

Some quick feedback on this patch as well. High-level looks okay (need
to have a deeper dive), one thing really implement proper support for
EV_SYN and particular you MUST handle SYN_DROPPEPD, it has bitten me
many times. Basically if you don't process input fast enough (can
happen for various reason either you are too slow or device is too
fast), evdev drops input and you can't trust the state. When input is
dropped SYN_DROPPED is sent and you must follow the required
procedures to recover (ignore any input data until next SYN_REPORT).

I'm not sure how you are marking the end of input reports, but you may
want to mark a report completed based on the proper SYN flag as well
else you may build up unneeded input latency. Didn't follow too
closely what you are doing yet.

Thanks,
Roderick

On Mon, Feb 27, 2017 at 9:33 AM, Aric Stewart  wrote:
> v2: Updates from Sebastian Lackner
> Signed-off-by: Aric Stewart
>
> dlls/winebus.sys/bus_udev.c | 203 ++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 197 insertions(+), 6 deletions(-)

[PATCH v2 3/5] winebus.sys: Process device reports for linux event devices

[Roderick Colenbrander]

Hi Aric,

One other comment regarding this patch is the value interpretation. On
Linux the standard is for negative values to be left/up and postive to
be right/down. From what I remember in HID and also on Windows (at
least xinput) vertical axes are inverted relative to Linux. You
probably want to flip the axes.

In addition for the value interpretation rely on the absinfo
information for ranges for clamping etcetera like I mentioned for an
earlier patch as well.

Thanks,
Roderick

On Wed, Mar 1, 2017 at 10:39 PM, Roderick Colenbrander
 wrote:
> Hi Aric,
>
> Some quick feedback on this patch as well. High-level looks okay (need
> to have a deeper dive), one thing really implement proper support for
> EV_SYN and particular you MUST handle SYN_DROPPEPD, it has bitten me
> many times. Basically if you don't process input fast enough (can
> happen for various reason either you are too slow or device is too
> fast), evdev drops input and you can't trust the state. When input is
> dropped SYN_DROPPED is sent and you must follow the required
> procedures to recover (ignore any input data until next SYN_REPORT).
>
> I'm not sure how you are marking the end of input reports, but you may
> want to mark a report completed based on the proper SYN flag as well
> else you may build up unneeded input latency. Didn't follow too
> closely what you are doing yet.
>
> Thanks,
> Roderick
>
> On Mon, Feb 27, 2017 at 9:33 AM, Aric Stewart  wrote:
> > v2: Updates from Sebastian Lackner
> > Signed-off-by: Aric Stewart
> >
> > dlls/winebus.sys/bus_udev.c | 203 ++++++++++++++++++++++++++++++++++++++++++--
> >  1 file changed, 197 insertions(+), 6 deletions(-)