> > > Correct, the DS4 sends a touch history. The last element is the > > latest. An input report can contain multiple touch samples, because > > the device internally samples at a rate which is higher than at which > > it generates HID reports. On USB you can easily see multiple touch > > events and it is even easier on Bluetooth (especially if it is set to > > a low frequency). The extra history is important for gestures. > > OK, so if it's important, you need to actually send it by adding > input_mt_sync_frame() and input_sync() calls. Otherwise, the values will > just get mangled by the kernel in evdev and everything happens as if you > just sent the last pair in the history. > > The first 4 patches are IMO mergeable, but this one will need a little > bit more polish to actually forward the events. > > Cheers, > Benjamin > > > > > Thanks, > > Roderick Hi Ben, A kind of follow-up to this patch feedback which made it into the final patch. The recommendation was to use input_mt_sync_frame, which was a good recommendation. There is one oversight, which I'm not sure how we need to handle. Basically input_mt_sync_frame triggers pointer emulation, which is a problem for the Dualshock 4 since it already provides an ABS_X / ABS_Y, so the pointer emulation affects the analog stick values. The hid-sony driver registers the touchpad through input_mt_init_slots with the flags parameter '0', which was intended not to request such emulation I think. I'm not too familiar with the other input code, but should input_mt_sync_frame gate pointer emulation based on INPUT_MT_POINTER / INPUT_MT_DIRECT flags or something like that? Thanks, Roderick -- 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
