On Fri, Jul 20, 2012 at 11:14:25AM +0800, Chung-Yih Wang (王崇懿) wrote: > From our experiments, the assumption of "the slowest corner is the > stationary finger" is not always true. That is the major reason we want to > report the firmware data instead of semi-mt. Oh, but that was precisely the point; the reason it does not hold true is due to sensor and discretization errors. If we can improve upon this situation, we get a better model of reality. > The problem here will be how > to remove the pulling effect, we measured the pulling effect before and can > not get a good result as there could be IIR in firmware as well. It seems > not an easy job to remove the pulling effect cleanly. Probably a simple filter will work. If the bounding box is moving too fast for the tracked point to stay in the right corner, the solution is to use a smaller time step. In practise, keeping the tracked point as a state in the driver, and updating the bounding box using box -> (1 - m) box + m box_new. If the tracked point is in the right corner, let m = 1. If not, choose a smaller m. > > > * Add a new device property (INVALID_Y_AXIS_CROSSING?) that > > > describes the exact behavior of this device. I would be ok with this > > > if everyone else is, but only because proper clickpad behavior > > > (which I consider very importand) is broken without this knowledge. > > > Sounds good to me(but I would rather to have INVALID_CROSSING instead, > depending on the relative finger positions, it could still have wrong > tracking either in X or Y axis crossing) Propagating information about various sensor defects to userspace sounds horrid to me. The sooner we can forget about these devices, the better. > > > * Leave the device as SEMI_MT, but provide the real locations, and > > > allow userspace to determine the device vendor/model/etc. If > > > userspace knows that a specific device behaves in a specific way, it > > > can do its own quirking handling. Given the specificity of this > > > behavior to only some devices of one brand, this would be my > > > suggested resolution to the issue. > > > > A bit confused here, do you mean we report the real locations instead of > bounding box the current driver have? I am not quite sure if this will > affect other existing works in userspace for this semi-mt driver. I am not entirely opposed to this solution, but I would much rather see an attempt to improve the bounding box in the driver, since such a solution could be useful for other devices as well. Thanks, Henrik -- 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
