Hi Benjamin, > well, I'm not very satisfied with this patch. I first thought it was a > good idea but I can see now several cons: > 1. Henrik would like to partially base the time spent between two > events when the device wraps on the *event* time. This is a great idea > for consistency, but I'm afraid I won't be able to implement it > because this time is computed *after* we call input_event and is only > used by evdev. Thus, I still need to add an other clock and some > differences may occur. Alternatively, device times need to become part of input core. > 2. the user space (at least X) will not use it before a long time: > they already have the time of the event and it will not add that much > consistency. Ok. > 3. it will wake up the whole input chain when fingers are present but > no moves occurs on the digitizer: the only events we get are > MSC_TIMESTAMP and EV_SYN and the user-space will be awaken just for > that. Good point, and a second argument for including this in the input core. > 4. MSC_TIMESTAMP does not have an abs_max value, thus we are forced to > compute sth consistent in the kernel that can be forwarded to the user > space. Granted, but we do not really lose anything by doing so. > So, I propose not to include this feature, and eventually reverting > the patch that introduced MSC_TIMESTAMP as it's useless if we don't > use it right now. > > Jiri, Dmitry, Henrik, are ok with that? I think it is fine to postpone the patch, but based on the comments above, I do not think we need to revert the input definition. 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
