On Wed, Aug 05, 2015 at 03:29:06AM +0530, Aniroop Mathur wrote: > Hello Mr. Torokhov, > > On Tue, Aug 4, 2015 at 10:20 PM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > Hi Aniroop, > > > > On Sat, Aug 01, 2015 at 03:58:52AM +0530, Aniroop Mathur wrote: > >> When clock type is changed, previously stored data is flushed > >> and therfore does not reach to upper layer or application. > >> Data is critically important along with the timestamp. > >> So to avoid data loss and send correct timestamp as well, > >> lets not flush data upon clock type change and > >> to send correct timestamp, store only monotonic timestamp during write > >> and change monotonic clock time to desired clock time during read. > > > > I wonder if this matters that much. The only time where this change would make > > difference is when you have a reader thread and then a controlling > > thread changing clocks. Then you probably do not want to lose events, > > but you also would not know for given event what kind of timestamp it > > uses. > > > > For this case, I would like to throw some insight. > We could lose events and not know what kind of timestamp it uses but we can > know if timestamp is proper or not. If frequency of events are very high and > clock type is changed in between, it is possible that new timestamp is less > than old timestamp. Although it is a correct timestamp as per clock type but > for application it would mean that there is some problem with event timestamp > because it is ideally impossible that timestamp of new event is less than > previous event timestamp. This can happen if events are flushed or not. > But I think losing events is a bigger issue than an incorrect timestamp. Why? I can see that you would not want to lose keyboard events for example, but for them you do not really care about timestamps, but for other devices, like absolute touchpads and touchscreens, dropped events can and do happen (imagine you for some reason get a spike in CPU load and your reader does not schedule quickly enough to drain the event queue). > > > On the other hand I expect that your application changes clock type the > > very first thing after opening the event device. In this case the > > flushing queue does not matter: you are losing events that happened > > before you opened the device, so it does not really matter if you lose a > > few more in the beginning. > > > > I guess I need better understanding of your use case. > > > > Before explaining my use case, I would like to tell you about application which > checks timestamp strictly. > Application Name - CTS Verifier. > This is the application developed by Google to check functionality of android > device. It is mandatory for every android device in the world to pass all test > cases, otherwise device cannot be released in market. In the sensor module, > this application performs verifications like EventOrderVerification, > EventGapVerification, EventTimestampSynchronizationVerification, etc. > EventTimestampSynchronizationVerification verifies that the timestamp of the > event is synchronized with SystemClock.elapsedRealtimeNanos(), based on a given > threshold. > Ref Link: > https://source.android.com/compatibility/overview.html > http://androidxref.com/5.1.1_r6/xref/cts/tests/tests/hardware/src/android/ > hardware/cts/helpers/sensorverification/EventTimestampSynchronizationVerification.java OK. > > My Use Case: > Like cts application, My application checks for sensor events and provide > suggestions to correct it at run time. It checks sensor working from > "kernel side" by opening up the event device and enable the sensor so that > driver starts reporting events. It reads the events and checks if there are any > event time synchronization errors, event gap errors, etc are there or > not just like cts. > Event time synchronization error is checked using api > SystemClock.elapsedRealtimeNanos(). Event time synchronization error occurs > because event timestamp and timestamp received using > SystemClock.elapsedRealtimeNanos() does not match. > If event time synchronization error occurs, the application changes the clock > type and then check if error is still occuring. Now when clock type is changed, > event time synchronization error is removed but event gap error occurs > because events are lost. > Application working dummy example: > 1. data_x1, data_y1, time1... TimeSync - NOT OK, EventGap - OK > 2. data_x1, data_y1, time1... TimeSync - NOT OK, EventGap - OK > Application decides to change clock > 3. data_x1, data_y1, time1... TimeSync - OK, EventGap - NOT OK > 4. data_x1, data_y1, time1... TimeSync - OK, EventGap - NOT OK Now just teach your application that seeing a gap upon clock change is OK and call it a day. > > So, both test cases could not be checked together and thats how I came up with > the idea that it is better not to flush the events upon clock change. > > Similar use case for complete checking of driver, hal, framework where we use > original cts application and our application. > Similar use case for sensor simulator. > > Like in sensor domain, there can be more use cases in other domains which other > domain team members must be aware of. > > Apart from above, I have always read and learnt that kernel code should be > generic and should work fine for all application uses upon kernel upgrade. > I guess if events are lost in previous kernel version, them it should not be > lost in new version. That is not entirely true. We improve behavior of the kernel all the time and in this particular case I consider the behavior an improvement, because it allows application to recognize old vs new timestamps explicitly even in case when thread consuming the events is separate from the thread that is changing clock type. Thanks. -- Dmitry -- 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
