On 12.05.2017 16:28, Benjamin Tissoires wrote:
On Fri, May 12, 2017 at 4:23 PM, Benjamin Tissoires
<benjamin.tissoires@xxxxxxxxx> wrote:
On 05/12/2017 09:57 AM, Arek Burdach wrote:
On 12.05.2017 09:39, Benjamin Tissoires wrote:
On Fri, May 12, 2017 at 9:25 AM, Arek Burdach <arek.burdach@xxxxxxxxx>
wrote:
On 12.05.2017 08:56, Martin Kepplinger wrote:
No, you won't have "move after hold>5s" broken. Because at the HID
level, the device is supposed to send an update on every touch
when
reporting a touch (for Windows 8 devices). So if there are tiny
movements filtered at the input level in the kernel, we will get
those
and I suspect the timeout will only appear when the finger actual
leaves the surface.
ok. sounds a little more like a solution in the kernel would be
justified. Isn't it? It still feels dangerously ugly.
Mainly I wanted to point out that if you somehow have to stay with
"no"
for such broken devices, tslib would be a garbage can for userspace
workarounds. (in this case, most probably a new device-specific
hidraw
based module).
(...)
I am currently checking the requirements for the devices to be
validated by Microsoft:
https://msdn.microsoft.com/en-us/windows/hardware/commercialize/design/compatibility/1703/device-input-digitizer
I would believe that the Latency and ReportRate requirements mean that
as long as a finger is there, it should be reported at at least 60Hz,
meaning that if there are no input reports for more than 16 ms, all
fingers should be lifted. I think we can work something like that
(taking an arbitrary multiple of 60 Hz would prevent any system lag),
and release the touches if nothing comes in for, lets say, 250ms.
Thank you Benjamin, it is significant brick for building knowledge how
this devices are handled in Windows. I will take a look in our drivers
and will try to understand the code and find the way how to handle it.
I should be able to work on that for Win8 devices. Win7 devices are a
different beast, but hopefully they are nearly extinct or at least
quirked in the kernel for them to be working.
I have something which seems to compile, but for various reasons I haven't tested it (yet):
(...)
From what I can read in the documentation, this might be enough. However,
I wouldn't be surprised if this segfaults for whatever reasons.
Also note that there is no guards between the execution of the release and
the incoming events. So if you wait around 250 ms between 2 touches, nothing
prevents a race between the timeout previously started and the actual true
touches.
I've just tested it. Tapping works like a charm! but ... dragging
stopped to work at all. From logs is see that release event is produced
even if there is some other event like ABS_MT_POSITION_Y.
Maybe one useful information is that I've observed that average delay
between events when I'm moving finger on screen or using touchpad is
about 7-9 ms.
Feel free to send patch proposals for testing. I'll try to debug what is
wrong.
Cheers,
Arek
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
