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). >> >> (...) >> >>> Thank you for clarification. So do someone have an idea how it is >>> possible that Windows manages this? From my point of view, they can't >>> rely on timeouts because effect is visible immediately after releasing >>> finger. Is it possible that they use other protocol for communication >>> with device then we do? Because beside that, I don't see any other >>> option - there is too few information from device to correctly handle >>> this situation. >> >> hey, Benjamin explained what most probably is going on, see above, so: >> >> 1. convice yourself that microsoft isn't using out-of-band data by >> sniffing the connection. > > Touchscreen is communicating via i2c - am i right? Can you recommend some > i2c sniffer for windows? I wrote something few months ago: https://github.com/bentiss/SimplePeripheralBusProbe But it requires you to have confidence in not breaking your EFI :) I can help you setting the bits up if you want. > >> 2. if not, and Benjamin is right, come up with a timer- and hidraw based >> solution (I guess) and convince him and Dmitry to take it. >> >> 3. if they don't see any chance to support such broken behaviour in the >> kernel, which could as well be and also has it's benefits in some way, >> you write the thing in userspace (a tslib raw module is only one example >> that would make it easy for you). >> >> Even *if* Synaptics would come up with a firmware update: >> 1. the current firmware is already out there in the wild; >> 2. it takes time and work to get people to update >> >> so, if I had the device, I'd write a workaround. > > It is reasonable what you've wrote. The only blocker for me is that I have > almost zero-experience in low level programming. I'm from java world :-) It > is why I was looking for some low entry level solution. I'll do my best but > every helping hand will be appreciated. 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. 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. Cheers, Benjamin > > 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
