On Aug 12 2015 or thereabouts, Orivej Desh wrote: > -linux-kernel@xxxxxxxxxxxxxxx > -jkosina@xxxxxxxx > > * Benjamin Tissoires > > Hmm... This was actually my first shot, and I noticed that the > > flickering original Z axis was now taking over the correct X axis. So > > that's why I added some complexity to ignore at the HID level this axis. > > I just forgot to update the comment :) > > How did you notice that? Is there a tool in hid-replay? I did not test I used evemu-record (package evemu) to see at the raw outputs from the kernel. > my edition of the patch extensively because I did not expect such a > subtle difference. Yet I did not observe flickering when joypad was > idle. There might be filtering on the userspace side for X/Y, that would explain. > > I assumed that the commit that hid Rx axis in 3.18 by calling > "map_abs_clear(usage->hid & 0xf);" effectively removed any influence of > repeated axes in report description, but now it seems I am wrong. Would > you explain what it really did? It did remove the repeated axes. When you call map_abs(), it tries to map the given HID axis to the corresponding evdev axis. But if this axis is already mapped to an existing HID axis, it tries the next one. This works OK for miscellaneous axes, but not for the ones that are actually used and have a true semantic. By calling map_abs_clear(), the evdev axis is left untouched, so the next time it is mapped, it does not try the next one. > > > If you think this patch is good enough (you will get flickering X), we > > can carry on this one, but I think the one I submitted (with the comment > > edited) would provide a better experience. > > In this case I certainly prefer your original patch. OK. I'll amend the comment in the patch and resubmit then. Cheers, Benjamin -- 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
